Vulnerabilidades

*** Pendiente de traducción *** Totara LMS v19.1.5 and before is vulnerable to Incorrect Access Control. The login page code can be manipulated to reveal the login form. An attacker can chain that with missing rate-limit on the login form to launch a brute force attack. NOTE: this is disputed by the Supplier because (1) local login is enabled/disabled server side (this is not a client side control); (2) there is no evidence SSO login can be bypassed to allow local login; and (3) there is no evidence that local login can be performed when disabled server side.

*** Pendiente de traducción *** Totara LMS v19.1.5 and before is vulnerable to HTML Injection. An attacker can inject malicious HTML code in a message and send it to all the users in the application, resulting in executing the code and may lead to session hijacking and executing commands on the victim's browser. NOTE: The supplier states that the product name is Totara Learning and that the functionality referenced is the in app messaging client. They note that the in app messaging client only has the ability to embed a specific allowed list of HTML tags commonly used for text enhancement, which includes italic, bold, underline, strong, etc. Last, they state that the in app messaging client cannot embed , , , , , , , , , , etc., and any attempt to embed tags or attributes outside of the allowed list (including onerror, onaction, etc.) is sanitized via DOMPurify.

*** Pendiente de traducción *** A heap buffer overflow in the av_bprint_finalize() function of FFmpeg v8.0.1 allows attackers to cause a Denial of Service (DoS) via a crafted input.

*** Pendiente de traducción *** An improper resource deallocation and closure vulnerability in the tools/zmqsend.c component of FFmpeg v8.0.1 allows attackers to cause a Denial of Service (DoS) via supplying a crafted input file.

*** Pendiente de traducción *** An out-of-bounds read in the read_global_param() function (libavcodec/av1dec.c) of FFmpeg v8.0.1 allows attackers to cause a Denial of Service (DoS) via a crafted input.

*** Pendiente de traducción *** A stack overflow in the experimental/tinyobj_loader_opt.h file of tinyobjloader commit d56555b allows attackers to cause a Denial of Service (DoS) via supplying a crafted .mtl file.

*** Pendiente de traducción *** A vulnerability in the `TFSMLayer` class of the `keras` package, version 3.13.0, allows attacker-controlled TensorFlow SavedModels to be loaded during deserialization of `.keras` models, even when `safe_mode=True`. This bypasses the security guarantees of `safe_mode` and enables arbitrary attacker-controlled code execution during model inference under the victim's privileges. The issue arises due to the unconditional loading of external SavedModels, serialization of attacker-controlled file paths, and the lack of validation in the `from_config()` method.

*** Pendiente de traducción *** Before Airflow 3.2.0, it was unclear that secure Airflow deployments require the Deployment Manager to take appropriate actions and pay attention to security details and security model of Airflow. Some assumptions the Deployment Manager could make were not clear or explicit enough, even though Airflow&amp;#39;s intentions and security model of Airflow did not suggest different assumptions. The overall security model [1], workload isolation [2], and JWT authentication details [3] are now described in more detail. Users concerned with role isolation and following the Airflow security model of Airflow are advised to upgrade to Airflow 3.2, where several security improvements have been implemented. They should also read and follow the relevant documents to make sure that their deployment is secure enough. It also clarifies that the Deployment Manager is ultimately responsible for securing your Airflow deployment. This had also been communicated via Airflow 3.2.0 Blog announcement [4].<br /> <br /> [1] Security Model: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html <br /> [2] Workload isolation: https://airflow.apache.org/docs/apache-airflow/stable/security/workload.html <br /> [3] JWT Token authentication: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html <br /> [4] Airflow 3.2.0 Blog announcement: https://airflow.apache.org/blog/airflow-3.2.0/ <br /> <br /> <br /> <br /> Users are recommended to upgrade to version 3.2.0, which fixes this issue.

*** Pendiente de traducción *** Sourcecodester Computer and Mobile Repair Shop Management System v1.0 is vulnerable to SQL Injection in the file /rsms/admin/services/view_service.php.

*** Pendiente de traducción *** Sourcecodester Computer and Mobile Repair Shop Management System v1.0 is vulnerable to SQL injection in the file /rsms/admin/inquiries/view_details.php.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()<br /> <br /> m2sm() converts a u32 slope to a u64 scaled value. For large inputs<br /> (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores<br /> the difference of two such u64 values in a u32 variable `dsm` and<br /> uses it as a divisor. When the difference is exactly 2^32 the<br /> truncation yields zero, causing a divide-by-zero oops in the<br /> concave-curve intersection path:<br /> <br /> Oops: divide error: 0000<br /> RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601)<br /> Call Trace:<br /> init_ed (net/sched/sch_hfsc.c:629)<br /> hfsc_enqueue (net/sched/sch_hfsc.c:1569)<br /> [...]<br /> <br /> Widen `dsm` to u64 and replace do_div() with div64_u64() so the full<br /> difference is preserved.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP<br /> <br /> Weiming Shi says:<br /> <br /> xt_match and xt_target structs registered with NFPROTO_UNSPEC can be<br /> loaded by any protocol family through nft_compat. When such a<br /> match/target sets .hooks to restrict which hooks it may run on, the<br /> bitmask uses NF_INET_* constants. This is only correct for families<br /> whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge<br /> all share the same five hooks (PRE_ROUTING ... POST_ROUTING).<br /> <br /> ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different<br /> semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks<br /> validation silently passes for the wrong reasons, allowing matches to<br /> run on ARP chains where the hook assumptions (e.g. state-&gt;in being<br /> set on input hooks) do not hold. This leads to NULL pointer<br /> dereferences; xt_devgroup is one concrete example:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]<br /> RIP: 0010:devgroup_mt+0xff/0x350<br /> Call Trace:<br /> <br /> nft_match_eval (net/netfilter/nft_compat.c:407)<br /> nft_do_chain (net/netfilter/nf_tables_core.c:285)<br /> nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61)<br /> nf_hook_slow (net/netfilter/core.c:623)<br /> arp_xmit (net/ipv4/arp.c:666)<br /> <br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> Fix it by restricting arptables to NFPROTO_ARP extensions only.<br /> Note that arptables-legacy only supports:<br /> <br /> - arpt_CLASSIFY<br /> - arpt_mangle<br /> - arpt_MARK<br /> <br /> that provide explicit NFPROTO_ARP match/target declarations.