CVE-2026-106510
Raw vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:LCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-106510 is a high-severity Permissive List of Allowed Inputs (CWE-183) vulnerability. Its CVSS base score is 7.7 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); 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 AC-3 (Access Enforcement) and AC-6 (Least Privilege) — see the control section below for these in your framework.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-94369
Vulnerability Data
Backstage is an open framework for building developer portals. Prior to 1.14.6, the @backstage/plugin-techdocs-node package is affected by remote code execution via crafted markdown_extensions in techdocs mkdocs.yml. An authenticated user who can register catalog entities can provide a crafted mkdocs.yml…
more
causing arbitrary OS command execution on the TechDocs build host when the docs are built. This issue is fixed in versions 1.14.6 and 1.15.4.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.5.2V4.4.2
Mitigating Controls (NIST 800-53 r5) AI
Enforces authorization checks on the code or classes ultimately invoked, blocking unauthorized selections even if reflection is used.
Limits privileges of any code reached through unsafe reflection, reducing blast radius without stopping the selection itself.
Strict validity checks on inputs directly stop overly permissive allow lists from being used as the protection mechanism.
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.
Vulnerability identification processes can discover unsafe reflection during code review or scanning.
Preventing execution of unauthorized code can block exploitation of unsafe reflection at runtime.
Secure SDLC practices directly require rigorous allow-list design and testing that prevents permissive input validation.
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.
A.8.25 mandates secure SDLC practices including secure coding guidelines, security requirements, checkpoints, testing (scans/penetration), and developer training that can catch/prevent unsafe reflection flaws during development; this stops exploitation for a minority slice (first-party code written under the process) but leaves the bulk of the weakness (e.g. in third-party libraries, legacy code, or incomplete enforcement) untouched.
Application security requirements can mandate strict, minimal allow-lists and input validation rules that prevent overly permissive lists.
A.8.27 mandates security-by-design principles (least privilege, default-deny, distrust-external-input, secure session control, data validation/sanitization, assume-breach) that reach many but not all permissive-allowlist cases; a bounded remainder (e.g. custom business-logic allowlists whose enumerated safe values are chosen incorrectly) can still be introduced and exploited.
Secure coding standards enforce rigorous input validation and reject unsafe values, mitigating permissive allow-list weaknesses.