Overview
Version 3.0.7 of the Securly Chrome Extension contains multiple vulnerabilities involving insecure data transmission, weak cryptography, and improper access control. These issues may expose sensitive filtering rules, enable the manipulation of downloaded configuration files, and allow unauthenticated access to protected resources. An attacker could exploit these weakness to steal configuration information, induce a Denial of Service (DoS), or modify content blocking rules for student users.
Description
The Securly Chrome Extension is a browser add-on commonly used in K–12 school-managed Chromebooks to enforce internet safety policies, filter or block websites, and provide activity monitoring for students. It is an element of the Securly classroom management platform, which helps schools comply with web filtering requirements and safely manage student online access.
CVE-2026-8874
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 Internet Watch Foundation (IWF) and Children’s Internet Protection Act (CIPA) data over HTTPS, demonstrating an inconsistent implementation of TLS.
CVE-2026-8876
The Securly Chrome Extension contains hardcoded, plaintext AES passphrases in securly.min.js. These keys decrypt crisis alert keyword data and intervention site data.
CVE-2026-8878
The Securly Chrome Extension exposes multiple publicly accessible endpoints that allow unauthenticated access to sensitive data. The exposed information consists of SHA-1 hashes that are inadequately obfuscated using a simple Caesar cipher, which can be easily reversed to recover the original hash values and access the protected data.
CVE-2026-8879
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.
CVE-2026-8881
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. This weak derivation method significantly reduces the effective security of the encryption, making the protected data vulnerable to efficient offline cracking.
CVE-2026-8888
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.
CVE-2026-8889
The Securly Chrome Extension uses deprecated SHA-1 hashing for IWF CSAM URL matching (25,020 hashes) and CIPA blocklist matching (12,352 hashes).
Impact
These vulnerabilities collectively enable multiple attack paths and threaten the security and privacy of student users, for which the extension may be academically mandatory. The HTTP configuration downloads (CVE‑2026‑8874, CVE‑2026‑8888) and weak cryptographic primitives (CVE‑2026‑8876, CVE‑2026‑8881, CVE‑2026‑8889) allow a network‑adjacent attacker to intercept, modify, or decrypt data related to keyword filtering. The presence of unauthenticated, publicly accessible endpoints with trivially reversible obfuscation (CVE‑2026‑8878) further exposes internal keyword lists, blocklists, and rule definitions. These weaknesses enable the reconstruction and manipulation of the extension’s filtering logic. For student users, this could result in exposure to content that the filtering system is intended to block, or the inappropriate blocking of legitimate educational resources. Additionally, the undeclared, dynamically‑registered content script (CVE‑2026‑8879) can be abused to fully obscure web pages, leading to DoS conditions for end users.
Solution
Unfortunately, Securly could not be reached for coordination of these vulnerabilities. Until a patch is available, administrators can lower their potential exposure by restricting usage of the extension on untrusted or public networks, installing school-managed VPNs on the underlying devices, and monitoring for unexpected or abnormal filtering behavior.
Acknowledgements
Thanks to the reporter Santh for discovering and researching these vulnerabilities. This document was written by Molly Jaconski.

