CVE-2025-7339

What it actually does

The flaw is an improper input validation issue in the Node.js on-headers middleware before version 1.1.0. When application code calls response.writeHead() with headers supplied as an array rather than an object, on-headers can inadvertently modify response headers. At a technical level, this can lead to unintended header values or header structure changes, with limited potential impact to confidentiality or integrity depending on how the affected application uses response headers for caching, content handling, cookies, redirects, security policy, or downstream proxy behavior. The CVSS vector indicates local attack requirements and high privileges, and there is no public exploit maturity reported.

Why it matters to the business

This is a low-severity supply-chain and application behavior issue. The most likely business impact is incorrect HTTP responses, degraded trust in web application behavior, or limited exposure of data if modified headers weaken caching, content handling, or security controls. Because EPSS is very low, the issue is not currently known to be widely exploited, is not in CISA KEV, and is not associated with ransomware campaigns, it should generally be handled through normal dependency and platform patch cycles rather than emergency response. Organizations with broad Node.js dependency footprints should still prioritize inventory and patching because transitive use of on-headers may be common in web middleware stacks.

How an attack unfolds

An attacker generally cannot exploit this by simply sending a normal web request unless the application already exposes a code path where attacker-controlled input influences headers and the application or framework calls response.writeHead() with an array. In a plausible scenario, the attacker identifies a Node.js application using a vulnerable on-headers version, reaches an endpoint that triggers response.writeHead() with array-form headers, and supplies input that causes specific response headers to be produced. The vulnerable middleware mishandles that array-form input and may alter headers before they are sent. The attacker then observes whether cache directives, content type, security headers, redirect headers, or other response metadata are changed in a way that can be abused. There are no known public exploit campaigns or named threat actors reported for this issue.

How to fix it

Upgrade on-headers to version 1.1.0 or later. For source-based use of jshttp/on-headers, ensure the fix commit c6e384908c9c6127d18831d16ab0bd96e1231867 or a later release is present. Regenerate package lockfiles and rebuild containers or deployable artifacts so transitive dependencies are actually updated. If immediate upgrade is not possible, change application code to pass an object to response.writeHead() rather than an array, as recommended by the maintainer. For Alpaquita linux-lts packages listed as affected, upgrade to the fixed package versions: Alpaquita 23 linux-lts 6.1.81-r0 or later; Alpaquita stream linux-lts 6.6.58-r0, 6.12.41-r0, or later as applicable; and Alpaquita 25 linux-lts 6.12.41-r0 or later. After patching, redeploy all services that bundle the vulnerable dependency.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles resolve on-headers to 1.1.0 or later. Use package-manager commands such as npm ls on-headers, yarn why on-headers, or pnpm why on-headers to identify direct and transitive copies. Inspect generated artifacts and containers for embedded node_modules/on-headers/package.json files with versions below 1.1.0. Add a regression test for any application code that calls response.writeHead() with array-form headers and verify that expected headers are preserved after the upgrade. For Alpaquita systems, verify installed linux-lts package versions meet or exceed the fixed versions using the system package manager. Re-scan software composition analysis results to confirm the CVE no longer appears in deployed artifacts.

Typical attack path

1. Identify a Node.js web application or service that includes on-headers before version 1.1.0, directly or transitively.
2. Find an endpoint whose response construction uses response.writeHead() with headers passed as an array.
3. Determine whether user-controlled input can influence the affected response or its headers.
4. Send crafted requests that exercise the vulnerable response path.
5. Observe response headers for unintended modification, omission, duplication, or transformation.
6. Attempt to turn the header manipulation into a practical impact, such as cache behavior changes, content-type confusion, weakened browser protections, or unintended disclosure through misdirected response handling.

How to detect it

There are no known unique indicators of compromise, public exploit artifacts, or campaign-specific behaviors for this vulnerability. To check for possible prior exploitation, focus on application and access logs for endpoints that use response.writeHead() with array-form headers and compare historical response metadata against expected behavior. Useful sources include Node.js application logs, reverse proxy logs, CDN logs, WAF logs, API gateway logs, browser error telemetry, and synthetic monitoring records that capture response headers. Look for unusual or unexplained changes to security-relevant headers such as Set-Cookie, Cache-Control, Content-Type, Location, Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, and CORS headers. Also review application error logs for exceptions or warnings around response.writeHead(), header serialization, duplicate headers, or invalid header values. Because exploitation depends heavily on application-specific code paths, absence of generic IOCs does not prove absence of impact; validate affected endpoints directly if the vulnerable package was deployed.

What your security team should do

• Inventory Node.js services and build artifacts for on-headers versions earlier than 1.1.0, including transitive dependencies.
• Prioritize patching internet-facing Node.js web applications, middleware-heavy services, and applications that rely on response headers for security, caching, authentication, or content handling.
• Upgrade on-headers to 1.1.0 or later and rebuild/redeploy affected applications, containers, and serverless packages.
• Where patching is delayed, review code for response.writeHead() calls using array-form headers and convert them to object-form headers.
• Add dependency policy checks to block on-headers versions below 1.1.0 in future builds.
• Run targeted tests to compare response headers before and after the patch for critical endpoints.
• Treat this as normal-priority remediation unless local application analysis shows that header modification creates a material security control bypass.