NoSQL Injection / LDAP Injection

Directory-style login portals frequently map user input into structured queries, not raw SQL. If untrusted input reaches a Mongo operator or LDAP filter context, the bug class shifts accordingly.

Why It Works

• JSON bodies allow operator objects ($ne, $regex); LDAP filters allow wildcards and closures. Either lets you alter the query logic without touching SQL.

Vulnerable Pattern

• JSON login bodies, employee portals, support tooling, or "search employee by name" flows that smell like a document DB or directory backend.

Exploit Flow

1. Try operator-shaped parameters first for Mongo-like backends, then malformed filter expressions for LDAP-like ones.
2. Rely on timing, login branching, or error wording if direct data output is unavailable.

Variations

• username[$regex], password[$ne], LDAP wildcards, filter closures, or boolean operator abuse.

Common Blockers

• Server-side coercion to strings, query builders that strip operator syntax, or the backend not actually being Mongo/LDAP despite the surface vibe.

PoC Sketch

# Mongo-style auth
username[$regex]=^adm&password[$ne]=x

# LDAP-style filter abuse
username=*)(uid=*))(|(uid=*

Good Situations To Use It

• A JSON login or employee-search portal.
• Errors or timing hint at Mongo or LDAP behind the scenes.
• String coercion isn't enforced on input.

Sources

• ehaxctf2026/web/megacorp