GHSA-8r4g-cg4m-x23c

What it actually does

A remote, unauthenticated denial-of-service flaw in the node-static HTTP static-file server allows a crafted request to hang or crash the Node.js process. The library does not adequately bound or validate request inputs (notably oversized or malformed headers and paths), which can cause unbounded CPU or memory consumption or an uncaught exception that terminates the process. Confidentiality and integrity of served files are not directly affected; availability of the static-content listener is lost until the process is restarted.

Why it matters to the business

Sites, documentation hosts, and applications that expose node-static can be taken offline without credentials, interrupting content delivery and any workflows that depend on those assets. Recovery requires a process or container restart and can be repeated by a persistent attacker. The advisory is not in CISA KEV, is not associated with ransomware campaigns, and has no recorded exploit maturity, so urgency is driven by exposure of the service rather than active mass exploitation. Residual risk remains for any lockfile, image, or downstream package that still vendors an unpatched node-static.

How an attack unfolds

An attacker finds a reachable HTTP endpoint running node-static (often a simple static site, internal file server, or development host). They send one or more malformed HTTP requests that the library fails to constrain. The Node.js process then spikes CPU or memory, blocks the event loop, or exits on an uncaught exception, so legitimate clients receive timeouts or connection failures. Repeating the request after an automatic restart keeps the service down. No authentication or data theft is required; the objective is availability disruption. No named APT groups or KEV-listed campaigns are associated with this issue.

How to fix it

Upgrade node-static to a patched release (0.7.11 or later) and rebuild any application, container, or static-hosting image that vendors it. Inventory npm/yarn/pnpm lockfiles and base images for the vulnerable package and update dependents. If an immediate upgrade is not possible, do not expose node-static directly to untrusted networks; put it behind a reverse proxy that enforces strict URI and header size limits, request timeouts, and connection rate limits, and run the process under a supervisor with memory and file-descriptor caps.

How to confirm the fix worked

Confirm lockfiles and installed packages show node-static 0.7.11 or newer; rebuild and redeploy so runtime images no longer contain the old tarball. After upgrade, restart the service and verify it still serves legitimate static content. From a non-production check, confirm the proxy or patched server rejects oversized headers and URIs and that the Node.js process remains stable under normal load. Scan container SBOM and registry images for leftover vulnerable versions.

Typical attack path

1. Discover a reachable HTTP service that uses node-static (default ports, stack fingerprints, or package/deployment clues).
2. Send crafted HTTP requests that trigger unbounded header or path handling or an uncaught exception in the static-file pipeline.
3. Confirm denial of service via process hang, crash, event-loop stall, or widespread client timeouts.
4. Replay the request against supervised or containerized instances to maintain the outage after restart.

How to detect it

There is no public in-the-wild campaign or KEV listing for this issue, so look for availability artifacts rather than a known implant. Review HTTP access and error logs in front of the static server for bursts of requests with unusually large or malformed headers or URIs immediately before outages. On hosts running Node.js static serving, inspect process-manager, container, and systemd logs for repeated node process exits, uncaught exceptions, event-loop stalls, and OOM kills coinciding with those requests. Correlate with CPU/memory spikes on the node process and 5xx or upstream timeout rates at the reverse proxy. Absence of these signals does not prove the service was never targeted; it only indicates no crash-loop evidence was retained.

• uncaughtException
• node-static
• Event loop blocked
• JavaScript heap out of memory
• npm package node-static
• HTTP request header size exceeded
• ERR_HTTP_HEADERS_SENT
• process.exit after static file request

What your security team should do

• Inventory all applications, images, and lockfiles that depend on node-static and treat internet-facing instances as first priority.
• Upgrade node-static to 0.7.11+ and redeploy; do not leave the old binary in cached layers.
• Stop exposing node-static directly; require a reverse proxy with header/URI size limits, timeouts, and rate limiting.
• Cap process memory and file descriptors and ensure crash-loop alerting on the Node.js service.
• Track this as an availability defect rather than an active KEV/ransomware item, but do not defer patching of exposed services.