The same LDAP injection, in two firewalls, in the same month

OPNsense 26.1.6, released April 9, patched a three-line fix for CVE-2026-34578: an LDAP filter injection in the firewall’s authentication code. The vulnerable line concatenated the raw login username into an LDAP search filter without calling PHP’s ldap_escape(). CVSS 8.2. The code had been in production since July 27, 2015.

Weeks later, WatchGuard disclosed CVE-2026-1498, an unauthenticated LDAP information extraction flaw affecting its full T-series and M-series firewall lineup.

Two major firewall vendors. The same class of vulnerability. The same month. That is the story worth paying attention to.

The obvious read

A vendor shipped a bug, a researcher found it, the vendor patched it quickly. Twelve days from report to public disclosure. Coordinated, professional, unremarkable. If you run OPNsense with LDAP authentication, you update to 26.1.6 and move on.

That reading is correct but incomplete. The more interesting detail is how the flaw survived for eleven years, a professional security audit, and over 300,000 claimed deployments without anyone noticing.

What actually hid, and where

The vulnerable code lived in LDAP.php, in a method called searchUsers(). The LDAP filter was built by dropping the POST parameter directly into the query string. No escaping, no sanitization, no parameterization. PHP’s ldap_escape() function, which exists precisely for this purpose, has been available since PHP 5.6.0, released in September 2014. The vulnerable commit was written eleven months later.

This was not inherited from pfSense. OPNsense forked from pfSense in January 2015 and built a new MVC framework. The LDAP connector was fresh code. pfSense’s current codebase does call ldap_escape() in its authentication path. OPNsense wrote new code and introduced the flaw themselves.

Two attack primitives result from the injection. The first is unauthenticated username enumeration: submitting admin* as the username causes the LDAP server to return all entries matching that prefix, and by binary-searching prefix by prefix (a*, ad*, adm*), an attacker reconstructs valid usernames without any credentials. In organizations where LDAP usernames match corporate email addresses, this is a direct path to employee enumeration.

The second is group membership bypass, which requires any valid LDAP credential. OPNsense’s “Extended Query” feature restricts authentication to members of a specific LDAP group, a common pattern for gating VPN and captive portal access. A crafted injection payload nullifies the group check. A contractor removed from the VPN access group but whose AD account was never disabled can re-authenticate. On the captive portal and VPN surfaces, there is no downstream guard that catches this.

The pattern underneath

The OPNsense flaw is a specimen, not an anomaly. It belongs to a pattern that has been building for years across the network security appliance category.

Management interfaces don’t get audited the way data planes do. LogicalTrust conducted a professional security assessment of OPNsense in June 2023, roughly 120 hours covering the GUI, API, and parts of the system backend. They found 16 vulnerabilities, including zip-slip RCE and multiple XSS chains. Serious work. But the scope treated authentication as a precondition, not an attack surface. LDAP injection at the pre-authentication stage fell outside the threat model. The LDAP connector was not listed as an assessed component.

This is not a failure of the auditors. It is a structural feature of how security reviews are scoped. The control plane sits behind a restricted subnet (in theory), so it feels lower-risk. Authentication code is considered solved. LDAP, RADIUS, local auth: commodity features, not innovations. Teams add them, they work against a test directory, and the code stops being examined.

Long-lived code is invisible code. A file that has not generated a bug report and has not been modified in years does not attract attention during code review. The OPNsense LDAP connector went eleven years without a meaningful change. Meanwhile, the same vulnerable functions expanded in scope: they back the WebGUI, the captive portal, and VPN authentication. The audit surface grew. The review surface did not.

The tooling gap is real. LDAP injection shares the same root cause as SQL injection: user-controlled text concatenated into a query string. But parameterized LDAP queries were never standardized the way PreparedStatement was for SQL. PHP’s ldap_escape() arrived in 2014. Java JNDI requires manual escaping. RFC 4515 (search filters) and RFC 2253 (Distinguished Names) require different escape character sets; a developer who correctly escapes a DN value is not protected in a filter context. The absence of a clean, obvious parameterization API means the burden falls entirely on the developer remembering to call the right function.

The evidence keeps arriving

The OPNsense and WatchGuard disclosures are the most recent, but they are not the first.

Fortinet’s CVE-2020-12812 was not filter injection but a case-sensitivity mismatch between FortiOS and LDAP that bypassed two-factor authentication. Different mechanism, same category of blind spot. CVSS 9.8, documented APT exploitation via FBI and CISA joint advisory. Over 10,000 unpatched firewalls remained exposed as late as 2025. Cisco’s CVE-2014-2120, a cross-site scripting flaw on the ASA WebVPN login page, was present for a decade before active exploitation in 2024 drew CISA KEV attention; not LDAP injection, but the same structural neglect of a login surface on a security appliance. Linux SSSD’s CVE-2022-4254 allowed certificate data used in LDAP filter construction to bypass authentication entirely.

The common thread is not that these vendors are careless. It is that LDAP authentication code in security products occupies a blind spot: too “solved” to audit, too trusted to question, too old to review.

What this means for prioritization

If you run OPNsense with LDAP authentication, 26.1.6 is the immediate patch and it is straightforward. The harder question is what this pattern implies about where firewall security investment actually lands.

The exposure surface is larger than it looks. OPNsense’s web UI listens on all interfaces by default. The captive portal is internet-facing by design. Forum threads confirm WAN-exposed WebGUI deployments are common. The enumeration primitive requires no credentials and, on the captive portal path, produces no error messages. This is not a theoretical risk gated by network architecture; the attack surface is the login page itself.

The group membership bypass is the more corrosive finding for organizations that relied on Extended Query restrictions for VPN or captive portal segmentation. That control has been bypassable since 2015. Injected queries look like normal authentication failures in LDAP logs, which means the absence of confirmed exploitation tells you very little. If group-based LDAP restrictions were load-bearing in your access model, the patch alone does not answer whether the control was ever tested from the attacker’s side.

MSP environments compound the problem. Shared LDAP and Active Directory configurations across clients mean a single compromised credential set has a blast radius that scales with the number of managed instances, not the size of one organization.

The pattern across all of these cases is that firewall management interfaces receive less scrutiny than the traffic they inspect. The data plane gets the pentest. The control plane gets the assumption.

What to watch

The NVD entry for CVE-2026-34578 has not been published yet. The CVSS 8.2 score comes from the GitHub Security Advisory and third-party aggregators, not NVD’s own analysis. Whether the OPNsense Business Edition received the fix on the same timeline is not addressed in any public source. Whether the constant-time login delay was applied consistently across the captive portal and VPN paths is unclear from the researcher’s disclosure.

The structural question is whether the WatchGuard disclosure in the same month is coincidence or the start of a cluster. When one researcher demonstrates a class of flaw in a category, other researchers follow. LDAP authentication code in network appliances has been largely unexamined. It is reasonable to expect more disclosures in this class over the coming months.

Three lines of code, eleven years of exposure, and a professional audit that looked right past it. PatchDay Alert tracks these cross-vendor patterns in the daily digest so the signal reaches you before the next advisory does. But the flaw was not hidden. It was just in a place nobody thought to look. That is the pattern worth auditing against, regardless of which firewall sits at your edge.