Static config scanner that flags nginx configs vulnerable to the complex_value two-pass capture-clobbering bug (regex map + regex capture → heap overflow / info leak).

• clobber makes the value longer than measured: heap buffer overflow (attacker-controlled out-of-bounds write)
• clobber makes the value shorter than measured: uninitialised heap returned to the client (info leak of libc/heap pointers)

Both directions are remotely triggerable when the map input is attacker-influenced ($request_body, $http_*, $arg_*, $uri, $ssl_preread_server_name, and so on).

What counts as vulnerable

The scanner flags a location or server when all of these land in one two-pass buffer, in the exploitable order:

1. Capture source: a regex location ~, server_name ~, rewrite, if (... ~ ...), or a regex map with a capture group.
2. Clobber trigger: a map (http or stream) with a ~ or ~* regex match key, referenced by its output variable.
3. Two-pass sink using both a capture ref and the regex-map variable:
   • single-value directives (return, set, add_header, proxy_method, proxy_pass, rewrite, index, and others): both refs in the same value.
   • the param/header families (proxy_set_header, proxy_set_body, fastcgi_param, scgi_param, uwsgi_param, grpc_set_header): these build one buffer per request for the whole family, so the two refs can be in separate directives in the same location.
4. Order: the capture must be evaluated before the regex map. A regex map runs once and caches, so map-before-capture reads a consistent state and is not vulnerable. The scanner reports those as cleared (safe but fragile, do not reorder).

Usage

Options

Exit codes

Usable in CI, since a vulnerable config exits non-zero:

Output

Text mode prints, for each finding: file and line, the enclosing scope, the sink directive, the capture and map variables involved, the triggering map, and a one-line reason. A cleared section lists safe-order coexistences. --json produces:

Fixing what it finds

1. Apply the vendor patch (nginx 1.30.4 stable / 1.31.3 mainline, NGINX Plus R36 P7 / 37.0.3.1). This is the only complete fix. The patch adds a boundary guard (ngx_http_script_check_length()) that prevents the VALUE pass from writing past the allocated buffer, and computes the returned string length from bytes actually written rather than the LEN-pass measurement, closing both the overflow and the info-leak directions.
2. Interim config hardening (defence in depth, not a substitute for the patch):
   • Do not reference a regex map variable in the same location or buffer as a $1 to $9 or named-capture reference.
   • Do not reuse the same (?P<name>...) group across multiple regex maps.
   • Keep capture refs and regex-map refs out of the same proxy_set_header or fastcgi_param family.

Limitations

• Static analysis: it reads config, not runtime behaviour. It cannot resolve values produced by dynamically set variables.
• Unreadable include targets (for example absolute paths that do not exist locally) are reported under missing_includes, not silently skipped. Run it on the host where the config resolves for full coverage.
• A flagged capture-before-map hit can be defused at runtime if that map variable was already evaluated earlier in the same request (it would already be cached). The scanner still reports these, which is the conservative choice for a security self-scan.

Reference

Vulnerability write-up and exploit chain: https://cyberstan.co.uk/nginx-rce/