Vulnerabilities

Version 3.0.7 of the Securly Chrome Extension dynamically registers content13.min.js as a content script via chrome.scripting.registerContentScripts() at runtime. This script is NOT declared in manifest.json and bypasses Chrome Web Store static security review. It runs on all URLs and immediately hides all page content, creates a full-page overlay, pauses all videos, and only restores content when the service worker confirms the page passes filtering. If Securly's servers are unreachable, pages remain indefinitely hidden.

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.

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.

Version 3.0.7 of the Securly Chrome Extension uses deprecated SHA-1 hashing for IWF CSAM URL matching (25,020 hashes) and CIPA blocklist matching (12,352 hashes).

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.

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.

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.

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.

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.

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

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.

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.