GHSA-wjfc-pgfp-pv9c

What it actually does

This vulnerability is an improper input validation issue in nyholm/psr7, a PHP PSR-7 HTTP message implementation. Vulnerable versions can accept malformed attacker-controlled HTTP message data that should be rejected, such as invalid header-related input. In applications that use untrusted input to construct PSR-7 requests or responses, this can enable downstream HTTP behavior that differs from application intent, potentially including header injection, response splitting, cache poisoning, request manipulation, or bypass of logic that assumes the message object contains only valid HTTP syntax. The issue is not known to provide direct remote code execution by itself, and the provided exploit maturity is none, but it can become security-relevant when the library is used in web-facing request/response handling paths.

Why it matters to the business

Applications depending on vulnerable nyholm/psr7 versions may mishandle malicious HTTP input, which can lead to incorrect responses, user redirection, session or cache integrity issues, or bypasses in middleware and proxy-heavy architectures. The CVSS score is moderate, it is not listed in CISA KEV, and no mature public exploitation is indicated, so this is typically a patch-management and defense-in-depth priority rather than an emergency incident unless the dependency is used in internet-facing authentication, redirect, proxy, API gateway, webhook, or response-generation flows. Because this package is a common PHP HTTP message component, the impact may be indirect through frameworks, SDKs, or middleware rather than direct application code.

How an attack unfolds

An attacker first identifies an application path where user-controlled data is incorporated into a PSR-7 request or response object handled by nyholm/psr7. The attacker then submits specially crafted HTTP input containing malformed values that should be rejected by strict HTTP validation. If the vulnerable library accepts that input and the application later serializes, forwards, reflects, redirects, or caches the resulting message, downstream components such as web servers, reverse proxies, caches, clients, or middleware may interpret the message differently from the application. Depending on the application behavior, the attacker may be able to inject unintended headers, alter response handling, poison intermediary caches, influence redirects, or bypass validation assumptions. There is no indication from the supplied data that this issue is widely exploited or used by named threat actors or ransomware campaigns.

How to fix it

Upgrade nyholm/psr7 to version 1.6.1 or later. In Composer-managed PHP applications, update the direct dependency or any upstream package that pins nyholm/psr7 to a vulnerable version, then regenerate and redeploy the lockfile. Use `composer update nyholm/psr7 --with-dependencies` where appropriate, followed by application tests. If the affected Ubuntu 14.04 LTS packages are present in inventory, update mariadb-5.5 to 5.5.54-1ubuntu0.14.04.1 or later and mysql-5.5 to 5.5.54-0ubuntu0.14.04.1 or later, though those packages should also be assessed separately because they are a different ecosystem and Ubuntu 14.04 is end-of-life. As mitigations where immediate upgrade is not possible, reject control characters in header names and values, avoid placing untrusted data directly into response headers or redirect locations, canonicalize and allowlist redirect destinations, and ensure reverse proxies or web servers reject malformed HTTP messages.

How to confirm the fix worked

Confirm that Composer dependency resolution uses nyholm/psr7 version 1.6.1 or later by checking `composer.lock`, `composer show nyholm/psr7`, SBOM output, or software composition analysis results. Verify that deployed artifacts match the rebuilt dependency set rather than only the source repository. Run regression tests around HTTP headers, redirects, URL generation, proxy forwarding, webhook handling, and middleware that constructs PSR-7 messages. Where feasible, add negative tests that attempt to pass newline/control-character data into header names, header values, redirect targets, and similar fields and confirm the application rejects or safely encodes the input. For Ubuntu package exposure, validate package versions with package inventory tooling such as `dpkg -l` or vulnerability management scans and confirm the fixed versions are installed where applicable.

Typical attack path

1. Identify a PHP application or service that includes a vulnerable nyholm/psr7 version, often through Composer dependencies or a framework/SDK.
2. Find an endpoint where request parameters, headers, URLs, redirect targets, webhook fields, or other user-controlled values are used to construct PSR-7 messages.
3. Send crafted HTTP input containing malformed syntax such as newline/control-character sequences or otherwise invalid header-related data.
4. Rely on the vulnerable library accepting input that should have been rejected or normalized safely.
5. Trigger application behavior that serializes, forwards, reflects, redirects, or caches the crafted PSR-7 message.
6. Observe whether downstream clients, proxies, caches, or middleware process injected or malformed message elements in a security-relevant way.

How to detect it

To assess possible prior exploitation, review application access logs, web server logs, reverse proxy/CDN logs, WAF events, and application error logs for attempts to inject newline or control characters into query parameters, form fields, headers, redirect parameters, webhook payloads, or API fields that influence outbound requests or responses. Useful log sources include NGINX/Apache access and error logs, PHP-FPM logs, application framework logs, WAF/CDN security events, reverse proxy logs, and cache logs. Focus on requests containing encoded CRLF sequences such as `%0d%0a`, mixed-case variants, double-encoded forms such as `%250d%250a`, or raw control-character representations. Investigate any suspicious requests followed by unusual response headers, unexpected redirects, cache anomalies, duplicate or malformed headers, unexplained `Set-Cookie` or `Location` values, or proxy/cache errors. Because no specific public exploit or malware artifact is provided, detection should be behavior-based and scoped to endpoints that construct PSR-7 messages from user input.

• %0d%0a
• %0D%0A
• %0a
• %0A
• %250d%250a
• %250D%250A
• \r\n
• %0d%0aSet-Cookie:
• %0D%0ASet-Cookie:
• %0d%0aLocation:
• %0D%0ALocation:
• %0d%0aContent-Length:
• %0D%0AContent-Length:
• vendor/nyholm/psr7
• nyholm/psr7

What your security team should do

• Inventory PHP applications and SBOMs for nyholm/psr7 versions earlier than 1.6.1, including transitive dependencies pulled in by frameworks, SDKs, API clients, and middleware.
• Prioritize remediation for internet-facing applications, authentication flows, redirect endpoints, reverse-proxy integrations, webhook handlers, and services that forward or synthesize HTTP requests or responses.
• Upgrade nyholm/psr7 to 1.6.1 or later and redeploy from a refreshed Composer lockfile; verify the running artifact contains the fixed dependency.
• Add input validation or allowlisting for data used in response headers, redirect locations, forwarded requests, and generated PSR-7 messages.
• Review web server, reverse proxy, CDN, and cache configurations to ensure malformed HTTP messages and newline/control-character injection attempts are rejected.
• Search recent access logs and application logs for encoded or raw CRLF/control-character injection attempts against endpoints that influence headers, redirects, or proxied requests.
• Track this as moderate severity unless local exposure analysis shows attacker-controlled input is used to construct HTTP headers or responses in sensitive flows, in which case raise priority.