HIGH 7.5

CVE-2026-48979: HTTP/2 Request Smuggling in PHP Standard Library – Patch PSL 6.1.2 / 6.2.1

The PHP Standard Library (PSL) contains a flaw in its HTTP/2 server implementation that allows an attacker to bypass security controls by sending mismatched request sizes. Specifically, the server doesn't verify that the actual data received matches the size declared in the request headers, enabling an attacker to slip additional data past application-level checks or truncate requests early. This is similar to HTTP request smuggling attacks that have historically been used to bypass firewalls, WAFs, and other protective measures. Most developers using PSL through its documented APIs are unaffected; only those directly using the low-level ServerConnection class with untrusted client input face exposure.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.5 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Weaknesses (CWE)
CWE-444
Affected products
0 configuration(s)
Published / Modified
2026-06-17 / 2026-06-23

NVD description (verbatim)

PHP Standard Library (PSL) is set of APIs covering async, collections, networking, I/O, cryptography, terminal UI, etc. In versions 6.1.0, 6.1.1 and 6.2.0, the Psl\H2\ServerConnection does not validate that the total bytes received in DATA frames match the content-length header declared in the HEADERS frame, allowing request smuggling. This is in violation of RFC 9113 §8.1.1. A malicious client is able to send more DATA bytes than declared, smuggling additional content past application-level size limits and send fewer DATA bytes than declared and close the stream early, causing applications that trust the declared length to behave incorrectly. The vulnerability is only reachable for consumers using Psl\H2\ServerConnection directly to accept untrusted client traffic. Consumers of documented high-level PSL APIs are not affected. This issue has been fixed in versions 6.1.2 and 6.2.1.

3 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-48979 exploits a validation gap in Psl\H2\ServerConnection whereby incoming HTTP/2 DATA frames are not reconciled against the content-length header specified in the preceding HEADERS frame. RFC 9113 §8.1.1 mandates this validation to prevent request smuggling; PSL versions 6.1.0, 6.1.1, and 6.2.0 omit it. An attacker can send more bytes than declared (smuggling additional content), or fewer bytes followed by stream closure (causing truncation). The vulnerability manifests at the protocol-handling layer and is classified as CWE-444 (HTTP Request Smuggling), with a CVSS 3.1 score of 7.5 (HIGH). The attack surface is limited to applications directly instantiating and using Psl\H2\ServerConnection to handle untrusted HTTP/2 clients.

Business impact

Organizations deploying custom HTTP/2 servers built directly on Psl\H2\ServerConnection may experience request smuggling attacks that bypass application-level input validation, request size limits, or other business logic safeguards. This can lead to data exfiltration, privilege escalation, or injection attacks if downstream code processes the smuggled data. The integrity risk is significant—attackers can corrupt request semantics without detection by application firewalls or rate-limiting controls. However, the footprint is limited to applications that have chosen to use the low-level PSL API rather than higher-level frameworks.

Affected systems

Vulnerable versions: PSL 6.1.0, 6.1.1, and 6.2.0. Fixed versions: PSL 6.1.2 and 6.2.1. Only applications directly using Psl\H2\ServerConnection for HTTP/2 request handling are at risk. Applications using PSL through documented public APIs (async, collections, networking, I/O, cryptography, terminal UI abstractions) are not affected. No third-party vendors or products are listed as affected at this time.

Exploitability

Exploitation requires network access to an application using the vulnerable ServerConnection class and the ability to send HTTP/2 requests. The attack is straightforward—no authentication or user interaction is needed. An attacker simply crafts an HTTP/2 request with mismatched content-length and actual DATA frame sizes. The low complexity and lack of prerequisites make this a practical attack vector for exposed services, though the specific scope (low-level API usage) limits the number of vulnerable deployments in the wild.

Remediation

