Cyber Resilience

CVE-2026-8888

RCE in Securly 3.0.7

Published
03 June 2026
Modified
22 July 2026
CVSS Score v3.1 7.5
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score 0.0043 36th percentile
Risk Priority 57 floored blend · peak EPSS

Summary

CVE-2026-8888 is a high-severity Expression Language Injection (CWE-917) vulnerability in Securly Securly. Its CVSS base score is 7.5 (High).

Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 36th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.

OWASP Top 10 for Web (2025)

EU & UK References

Vulnerability Data

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…

more

service on all browsing.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1499 Endpoint Denial of Service Impact
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users.
T1190 Exploit Public-Facing Application Initial Access
Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network.
T1499.003 Application Exhaustion Flood Impact
Adversaries may target resource intensive features of applications to cause a denial of service (DoS), denying availability to those applications.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2026-8889Same product: Securly Securly
CVE-2026-8878Same product: Securly Securly
CVE-2026-8874Same product: Securly Securly
CVE-2026-8879Same product: Securly Securly
CVE-2026-8881Same product: Securly Securly
CVE-2026-8876Same product: Securly Securly
CVE-2023-6688Shared CWE-1333
CVE-2023-45813Shared CWE-1333
CVE-2023-25167Shared CWE-1333
CVE-2025-70034Shared CWE-1333

Affected Assets

securly
securly
3.0.7

Mitigating Controls

Control response

Prevent
Stop it (NIST 800-53)

Detect
Catch it (NIST detect / respond)

Harden
Shrink the surface (DISA STIG)

Validate
Prove the fix (OWASP ASVS)
  • V1.1.2
  • V1.3.2
  • V1.3.5
  • V4.3.1

Mitigating Controls (NIST 800-53 r5) AI

Developer testing and evaluation can discover inefficient regex patterns via performance or static analysis.

Input validation directly requires checking and neutralizing special elements in externally influenced data before it is used to build executable statements such as EL expressions.

Development standards and tools can require safe regex construction and forbid known exponential patterns.

Security engineering principles include requirements for safe construction and sanitization of dynamic statements, structurally preventing expression-language injection at design time.

Denial-of-service protections limit resource exhaustion caused by expensive regex evaluation.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly require input neutralization and safe EL construction to prevent injection flaws.

ID.RA-01 partial match
prevents

Vulnerability identification processes can discover ReDoS issues in existing code but do not stop their introduction.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

finds

Security testing in development and acceptance can detect EL injection but does not itself implement the fix.

prevents

Secure SDLC mandates input validation and output encoding that directly prevent expression-language injection.

prevents

Application security requirements explicitly call for controls against injection flaws including EL injection.

prevents

Secure architecture principles reduce the attack surface but do not prescribe the specific neutralization techniques needed.

prevents

Secure coding standards require proper escaping and parameterization of expression-language statements.

References