CVE-2026-78579

Executive Summary

CVE-2026-78579 is an LDAP injection vulnerability (CWE-90) in Okta Access Gateway in which SAML assertion attribute values are not sanitized before being interpolated into LDAP search filters used by the LDAP datastore configuration. Because SAML attribute values originate from identity providers and can be influenced by the identities being authenticated, an attacker who can cause a crafted attribute value to be presented in an assertion may alter the logic of the LDAP search performed by the gateway. Successful exploitation could allow manipulation of directory lookups, potentially leading to unauthorized reads or unintended attribute modification consistent with the CVSS confidentiality and integrity ratings of High (C:H/I:H), on systems where Okta Access Gateway brokers access to LDAP-backed resources.

Technical Analysis

The vulnerability class is LDAP injection, formalized as CWE-90 (Improper Neutralization of Special Elements used in an LDAP Query). The root cause described by NVD is a failure to sanitize SAML assertion attribute values before those values are substituted into an LDAP search filter associated with the LDAP datastore configuration.

The mechanism, as described, is direct string interpolation: the raw attribute value is concatenated or otherwise substituted into the filter string and then passed to the LDAP search operation. No encoding, escaping, or parameterization of LDAP filter metacharacters (such as the characters used to delimit filter conditions and operands) is noted. As a result, characters contained in the assertion attribute value can be interpreted by the directory server as filter syntax rather than as literal data. This is the classic "data interpreted as code" failure: because the filter is assembled as a string rather than composed from escaped/typed components, the attacker-controlled portion of the input can change the structure of the query.

The attack surface is the trust boundary between the SAML assertion processing path and the LDAP datastore lookup path inside Okta Access Gateway. A relevant attribute value arriving in a SAML assertion flows into the LDAP search filter. Because the substitution changes "the intended query logic," the effective search can be broadened, narrowed, or redirected relative to what the access decision intended.

The CVSS v3.1 vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, score 6.8 (Medium). This indicates:

• AV:N — the component is reachable over a network.
• AC:H — successful exploitation depends on conditions outside the attacker's direct control (for example, obtaining or inducing a SAML assertion that carries a suitably crafted attribute value through a trusted identity provider path).
• PR:L — the attacker requires low-level privileges (a position from which they can supply an assertion/attribute).
• UI:N — no user interaction is required.
• S:U — impact is scoped to the vulnerable gateway component rather than crossing a security authority boundary.
• C:H / I:H — high confidentiality and integrity impact against the LDAP lookup result/records.
• A:N — no availability impact.

No additional implementation detail (specific function names, filter parameter names, endpoint paths, or configuration keys) is provided in the NVD description, and none is asserted here. The affected version range is not published in the supplied data and remains UNKNOWN.

Exploitation Scenarios

Because the controlling trust assumption is that SAML assertion attribute values are safe to embed in LDAP filters, exploitation centers on getting a malicious value into an attribute that the gateway uses to build an LDAP search.

1. Reconnaissance / target identification. The attacker identifies an Okta Access Gateway deployment that brokers access to an LDAP-backed directory and that trusts a SAML identity provider. Target identification can use the well-known Okta/Access Gateway web surface (e.g., login/administration endpoints) to confirm the product and its role in the identity path. No public PoC is available in the supplied data, so the chain below is described at the vulnerability-class level, not as a verified exploit.

2. Triggering the specific flaw class (LDAP injection). The attacker arranges for a SAML assertion to carry an attribute value containing LDAP-filter metacharacters. This value is not sanitized and is interpolated directly into the LDAP search filter. When the gateway executes the search against the LDAP datastore, the directory server parses the crafted characters as filter syntax, altering the query's logical structure. The precise requirement to achieve this (authored by a trusted IdP, a claim the attacker can influence, or a self-asserted attribute) is what the AC:H rating reflects.

3. Payload / execution method (vulnerability-class level). The "payload" is a crafted attribute value rather than code. Classical LDAP-filter metacharacters and boolean/comparison operators are used to change the filter's evaluation—for example, to make a condition always true, to union in additional entries, or to target a different object than intended. The report intentionally does not fabricate specific filter strings, parameter names, or code paths, because the NVD description does not provide them.

4. Post-exploitation impact. Because the modified search changes which directory records are returned (and, per the C:I ratings, what can be read or altered), the attacker may obtain directory data they should not receive or cause the gateway to act on records other than those intended by policy. This can undermine authorization decisions that depend on directory lookups—for example, mappings between SAML identities and LDAP-backed resources.

There is no CISA KEV listing, no supplied evidence of in-the-wild exploitation, and no public exploit code; exploitation should be treated as plausible and high-impact but not yet observed at scale.

Impact Assessment

• Confidentiality (High): A manipulated LDAP search can return directory entries beyond the intended result set, exposing attribute data the access policy did not authorize.
• Integrity (High): If the changed query logic leads the gateway to operate on unintended entries, subsequent authorization or resource-mapping actions can be altered.
• Availability (None): The vector reports no availability impact; the flaw affects query semantics, not service liveness.
• Scope (Unchanged): Impact is confined to the Okta Access Gateway and the LDAP lookups it performs.
• Overall CVSS: 6.8 (Medium), reflecting a serious but condition-dependent (AC:H, PR:L) flaw.

Blast radius: Any deployment of Okta Access Gateway configured to use an LDAP datastore and to consume SAML assertions whose attribute values flow into LDAP filters. The affected version range is not published; operators should treat all versions not confirmed patched as potentially affected. Because the gateway sits in the authentication/authorization path, an integrity failure here can have downstream effects on every resource it brokers.

Detection Guidance

