CVE-2026-34578
Opnsense ≤ 26.1.6
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:NSummary
CVE-2026-34578 is a high-severity LDAP Injection (CWE-90) vulnerability in Opnsense Opnsense. Its CVSS base score is 8.2 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked at the 34th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
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.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-34578 is an LDAP injection vulnerability in OPNsense, a FreeBSD-based firewall and routing platform. Prior to version 26.1.6, the LDAP authentication connector passes the login username directly into an LDAP search filter without proper escaping via ldap_escape(), enabling injection of LDAP filter metacharacters. This flaw affects the WebGUI login page when LDAP authentication is configured and is classified under CWE-90 with a CVSS v3.1 base score of 8.2 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N).
An unauthenticated remote attacker can exploit this vulnerability by submitting specially crafted input in the username field during login attempts. This allows enumeration of valid LDAP usernames in the configured directory by observing LDAP server responses. Additionally, if the LDAP configuration includes an Extended Query restricting logins to members of a specific group, the injection can bypass this restriction, enabling authentication as any LDAP user whose password is known, irrespective of group membership.
The vulnerability is addressed in OPNsense 26.1.6, where the fix involves proper escaping of the username in the LDAP search filter, as detailed in the commit at https://github.com/opnsense/core/commit/016f66cb4620cd48183fa97843f343bb71813c6e and the GitHub Security Advisory at https://github.com/opnsense/core/security/advisories/GHSA-jpm7-f59c-mp54. Security practitioners should upgrade to 26.1.6 or later and review LDAP configurations for exposure.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-20896
Vulnerability Data
OPNsense is a FreeBSD based firewall and routing platform. Prior to 26.1.6, OPNsense's LDAP authentication connector passes the login username directly into an LDAP search filter without calling ldap_escape(). An unauthenticated attacker can inject LDAP filter metacharacters into the username…
more
field of the WebGUI login page to enumerate valid LDAP usernames in the configured directory. When the LDAP server configuration includes an Extended Query to restrict login to members of a specific group, the same injection can be used to bypass that group membership restriction and authenticate as any LDAP user whose password is known, regardless of group membership. This vulnerability is fixed in 26.1.6.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.2.6
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can discover LDAP injection flaws through static analysis or crafted test cases.
Input validation directly stops untrusted data from reaching an LDAP query builder without neutralization of special characters.
Secure engineering principles require safe query construction and escaping that structurally prevents LDAP injection.
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.
Secure SDLC practices directly require input neutralization and query parameterization to prevent LDAP injection.
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.
Security testing in development catches LDAP injection via dynamic analysis or fuzzing, but does not prevent it at the source.
Secure development lifecycle mandates input validation and query construction practices that directly prevent LDAP injection.
Application security requirements include explicit rules for safe construction of directory queries, mitigating LDAP injection.
Secure coding standards require proper neutralization of LDAP special characters, directly eliminating this weakness.
Secure architecture principles encourage safe query interfaces but do not prescribe the specific coding controls needed for LDAP injection.
Information access restriction limits who can query LDAP but does not address how queries are built.