Upgrade to PSL 6.1.2 or 6.2.1 immediately. For version 6.1.x users, apply 6.1.2; for version 6.2.x users, apply 6.2.1. There is no documented workaround for versions 6.1.0–6.2.0 short of patching. Review your codebase to identify any direct instantiation of Psl\H2\ServerConnection; if found, prioritize patching. If you are using PSL only through its high-level APIs, you are not affected and no immediate action is required, though staying current with minor releases is advisable.

Patch guidance

Patches are available in PSL 6.1.2 and 6.2.1. Version selection depends on your current deployment: if running 6.1.x, upgrade to 6.1.2; if running 6.2.0, upgrade to 6.2.1. These point releases address only the validation gap and are considered safe for production deployment. Test the upgrade in a staging environment first to ensure compatibility with any custom extensions or integrations, though the fix is localized to HTTP/2 frame validation and should have minimal side effects.

Detection guidance

Monitor HTTP/2 traffic patterns for DATA frames whose byte counts deviate from declared content-length values, particularly on systems running PSL 6.1.0–6.2.0. Network-level detection is challenging; application logging is more reliable. If possible, instrument Psl\H2\ServerConnection with logging to capture frame-level details. Look for unusual request sizes, truncated payloads, or repeated stream resets. Intrusion detection systems (IDS) tuned to HTTP/2 anomalies may flag mismatched sizes if they perform deep inspection.

Why prioritize this

This vulnerability merits urgent patching for any organization using Psl\H2\ServerConnection directly. The CVSS score of 7.5 reflects high integrity impact with no confidentiality loss. Request smuggling is a well-established attack vector with real-world exploitation potential, and the fix is a simple upgrade with low deployment risk. However, the narrow scope (low-level API only) means most PSL users face no exposure, so inventory your codebase first to confirm exposure before broadly escalating.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects: Network-accessible attack vector (AV:N), low attack complexity (AC:L), no privilege or user interaction required (PR:N, UI:N), no scope change (S:U), no confidentiality impact (C:N), high integrity impact (I:H), and no availability impact (A:N). The integrity rating is driven by the attacker's ability to inject or truncate request data, deceiving downstream applications. The lack of availability or confidentiality impact prevents a critical rating, but the ease of exploitation and real-world consequences of request smuggling justify the HIGH designation.

Frequently asked questions

Are all PSL users affected?

No. Only applications directly using Psl\H2\ServerConnection to accept untrusted HTTP/2 client traffic are vulnerable. If you use PSL through its documented public APIs for async, collections, networking abstractions, or cryptography, you are not affected. Review your codebase for direct instantiation of ServerConnection.

What is request smuggling and why is it dangerous?

Request smuggling occurs when an attacker exploits inconsistencies in how HTTP requests are parsed—in this case, by declaring one content-length but sending different actual bytes. This can bypass application-level size limits, WAF rules, and validation logic, allowing attackers to inject malicious payloads or access unauthorized content. It is a protocol-level attack that is very difficult to detect at the application layer.

Is there a workaround if I cannot upgrade immediately?

There is no documented workaround. If you cannot upgrade to 6.1.2 or 6.2.1, consider disabling HTTP/2 support or restricting access to the affected ServerConnection to trusted clients only. Patching is the only reliable fix.

Do I need to validate request sizes in my application code after upgrading?

No. Once patched, PSL will correctly validate that DATA frame bytes match the declared content-length per RFC 9113. Your application should continue to enforce its own input limits as best practice, but the protocol-level validation gap will be closed.

This analysis is provided for informational purposes and based on the CVE description and vendor advisory. SEC.co does not guarantee the accuracy or completeness of this information. Organizations should verify patch availability and applicability against their specific PSL deployments. CVSS scores and severity ratings are as published by the vendor; organizations should conduct their own risk assessment. No exploit code or weaponized proof-of-concept is provided. Consult vendor documentation and security advisories for authoritative guidance on remediation and detection. Source: NVD (public-domain), retrieved 2026-07-27. Analysis generated by SEC.co (claude-haiku-4-5).