5 million Express fingerprints and 13.4 million header matches do not show proxy-addr versions
ZoomEye returned 5,018,187 matches for app="Express" and 13,381,943 for http.header="X-Powered-By: Express" on November 4, 2026. Those are measurements of an application framework and a response header. They are not measurements of proxy-addr versions.
The distinction matters for CVE-2026-90711. The vulnerable package parses trusted proxy networks and feeds client-address decisions inside Express applications. It is a transitive dependency, so the product fingerprint can reveal Express adoption without revealing the library that an application actually resolved.
Observation
| Query | Matches |
|---|---|
app="Express" |
5,018,187 |
http.header="X-Powered-By: Express" |
13,381,943 |
The app query completed at 2026-11-04T23:43:37Z and the header query at 2026-11-04T23:43:39Z. Both used page 1, page size 1, and sub_type=all. They succeeded. The difference in the counts is evidence that the two fields observe different things.
An X-Powered-By header may be set by an Express application even when the index does not identify an Express application fingerprint. The header can also be removed or rewritten by a proxy. Neither count tells us the dependency tree, the trust-proxy configuration, or whether the listener is a real application rather than a honeypot or marketing page.
What the measurements support
The counts support a scale statement: Express and its identifying header are common in the indexed web population. That makes transitive parsing bugs potentially widespread in deployed code.
They do not support a claim that five or thirteen million applications are vulnerable. An Express application may have upgraded proxy-addr, may not trust forwarded headers, may sit behind a correctly configured gateway, or may not use address-based authorization at all.
Inventory dependencies, not banners
Use software composition analysis and lockfiles to find proxy-addr versions. Include monorepos, container images, serverless bundles, and applications maintained by partner teams. Check the runtime dependency tree because a top-level lockfile can differ from a production image built earlier.
Search configuration for Express trust proxy values. Flag IPv4-mapped IPv6 subnets with short prefixes. Confirm the number of proxy hops and whether the application accepts forwarded headers from an untrusted network.
Review code that uses req.ip for access control or rate limiting. If an allowlist is based only on a client-supplied header, a parser bug can widen the trust boundary. Add a test that sends a spoofed X-Forwarded-For from an untrusted source and verifies the resolved address.
A smaller, more useful inventory
The framework count can help an external researcher describe adoption. It cannot identify the vulnerable package. A smaller inventory assembled from source manifests, container images, and runtime checks is more useful for remediation.
For organizations with many Express applications, prioritize those that expose administrative routes, password reset flows, or API rate limits. Then verify proxy-addr 2.0.8 or later and test the actual trust behavior.
Top comments (0)