The following rules are heuristic starting points for the LDAP-injection-via-SAML class in an identity gateway context. They must be tuned to the local environment; the NVD description does not provide exact parameter names, so detections target behavior (unexpected LDAP metacharacters carried in SAML/authentication traffic, anomalous LDAP filter strings) rather than a specific endpoint or field.

Sigma Rule

title: Okta Access Gateway - SAML Attribute Value with LDAP Filter Metacharacters
id: 5c6f1b2e-8a3d-4f1e-9c7a-000000000001
status: experimental
description: Detects SAML assertion attribute values containing LDAP filter metacharacters that may indicate LDAP injection (CWE-90) in Okta Access Gateway.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-78579
author: valtersit.com
logsource:
  category: webserver
detection:
  selection_path:
    cs-uri-query|contains:
      - 'SAMLResponse'
      - 'SAMLRequest'
  selection_payload:
    cs-uri-query|contains:
      - '%28'
      - '%29'
      - '%2A'
      - '%7C'
      - '%26'
      - 'objectClass'
      - '(|'
      - '(&'
  condition: selection_path and selection_payload
falsepositives:
  - Legitimate IdP assertions containing encoded special characters
level: medium

YARA Rule

rule CVE_2026_78579_LDAP_Injection_SAML
{
    meta:
        description = "Detects SAML assertion payloads carrying LDAP filter metacharacters for CVE-2026-78579 (CWE-90) LDAP injection"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-78579"
        author = "valtersit.com"
        date = "2026-01-01"
    strings:
        $saml = "SAMLResponse" nocase
        $attr1 = "objectClass" nocase
        $inject1 = "(|(" ascii
        $inject2 = "(&(" ascii
        $inject3 = ")(|" ascii
        $inject4 = "*))" ascii
    condition:
        filesize < 1MB and $saml and any of ($inject*) or ($saml and $attr1)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-78579 Possible LDAP Injection via SAML Attribute Value (Okta Access Gateway)"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"SAMLResponse"; http.client_body; content:"(|"; http.client_body; content:"objectClass"; nocase; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-78579; classtype:attempted-user; sid:202678579; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=1m
  [network where http.request.method == "POST" and url.query contains "SAMLResponse"]
  [network where http.request.body.text contains "(|" or http.request.body.text contains "(&" or http.request.body.text contains "objectClass"]

Splunk SPL Query

index=web sourcetype=access_combined
| eval raw=lower(_raw)
| where match(raw,"saml(response|request)") AND (match(raw,"%7c|%28|%29|%2a") OR match(raw,"objectclass") OR match(raw,"\(\||\(&"))
| stats count min(_time) as first_seen max(_time) as last_seen by src_ip, uri_path, status
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="okta,access_gateway,web,">
  <rule id="2026785" level="10">
    <decoded_as>web-accesslog</decoded_as>
    <description>CVE-2026-78579: Possible LDAP injection in SAML attribute value targeting Okta Access Gateway</description>
    <regex_url>SAML(Response|Request)</regex_url>
    <regex_url>(%7C|%28|%29|%2A|\(\||\(&)</regex_url>
    <group>attack,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED). NVD is listed as the single source indicating a patch; this is not independently confirmed, and no vendor advisory, version number, or fixed-build reference is available in the supplied data.

1. Immediate mitigations (workarounds are not published; none listed in the data):

   • Treat all versions of Okta Access Gateway as potentially affected until a vendor-issued fix is confirmed for your build.
   • Restrict the set of SAML attributes that the LDAP datastore configuration consumes and reduce IdP trust to only vetted providers, limiting an attacker's ability to introduce crafted attribute values.
   • Apply network controls to limit which sources can present assertions to the gateway and monitor authentication traffic for LDAP metacharacters.
   • Monitor the Okta trust/security advisories channel and the NVD entry for an authoritative patch reference before relying on any single-source patch claim.

2. Patch/upgrade steps:

   • Do not treat the CLAIMED patch as confirmed. Verify against the vendor (Okta) advisory and release notes for the specific Access Gateway version that resolves CVE-2026-78579.
   • Once a vendor-issued fixed version is identified, test in a staging environment, then upgrade the LDAP datastore configuration-bearing gateways first.
   • In the absence of a confirmed fixed version, escalate with Okta support to obtain the remediation timeline for this CVE.

3. Long-term hardening:

   • Ensure the gateway/product path constructs LDAP queries using proper escaping of LDAP filter special characters rather than raw string interpolation; this is a product-side fix and should be validated in the patched release.
   • Enforce strict allowlisting of SAML attribute names and value character sets to reduce injection surface.
   • Adopt least privilege on the LDAP bind account used by the gateway so that a manipulated query cannot read or modify more than its intended scope.
   • Add continuous detection for anomalous LDAP filter strings and authentication-path injection attempts (see Detection Guidance).

References

• NVD — CVE-2026-78579: https://nvd.nist.gov/vuln/detail/CVE-2026-78579
• CWE-90 — Improper Neutralization of Special Elements used in an LDAP Query: https://cwe.mitre.org/data/definitions/90.html
• Okta Trust / Security Advisories (verify vendor advisory for Okta Access Gateway): https://trust.okta.com/
• CVSS v3.1 Specification (for vector interpretation): https://www.first.org/cvss/v3.1/specification-document
• FIRST EPSS (score 0.00247, ~16.3rd percentile at time of data collection): https://www.first.org/epss/

No CISA KEV entry, no confirmed in-the-wild exploitation, and no public exploit code were identified in the supplied intelligence. Exploit-in-the-wild evidence beyond the reported public vulnerability status was not available.