Overview
VoLTE deployments on Verizon’s IMS network have operated without negotiated SIP integrity protection. In observed test conditions, SIP signaling—including registration, call setup, and messaging—traveled without IPsec ESP encapsulation and without SIP Security Agreement headers, exposing it to interception and modification by on-path attackers.
Recent carrier configuration updates, including Apple’s iOS 26.5 carrier bundle released on May 11, 2026, include IMS IPsec–related settings. However, such configuration entries do not confirm active deployment, successful negotiation, or functional protection in production.
Description
CVE-2026-10629
Verizon IMS deployments were observed transmitting SIP signaling without integrity protection. REGISTER exchanges lacked Security-Client, Security-Server, and Security-Verify headers, and no ESP-encapsulated SIP traffic was detected during subsequent signaling such as INVITE, MESSAGE, BYE, and UPDATE. This pattern persisted across devices, operating systems, and network conditions, indicating a deliberate network configuration rather than a transient issue.
Per 3GPP TS 33.203 and GSMA IR.92, SIP signaling between the UE and P-CSCF must be protected using IPsec ESP following IMS AKA authentication, with negotiation occurring during registration. The absence of this protection allows attackers to manipulate SIP signaling undetected, enabling call hijacking, spoofing, denial-of-service, and misrouting of emergency calls.
Verizon initially acknowledged the issue and stated that integrity support would be available upon request and extended broadly later in the year. However, the company has since ceased participation in coordination, including follow-up discussions and draft review, and has not provided verifiable evidence of mitigation. As remediation remains unconfirmed, this disclosure proceeds to inform users of an ongoing security exposure.
Independent verification would require observation of successful SIP security negotiation, ESP-protected traffic, or official confirmation from Verizon.
Impact
Without integrity protection, on-path attackers can intercept, replay, or alter SIP messages with no risk of detection. This undermines core VoLTE security assumptions and enables signaling spoofing, call disruption, and manipulation of emergency routing.
Although recent configuration changes suggest potential progress, their operational status remains unverified. Until protections are confirmed, the risk persists.
Solution
Remediation requires coordinated network and device-side changes. Verizon must enable and enforce SIP security negotiation and ESP protection in its IMS core infrastructure, and devices must receive and apply correct carrier configuration to support IPsec.
Verification should confirm successful SIP security negotiation and ESP-protected signaling, either through observed headers, traffic capture, or operator confirmation.
Until then, organizations relying on high-assurance VoLTE should treat signaling as untrusted
Acknowledgements
The authors thank DongWon Lee, Jeongmin Choi, and CheolJun Park from Kyung Hee University for their technical analysis, coordination efforts, and identification of the iOS 26.5 configuration updates. Their work has advanced understanding of this issue and ensured disclosures remain grounded in observable evidence.
This report was prepared by Timur Snoke, with AI-assisted drafting to support clarity and accuracy.

Overview
A stored cross-site scripting (XSS) vulnerability has been discovered in Appsmith, specifically in the CodeMirror based SQL query editor’s autocomplete renderer. CVE-2026-7299 has been assigned to track the vulnerability. An attacker with developer level access to a shared PostgreSQL datasource can inject arbitrary JavaScript by creating malicious database objects whose names contain XSS payloads. Successful exploitation leads to arbitrary JavaScript execution in the browser of any workspace member who triggers SQL autocomplete, enabling session hijacking, privilege escalation, or credential theft. Version 2.1 of Appsmith fixes CVE-2026-7299.
Description
Appsmith is an open source, low code platform intended to allow developers to build internal tools, dashboards, and applications using a UI builder, database and API integrations, and JavaScript customization. Appsmith can also be deployable either self-hosted or via the cloud. A vulnerability, tracked as CVE-2026-7299, has been discovered, allowing for XSS within the SQL query editors autocomplete function.
The vulnerability description is below.
CVE-2026-7299
Appsmith’s SQL query editor’s autocomplete functionality fails to sanitize database object names before rendering them in innerHTML, allowing an authenticated Developer to inject persistent XSS by a malicious table or column names triggering arbitrary code execution in the sessions of other workspace members when they interact with the same datasource.
This vulnerability requires an account with developer access. A developer Appsmith account is an account designed to create, edit, and delete apps within a workspace they are assigned to. When an administrator opens the SQL editor and triggers autocomplete (e.g., by typing SELECT * FROM), the malicious table name executes their stored payload, which can allow for privesc.
Impact
Successful exploitation of CVE-2026-7299 leads to arbitrary code execution in the browser of any workspace member who triggers SQL autocomplete, enabling session hijacking, privilege escalation, or credential theft.
Solution
Version 2.1 of Appsmith fixes this vulnerability. Users should update their installations as soon as possible.
Acknowledgements
Thanks to the reporter, Stuart Beck. This document was written by Christopher Cullen.vrf26-04-DQBSN_exploit.py