Status

A response carrying a literal Status header exposes an internal server field. The unofficial header is the CGI Status field, meant to be consumed by the web server when it builds the real status line, leaking through to clients when a layer in the stack passes the field along instead of consuming the value.

Usage

The CGI specification defines Status as the way a script tells its web server which status code the response deserves. PHP-FPM, FastCGI applications, and CGI scripts emit the field internally, the server converts the value into the HTTP status line, and clients never see a Status header.

A proxy layer in front of the converting server breaks the pattern. When a CDN or reverse proxy receives an origin response where the field survived, the field travels on as an ordinary response header. Crawl data shows the leak on 90 hosts, frequently alongside cache infrastructure headers, matching stacks where a caching layer stored an origin response with the leaked field intact.

The problem is the mismatch: the leaked header and the actual status line diverge. A stored Status: 301 Moved Permanently header sits on a response whose real status line says 200, and tooling reading the header instead of the status line follows a redirect the server never sent. Clients and crawlers act on the status line alone, so the header misleads only header-parsing scripts and debugging sessions.

Values

Observed values mirror status-line text. The crawl records 301 Moved Permanently as the dominant value, with 200 OK, 404 Not Found, 302 Found, 410 Gone, and occasional bare codes like 410 behind it, plus FastCGI phrasings like 404 File not found.

Example

A cached response carries the leaked field beside a diverging status line. The real status is the 200 on the status line, and the Status header records what the origin script wanted at storage time.

HTTP/1.1 200 OK
Content-Type: text/html
Status: 301 Moved Permanently
X-Cache: HIT

How to fix

Locate the layer emitting the field. On PHP-FPM behind nginx, fastcgi_pass setups consume the field correctly, while double-proxying an already converted response preserves the leak. Removing the header at the outermost proxy (proxy_hide_header Status; in nginx or a CDN header-removal rule) hides the leak, and fixing the origin conversion removes the mismatch at the source.

See also

Last updated: September 21, 2026