Vulnerabilidades

*** Pendiente de traducción *** Version 3.0.7 of the Securly Chrome Extension downloads config.json over HTTP and compiles server-provided patterns as JavaScript regular expressions via new RegExp() without complexity validation. An on-path attacker can inject specific patterns to cause catastrophic backtracking, resulting in denial of service on all browsing.

*** Pendiente de traducción *** Version 3.0.7 of the Securly Chrome Extension uses EVP_BytesToKey key derivation with MD5 and a single iteration for AES encryption. MD5 has been broken since 2004 and a single iteration provides no key stretching.

*** Pendiente de traducción *** Version 3.0.7 of the Securly Chrome Extension downloads JSON files containing crisis alert keywords and filtering rules over unencrypted HTTP via the Fetch API. Other endpoints in the same extension correctly fetch IWF and CIPA data over HTTPS, demonstrating an inconsistent implementation of TLS.

*** Pendiente de traducción *** Concrete CMS below 9.5.2 is vulnerable to PHP Object Injection via unserialize() calls in the Workflow, Form block, and File/Set components that lack the allowed_classes restriction. An unauthenticated attacker may trigger arbitrary PHP object instantiation if a malicious serialized payload has been placed in the database. Thanks XananasX7 and Sanjorn Keeratirungsan (dizconnect) for both independently reporting. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 8.4 with vector CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.

*** Pendiente de traducción *** An authenticated ERPNext user with Item record edit permissions can persist arbitrary HTML/JavaScript in the item_name, description, or image fields of an Item and trigger unescaped rendering in the Point of Sale (POS) cart interface for every operator who adds that item to a transaction.This issue affects ERPNext: 16.16.0.

*** Pendiente de traducción *** An authenticated user can persist arbitrary HTML/JavaScript in the email_id or mobile_no fields of a Customer record and trigger unescaped rendering in the Point of Sale (POS) interface for every operator who selects that customer.<br /> This issue affects ERPNext: 16.16.0.

*** Pendiente de traducción *** OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. Prior to version 4.11.0, on many of the ECDH shared secret paths, the public key isn&amp;#39;t verified to be a point on the correct curve. By passing approximately 30-40 crafted public keys to OP-TEE, the private key can be reconstructed by a normal world attacker. When calling TEE_DeriveKey the public key is provided with full X and Y values, but the (X, Y) point might not satisfy the `Y^2 == X^3 + aX + b mod P` math for the specific curve that is used. When those public keys aren&amp;#39;t rejected, the attacker can select public keys such that each DeriveKey call will leak `d % r` where `d` is the private key and `r` comes from the relationship between the correct curve and the attacker selected curve. With enough leaked data the Chinese remainder theorem can be used to recover the full private key. Version 4.11.0 fixes the issue.

*** Pendiente de traducción *** OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. Starting in version 4.3.0 and prior to version 4.11.0, a type confusion vulnerability exists in OP-TEE OS when processing an FFA_MEM_SHARE request from the normal world. This only applies when OP-TEE is configured as an SPMC for S-EL0 SPs, that is, with `CFG_CORE_SEL1_SPMC=y` and `CFG_SECURE_PARTITION=y`. Version 4.11.0 fixes the issue.

*** Pendiente de traducción *** Cross Site Scripting vulnerability in Koha 25.11 and before allows a remote attacker to execute arbitrary code via file upload function in Invoice features

*** Pendiente de traducción *** Koha versions up to 25.11 contain a Server-Side Request Forgery (SSRF) vulnerability via the Z39.50/SRU server configuration. This allows authenticated attackers to perform internal network scanning and identify running services by analyzing server response times.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmveth: Disable GSO for packets with small MSS<br /> <br /> Some physical adapters on Power systems do not support segmentation<br /> offload when the MSS is less than 224 bytes. Attempting to send such<br /> packets causes the adapter to freeze, stopping all traffic until<br /> manually reset.<br /> <br /> Implement ndo_features_check to disable GSO for packets with small MSS<br /> values. The network stack will perform software segmentation instead.<br /> <br /> The 224-byte minimum matches ibmvnic<br /> commit ("ibmvnic: Enforce stronger sanity checks<br /> on GSO packets")<br /> which uses the same physical adapters in SEA configurations.<br /> <br /> The issue occurs specifically when the hardware attempts to perform<br /> segmentation (gso_segs &gt; 1) with a small MSS. Single-segment GSO packets<br /> (gso_segs == 1) do not trigger the problematic LSO code path and are<br /> transmitted normally without segmentation.<br /> <br /> Add an ndo_features_check callback to disable GSO when MSS

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: tmc-etr: Fix race condition between sysfs and perf mode<br /> <br /> When trying to run perf and sysfs mode simultaneously, the WARN_ON()<br /> in tmc_etr_enable_hw() is triggered sometimes:<br /> <br /> WARNING: CPU: 42 PID: 3911571 at drivers/hwtracing/coresight/coresight-tmc-etr.c:1060 tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc]<br /> [..snip..]<br /> Call trace:<br /> tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc] (P)<br /> tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc] (L)<br /> tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc]<br /> coresight_enable_path+0x1c8/0x218 [coresight]<br /> coresight_enable_sysfs+0xa4/0x228 [coresight]<br /> enable_source_store+0x58/0xa8 [coresight]<br /> dev_attr_store+0x20/0x40<br /> sysfs_kf_write+0x4c/0x68<br /> kernfs_fop_write_iter+0x120/0x1b8<br /> vfs_write+0x2c8/0x388<br /> ksys_write+0x74/0x108<br /> __arm64_sys_write+0x24/0x38<br /> el0_svc_common.constprop.0+0x64/0x148<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x3c/0x130<br /> el0t_64_sync_handler+0xc8/0xd0<br /> el0t_64_sync+0x1ac/0x1b0<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Since the enablement of sysfs mode is separeted into two critical regions,<br /> one for sysfs buffer allocation and another for hardware enablement, it&amp;#39;s<br /> possible to race with the perf mode. Fix this by double check whether<br /> the perf mode&amp;#39;s been used before enabling the hardware in sysfs mode.<br /> <br /> mode:<br /> [sysfs mode] [perf mode]<br /> tmc_etr_get_sysfs_buffer()<br /> spin_lock(&amp;drvdata-&gt;spinlock)<br /> [sysfs buffer allocation]<br /> spin_unlock(&amp;drvdata-&gt;spinlock)<br /> spin_lock(&amp;drvdata-&gt;spinlock)<br /> tmc_etr_enable_hw()<br /> drvdata-&gt;etr_buf = etr_perf-&gt;etr_buf<br /> spin_unlock(&amp;drvdata-&gt;spinlock)<br /> spin_lock(&amp;drvdata-&gt;spinlock)<br /> tmc_etr_enable_hw()<br /> WARN_ON(drvdata-&gt;etr_buf) // WARN sicne etr_buf initialized at<br /> the perf side<br /> spin_unlock(&amp;drvdata-&gt;spinlock)<br /> <br /> With this fix, we retain the check for CS_MODE_PERF in get_etr_sysfs_buf.<br /> This ensures we verify whether the perf mode&amp;#39;s already running before we<br /> actually allocate the buffer. Then we can save the time of<br /> allocating/freeing the sysfs buffer if race with the perf mode.