CVE-2026-35191 in OpenSSL
Summary
by MITRE • 09/29/2026
Issue summary: The OpenSSL QUIC server, when configured to not preform address validation, can be forced to count incoming packets multiple times in its unvalidated credit computation, leading to a violation of the RFC 9000 unvalidated connection amplification limit of 3 times the amount of data received.
Impact summary: A remote attacker able to spoof packets to a server using the OpenSSL QUIC implementation might use the server for an amplification of a DDoS attack.
CWE: CWE-440: Expected Behavior Violation
Description: OpenSSL's QUIC stack, when operating as a server, enforces client address validation (RFC 9000, Section 8), to confirm the peer address is not used for a traffic amplification attack. If this feature is disabled on the server, the QUIC stack limits the amount of server data that can be sent to 3 times the amount of data received from the peer address, until such time as the TLS handshake is completed.
The OpenSSL QUIC server, when operating in non-validation mode, adds the length of the whole datagram received to the unvalidated credit limit when processing each QUIC packet in the datagram. A remote peer may, after establishing a connection with an initial client hello frame, send a subsequent datagram containing multiple QUIC packets, leading the server to account the entire datagram length for each packet in the datagram, resulting in the server believing that the peer has sent more data than it actually has, thereby violating the 3x amplification limit mandated by the RFC.
FIPS impact: no As the QUIC stack lives outside the FIPS module boundary, no FIPS modules are affected by this CVE.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The OpenSSL implementation of the QUIC protocol contains a critical logic flaw in its unvalidated credit computation mechanism when address validation is disabled on the server side. Under normal operational conditions governed by RFC 9000 Section 8, servers enforce client address validation to prevent traffic amplification attacks. This standard mandates that until the TLS handshake is completed and the peer's identity is verified, a server must strictly limit its response data volume to no more than three times the amount of data received from the peer. This constraint serves as a fundamental defense against reflection-based Distributed Denial of Service (DDoS) attacks by ensuring that an attacker cannot leverage the server to amplify traffic significantly beyond their initial input bandwidth. However, when this address validation feature is explicitly disabled for performance or configuration reasons, the internal accounting logic fails to adhere to these safety boundaries due to a miscalculation in how received datagram lengths are attributed to individual packets within those datagrams.
The technical root cause of this vulnerability lies in the processing loop that handles incoming QUIC packets contained within UDP datagrams. When a server receives a single UDP datagram containing multiple distinct QUIC packets, it is supposed to sum the payload sizes of these packets to determine the total data received from the peer for credit calculation purposes. Instead, the flawed implementation adds the length of the entire outer datagram to the unvalidated credit limit for every individual packet found within that datagram. For example, if a single UDP datagram carries three QUIC packets each with small payloads but is encapsulated in a larger datagram structure, the server incorrectly attributes the full datagram size as received data for each of those three packets. This results in the unvalidated credit limit being inflated by a factor equal to the number of packets per datagram rather than reflecting the actual byte count transmitted by the peer. Consequently, the server believes it has received significantly more data from the client than is physically true, allowing it to send out proportionally larger amounts of response traffic before triggering internal limits or completing the handshake verification process.
This logic error directly enables a remote amplification attack vector against servers configured without address validation. A malicious actor capable of spoofing source IP addresses can exploit this discrepancy by sending carefully crafted datagrams containing multiple QUIC packets to trigger the inflated credit calculation. By doing so, the attacker forces the server to believe it has received sufficient data to justify transmitting much larger volumes of response traffic back to a victim's address. This effectively turns the vulnerable OpenSSL QUIC server into an amplifier for DDoS attacks against third-party targets. The severity is compounded by the fact that many high-performance servers may disable strict address validation under specific load-balancing or latency-sensitive configurations, inadvertently exposing them to this exploitation scenario. The attack does not require authentication or complex handshake manipulation beyond establishing a connection with an initial client hello frame, making it relatively straightforward for an attacker with basic networking capabilities to execute.
From a classification perspective, this vulnerability aligns closely with CWE-440 Expected Behavior Violation as the core issue is a deviation from the specified protocol limits defined in RFC 9000. It also maps to MITRE ATT&CK techniques related to Network Service Scanning and potentially Resource Hijacking if leveraged for sustained amplification, though it primarily facilitates reflection attacks rather than direct resource consumption on the target host itself. The vulnerability is categorized as a logic error within the application layer protocol implementation rather than a memory corruption or buffer overflow issue. It highlights the risks associated with disabling security controls like address validation in favor of performance metrics without fully understanding the downstream implications for traffic accounting and rate limiting mechanisms.
Mitigation strategies must prioritize re-enabling client address validation on all OpenSSL QUIC servers unless there is an absolute operational necessity to disable it, which should be evaluated against the amplified risk profile. If disabling validation remains a requirement due to specific network architecture constraints such as internal trusted networks or specialized load balancers that handle connection tracking differently, administrators should implement strict rate limiting and packet inspection at the network perimeter using firewalls or DDoS mitigation appliances. These external controls can detect and block anomalous traffic patterns indicative of amplification attempts before they reach the application layer. Additionally, applying the latest patches from OpenSSL vendors is critical as this flaw has been addressed in updated releases that correct the credit calculation logic to properly sum individual packet lengths rather than duplicating datagram sizes across all contained packets. Continuous monitoring for unusual outbound traffic spikes originating from QUIC-enabled services can also serve as an early detection mechanism for potential exploitation attempts while patching efforts are underway.