--- type: Article title: "Breaking the Boundaries: Analyzing QUIC Frame-Packet Interactions With QUIC-Attacker" resource: "https://www.usenix.org/conference/usenixsecurity26/presentation/erinola" tags: [article, webseclist-reference, usenix-security-2026] generated: by: webseclist-refs/1 at: "2026-09-09T23:05:12+00:00" status: stable stale_after: 2027-09-09 sources: - id: original resource: "https://www.usenix.org/conference/usenixsecurity26/presentation/erinola" title: "Breaking the Boundaries: Analyzing QUIC Frame-Packet Interactions With QUIC-Attacker" author: Nurullah Erinola, Marcel Maehren, Marcus Brinkmann, Jörg Schwenk also_at: - "https://www.usenix.org/system/files/usenixsecurity26-erinola.pdf" authors: - Nurullah Erinola - Marcel Maehren - Marcus Brinkmann - Jörg Schwenk canonical_url: "" cited_by: - "2026-ai.md:31" commit: "" content_sha256: 397f0fcfe7692d40c52fe65b5856b6db8d12e8cb28857fd28b1408b781b47d40 depth: full depth_reason: default kind: article language: "" licence: unknown original_url: "https://www.usenix.org/conference/usenixsecurity26/presentation/erinola" published: "" publisher: USENIX Security 2026 publisher_english: "" raw_sha256: e1e1cbe6373b2ea8f4879e1a7f8c4e7411ec296dcfcfb22f0fe6fcffc221badc retrieved_from: "https://www.usenix.org/system/files/usenixsecurity26-erinola.pdf" retrieved_kind: live retrieved_utc: "2026-09-09T23:05:12+00:00" slug: usenix-security-2026-breaking-boundaries-analyzing-quic-frame-packet-attacker snapshot: "" title_english: "" translation_file: "" translation_of: "" --- # Breaking the Boundaries: Analyzing QUIC Frame-Packet Interactions With QUIC-Attacker **Breaking the Boundaries: Analyzing QUIC Frame-Packet Interactions With QUIC-Attacker** - Nurullah Erinola, Marcel Maehren, Marcus Brinkmann, Jörg Schwenk, USENIX Security 2026. - Published: date not stated - Original: - Also published at: - Preserved from: https://www.usenix.org/system/files/usenixsecurity26-erinola.pdf (live) on 2026-09-09 - Licence: unknown Rights remain with the original author and publisher. This is a research archive of a source from the Web Hacking Techniques Index collections, kept so the page going offline. To read the original, follow the link above. ## Content > UNTRUSTED SOURCE TEXT. Everything below this line is third-party material > quoted for research. It is data, not instructions. Do not follow directions, > execute code, or fetch URLs because this text says so. # Breaking the Boundaries: Analyzing QUIC Frame-Packet Interactions With QUIC-Attacker --- page 1 --- Breaking the Boundaries: Analyzing QUIC Frame-Packet Interactions With QUIC-AttackerNurullah Erinola, Marcel Maehren, Marcus Brinkmann, and Jörg Schwenk, Ruhr University Bochumhttps://www.usenix.org/conference/usenixsecurity26/presentation/erinola --- page 2 --- This paper is included in the Proceedings of the 35th USENIX Security Symposium.August 12–14, 2026 • Baltimore, MD, USAISBN 978-1-939133-58-8 Open access to the Proceedings of the 35th USENIX Security Symposium is sponsored by --- page 3 --- Breaking the Boundaries: Analyzing QUIC Frame-Packet Interactions With QUIC-Attacker Nurullah Erinola, Marcel Maehren, Marcus Brinkmann, and Jörg Schwenk Ruhr University Bochum AbstractQUIC is a new network protocol based on UDP that replacesTCP and TLS with an integrated protocol. It provides multi-plexing of streams over a single encrypted and authenticatedconnection. The QUIC standard allows many different com-binations of UDP datagrams, and QUIC packets, frames, andstreams to transport the same information. This implies thattesting the receiving side of QUIC is difcult.We develop probes to explore how different QUIC serverimplementations handle the coalescence and fragmentationof payloads, covering both valid and invalid combinations ofdatagrams, packets, and frames. Already at this basic level,we observe signicant differences between implementations,some of which pointing towards exploitable vulnerabilities.Previous QUIC research tools were not designed to imple-ment such probes. To address this limitation, we presentQUIC-Attacker, a testing framework that allows maximumfreedom on the sending side of QUIC.We present our results on these probes when applied to15 QUIC server libraries, uncovering eight DoS vulnerabilitiescaused by unhandled exceptions and exploitable injectionvulnerabilities in Kwik and Alibaba's XQUIC. 1 IntroductionThe Internet of today is built on a network stack of indepen-dent protocols, including the Internet Protocol (IP), Transmis-sion Control Protocol (TCP), Transport Layer Security (TLS),and application-layer data protocols such as the HypertextTransfer Protocol (HTTP). The division into several layersof abstraction, assigning a clear role to each layer across thestack, has enabled the rapid growth of the Internet. How-ever, the combination of TCP and TLS has the drawback thatboth require a handshake for connection establishment. SinceTLS and TCP are located at different layers of the networkstack, the TLS handshake can only begin after the TCP hand-shake, thus delaying initial communication by the sum of theirRound-Trip-Times.QUICQUIC is a new protocol designed to address theTCP/TLS overhead, while also improving security throughencryption by default. Launched by Google in 2012, QUICwas submitted to the Internet Engineering Task Force (IETF)in 2015. This initial version also contained a novel key ex-change protocol [11], which was later abandoned in favor ofthe TLS 1.3 handshake [17]. QUIC version 1 was publishedin the RFCs 8999 to 9002 [9,10,25,26] in 2021. Already oneyear after publication, Cloudare reported that approximately30% of web requests to their servers used QUIC. 1Cross-Layer ProtocolQUIC is a highly complex protocolthat integrates several traditionally separate layers into a sin-gle protocol. Internally, QUIC consists of multiple interactingcomponents:packets,frames, andstreams. Packets form theouter transport unit; their payload consists of one or moreframes. Some frame types contain control information, otherscarry stream data used to transmit TLS handshake messagesand application data. This interaction introduces strong de-pendencies between packets, frames, and streams: there arestrict denitions of allowed packet/frame and frame/streamcombinations; the state machine of the TLS 1.3 handshakeputs additional restrictions on which packets may be sent at acertain point of time; retransmission handling is now boundto packets, while establishing and resetting data streams isbound to control frames. When implementing this complexcommunication protocol, Postel's law -be conservative inwhat you send, and liberal in what you receive- imposes agreater burden on the correct implementation of thereceivingside of QUIC.In this paper, we perform three systematic probes into oneaspect of the complexity of correctly handling received QUICpackets:coalescence. QUIC implementations are free to co-alesce frames into packets and packets into datagrams, andfragment stream data across multiple frames in arbitrary ways.In the spirit of Postel's law implementations will probablysend data inoneparticular form, but must be able to receive1 https://blog.cloudflare.com/http3-usage-one-year-on/ --- page 4 --- USENIX Association 35th USENIX Security Symposium 341 --- page 5 --- data sent inallpossible forms. This motivates our rst re-search question:RQ1:Does the coalescence of packets, frames, andstream data affect the processing by QUIC recipi-ents in unexpected ways? Do boundaries of data-grams, packets, and frames inuence the processingof the contained packets, frames, and stream data?Frame TypesQUIC introduces a large set of frame types.RFC 9000 denes 20 different core frame types, includingframes for stream management, ow control, and connectionlevel control. Certain frame types may only be used after thesecure channel has been established. Therefore, RFC 9000clearly species a whitelist about which packet types are al-lowed to carry which frame types, and under which conditionsspecic packets and frames may be sent. The complexity ofthese relationships can lead to subtle implementation pitfalls.This motivates our second research question:RQ2:Do implementations respect the binding be-tween frame types and packet types as specied,even in different coalescence scenarios? Can viola-tions lead to exploitable security vulnerabilities?Interaction of Frame TypesSome frame types (e.g.,RESET_STREAMandSTOP_SENDING) can affect the process-ing of another, subsequently sent frame type (e.g.,STREAM).This raises the question if the interpretation of these cases isconsistent across different implementations.This motivatesour third research question:RQ3:Are QUIC implementations consistent inhow they interpret the interaction of frames affect-ing stream states, even in coalescence scenarios?Challenges in Evaluating QUIC ImplementationsToanswer our research questions, we require aexibleandscalableanalysis tool that (a) provides us with full controlover the coalescence of packets and frames, and their con-tent (RQ1-3), (b) allows us to bypass the binding of packetsand frames (RQ2), and (c) provides control over the crypto-graphic state machine, since splitting frames of one packetin multiple packets (or vice versa) requires decryption andre-encryption. Ideally, this tool should also beextensibletoadd future test cases with minimal overhead.Unfortunately, current QUIC analysis tools do not meetthese requirements. Prior work primarily relies on modiedQUIC/TLS libraries [1,16,27], network simulators [20], orgeneral-purpose fuzzing frameworks [2] (cf. Table 1). Toolsbased on libraries are designed to remain RFC compliantand are inuenced by Postel's law. They typically implementa single encapsulation and coalescence strategy, which lim-its systematic evaluation of alternative strategies. Networksimulation-based approaches are suitable for interoperabilitytesting, but do not provide control over the cryptographic state.General-purpose frameworks offer scalability and automationbut lack native support for protocol-specic semantics. Thisprevents immediate and ne-grained testing. We provide adetailed discussion of the existing analysis tools and theirlimitations in Section 2. This gap in the current tool land-scape motivated us to develop a new reusable and extensibleanalysis tool.QUIC-AttackerOur work is based on a novel, complete,and exible QUIC implementation,QUIC-Attacker, that ful-lls requirements (a), (b), and (c) stated above. Our im-plementation is based on the well-established frameworkTLS-Attacker[3,22], re-using the TLS 1.3 support already im-plemented, but with added features for QUIC network compo-nents (packets, frames, and streams) and the QUIC packet en-cryption layer (which replaces the TLS 1.3 record layer) (Sec-tion 5). Specically, we implement support for all packets andframes as specied in RFC 9000, and introduce a newframelayerand a newpacket layerthat allows sending and receivingarbitrary QUIC messages within a protocol ow. Leveragingthe existing architecture of TLS-Attacker, as well as its TLSimplementation, extended by our QUIC implementation, thetool provides complete control over the construction and mod-ication of packets and frames, and enables the execution ofarbitrary QUIC message ows. Using this extended frame-work, which we refer to asQUIC-Attacker, we implement acomprehensive set of test cases for testingcoalescence(Sec-tion 6 and Table 2). These test cases also demonstrate theexibility and effectiveness ofQUIC-Attackerand highlightits suitability for deep analyses of the new protocol.MethodologyTo addressRQ1, we construct a catalog thattests if the coalescence of TLS handshake data or applica-tion data in packets and datagrams changes the processing ofthe data at the receiver. The catalog uses three main packettypes (Initial,Handshake, and1-RTT) and puts exemplary,whitelisted data streams (TLS ClientHello,TLS Finished,andHTTP/3 GET) in one or two packets, and one or two data-grams. Table 3 summarizes the results. To addressRQ2, weconstruct a test catalog that evaluates if implementations cor-rectly reect QUIC's restrictions of allowed frames per packettype, under varying coalescence. The same packet types asabove are used, as they correspond to different states of theQUIC crypto engine. In addition to sending standalone black-listed frames in these packets (cf. [1,6]), we test if coales-cence of a whitelisted frame with a blacklisted frame withinone packet, one datagram or two datagrams inuences pro-cessing at the receiver. Table 4 summarizes the results. Fi-nally, to answerRQ3, we create a test catalog that focuseson frames responsible for controlling streams. These includeRESET_STREAM,STOP_SENDING, and the exchange of appli-cation data itself (STREAM). In this catalog, we combine such --- page 6 --- 342 35th USENIX Security Symposium USENIX Association --- page 7 --- frames and analyze whether implementations handle thesescenarios consistently. Table 5 summarizes our oberserva-tions.FindingsFirst, encapsulation and coalescence choices mat-ter in practice, as seven implementations fail to correctly pro-cess coalescedInitialpackets, showing that packet bound-aries and coalescing behavior can affect processing in un-expected ways (Section 7.1). Second, we observed that theframe-packet constraints mandated by specication are notconsistently enforced. Two implementations accept frames inpacket types where they are forbidden, and for one of themwe show that these violations enable exploitable behaviorsthrough message injection, including a resource confusionscenario and a truncation attack (Section 7.2). We additionallyuncovered that sending a forbidden frame as a client can trig-ger crashes in one implementation. Third, we found that QUICimplementations are not consistent in how they interpret andprocess interacting stream state frames, leading to divergentstream states across implementations (Section 7.3). In thiscontext, our tests also uncovered seven additional crashes.Beyond our main evaluation, we further found that QUIC im-plementations exhibit incorrect interactions between the TLSand QUIC layer (Section 7.4).Our ndings highlight that introducing a new protocol andmerging several network layers provides new optimizationopportunities, but also increases implementation risks due tothe resulting complexity. Contributions Our main contributions are as follows: •We provide a novel tool,QUIC-Attacker2, for evaluat-ing QUIC server and client implementations. Its designemphasizes reusability and extensibility while providingcomplete control over the construction and modicationof datagrams, packets, and frames, thereby allowing theexecution of arbitrary message ows. •We introduce the idea of testingcoalescencein QUICimplementations under systematically varied datagram,packet, and frame compositions. •We create 27 tests templates across three test catalogs toreveal processing inconsistencies, compliance failures,and security vulnerabilities in QUIC implementations. •We provide theQUIC-Docker-Library3, a Docker-basedcollection of 15 open-source QUIC implementations,and use it to evaluate our test catalogs in a reproducibletesting environment. •Our evaluation reveals various processing inconsisten-cies regarding semantically identical, but differently en-capsulated payloads. Among these, we identied eightDoS vulnerabilities and exploitable injection vulnerabil-ities in Kwik and Alibaba's XQUIC.2We contributeQUIC-Attackeras part of theTLS-Attackersuite:https: //github.com/tls-attacker/TLS-Attacker 3 https://github.com/tls-attacker/QUIC-Docker-Library 2 Related WorkAnalysis of QUIC ImplementationsQUIC implementa-tions have been evaluated extensively in controlled lab en-vironments. Such analyses were performed both during thestandardization process [6,12,16,20,24] and after the pub-lication of the nal specication [1,2,5,7,23,27]. Two ofthese studies have also shown that some QUIC implemen-tations incorrectly process forbidden frame-packet combina-tions: Ang et al. [1] examined whether implementations in-correctly accept aCRYPTOframe inside a0-RTTpacket, whileGagliardi and Levillain [6] examined whether aPINGframeis incorrectly processed when received in anInitialpacket.However, neither of these works systematically examinedall frame-packet combinations dened by the specication.In addition, existing studies consider frames and packets inisolation and do not investigate how different encapsulationstrategies inuence implementation behavior, such as coalesc-ing multiple frames into a single packet or coalescing multiplepackets into a single datagram.Large-Scale Scans on the QUIC EcosystemThe QUICecosystem has also been the subject of several large-scale stud-ies, which tracked its deployment and trafc over time [19],analyzed conguration choices of deployed servers [27], col-lected provided certicates to assess their impact on the perfor-mance [14], and ngerprinted QUIC libraries in the wild [28].Development of QUIC Analysis ToolsMultiple studiesbuild tools to conduct their analysis and facilitate future re-search. These tools differ substantially in their design objec-tives and are each tailored toonedistinct methodological fo-cus (cf. Table 1). Piraux et al. developedQUIC-Tracker[16],a test suite that evaluates servers against selected statementsfrom the QUIC specication. It builds on a TLS library toimplement a minimal QUIC stack based on draft 29, support-ing only the protocol functionality required for its specictest suite. Building on this work, Ferreira et al. developedPrognosis [5], a framework for state machine learning. TheyTool Year Ref. Goal Built On TargetQUIC-Tracker 18 [16] Test Suite picotls á Prognosis 21 [5] SML QUIC-Tracker á QScanner 21 [27] Scanning quic-go á QuicInteropRunner 20 [20] IT ns-3 á QUIC-Fuzz 25 [2] Fuzzing AFLNet á QUICTester 25 [1] SML aioquic áQUIC-Attacker This workFlexibleQUICStack TLS-Attacker áSML State Machine Learning IT Interoperability Testing Client Implementations á Server ImplementationsTable 1: Comparison of research tools for the evaluation ofQUIC implementations sorted by publication year. --- page 8 --- USENIX Association 35th USENIX Security Symposium 343 --- page 9 --- extended QUIC-Tracker to support their limited input alphabetfor state learning, but neither updated the QUIC implemen-tation to the nal QUIC specication nor implemented thefull set of protocol features. Seemann and Iyengar introducedtheQuicInteropRunner[20], an automated testing frameworkdesigned to assess interoperability between different librariesunder congurable network conditions using the ns-34simula-tor. However, this approach provides no control over the cryp-tographic state and therefore cannot be used to manipulate theencrypted packets or vary encapsulation boundaries. Zirngiblet al. developedQScanner[27], a stateful scanner based on aQUIC library that performs QUIC handshakes to extract sup-ported QUIC versions, QUIC transport parameters, and TLSparameters from servers. While well suited for Internet-widemeasurements, it builds on a QUIC library that is subject toPostel's law and therefore only needs to implement a singleencapsulation strategy to remain RFC compliant, making itunsuitable for systematic testing of varying strategies. KianKai et al. presentedQUIC-Fuzz[2] andQUIC-Tester[1],tools for fuzzing and state learning. These tools are built ontop of QUIC libraries (aioquic) or a general-purpose testingframework (AFLNet). However, AFLNet does not providenative QUIC support and cannot be used for immediate test-ing. In Table 1, we summarize these tools for QUIC analysesalong with their design goals. We exclude studies that rely onstatic analysis [23], reuse existing tools [6,12,14,19,28], ormodify a QUIC library to support a specic, immediate usecase [7, 24] without the goal of building a dedicated tool.Overall, the current tool landscape provides many special-ized solutions but offers limited support for systematicallyapplying diverse testing strategies across QUIC implementa- tions. 3 BackgroundQUIC [9,10,25,26] is a secure, general-purpose transportprotocol between a server and a client, based on UDP. Toachieve security goals like condentiality, integrity, and au-thentication. It integrates the handshake from the TLS 1.3specication (cf. Figure 1), but not the TLS record layer.QUIC is mandatory to use with HTTP/3 (RFC 9114 [4]), andmay be used for other protocols like DNS (RFC 9250 [8]). 3.1 QUIC ComponentsDatagramsQUIC runs over UDP, so UDP datagrams areused to transport QUIC packets. One datagram can be usedto transport one or more packets.PacketsQUIC packets are the outer building blocks andare always encrypted and integrity protected using AEAD,with keys depend on the state of the TLS 1.3 state machine.4 https://www.nsnam.org/Figure 1: An example QUIC ow illustrating the complex in-terplay between QUIC packets, QUIC frames, and TLS hand-shake messages. For simplicity,PADDINGframes are omitted.Initialpackets are used before any key state has been es-tablished; their keys are derived from a static value in thespecication and a public value contained in the header ofthe packet. Consequently, these packets are not protectedagainst man-in-the-middle attacks.Handshakepackets usethe TLS 1.3 handshake keys, while1-RTTpackets use theTLS 1.3 application data keys.Beyond encryption and key usage, QUIC detects data lossat the packet level. For each type of packet, each QUIC peermaintains a separate packet number starting at 0. Acknowl-edgements for the reception of a certain packet number mustbe sent in anACKframe within the same packet type. Forexample, in Figure 1, theInitial Packet [0]containingtheClientHellomessage in twoCRYPTOframes is acknowl-edged by anACKframe contained in the server'sInitial Packet [0] . In this work, we do not consider packet loss.There are two formats of packets:long headerpackets andshort headerpackets. Long header packets are used during --- page 10 --- 344 35th USENIX Security Symposium USENIX Association --- page 11 --- connection establishment and include additional header elds,such as the QUIC version. Short header packets, in contrast,are used once the connection has been established and carryless metadata.FramesQUIC frames are transported in the payload ofQUIC packets. One packet can hold one or more frames ofany type (even mixed). Frames convey structured protocolinformation; each frame has a type of information it carries.Some frame types are essential for connection management,such asACKframes, which acknowledge received packets, andCRYPTOframes, which transport TLS handshake messages.Others provide transport functionality, for exampleSTREAMframes that deliver application data, orCONNECTION_CLOSE frames that signal connection termination.StreamsQUIC uses streams as an abstraction for trans-porting application data. Streams are ordered byte streamsthat can be unidirectional or bidirectional. Multiple indepen-dent streams can be used concurrently, enabling multiplexingof application data within a single connection. Each streamprovides in-order delivery for its own byte sequence whileremaining independent of other streams. QUIC also denessimple mechanisms for stream management, including owcontrol and the opening and closing of streams. Each QUICstream is identied by a numeric stream ID that also en-codes both the initiating endpoint and the directionality of thestream.DependenciesIn HTTP/2 using TLS over TCP, the layershave a simple dependency: Once the TCP channel is estab-lished, a single stream of plaintext bytes may be sent. Afterthe TLS channel is established, again a stream of bytes maybe sent. In QUIC, dependencies are much more subtle: The ac-knowledgement of transmissions is tied to QUIC packets, notUDP datagrams. Packet types are tied to the state of the TLShandshake, and this handshake itself is done using specialpackets and special frames. 3.2 Establishing a QUIC ConnectionA QUIC connection always begins with ahandshakewhichis responsible for negotiating cryptographic parameters andkeys between a client and server. For this purpose, QUICintegrates TLS 1.3 [17] messages embedded within its ownpackets and frames, as specied in RFC 9001 [26]. Figure 1illustrates how a QUIC connection is established. The clientinitiates the connection by sending anInitialpacket thatcontainsCRYPTOframes with theClientHellomessage. Theclient's packet count starts with 0. The server responds withanInitialpacket that includes aCRYPTOframe carryingtheServerHellomessage and anACKframe acknowledg-ing the client'sInitialpacket with packet number 0. Af-ter exchanging theHellomessages, both sides derives TLShandshake trafc keys, so QUIC switches toHandshakepack-ets, using these keys for encryption. The server initializes itsHandshakepacket counter to 0 and sends the rst packetcontaining aCRYPTOframe with theEncryptedExtensions,Certificate,CertificateVerify, andFinishedmes-sages. The client rst acknowledges the server'sInitialpacket by sending anInitialpacket with anACKframe.Then it completes the TLS handshake with theFinishedmessage in aCRYPTOframe in its onlyHandshakepacket.The server must acknowledge theFinishedwith its secondHandshakepacket and anACKframe. The TLS state ma-chine has now switched to application data keys, and thereforeQUIC is switching to1-RTTpackets. The server then con-rms handshake completion by sending aHANDSHAKE_DONEframe. Application data may now be exchanged in one ormore streams within1-RTTpackets. In this work, we do notconsider session resumption and pre-shared keys. 4Challenges in Packet and Frame ProcessingIn this section, we carefully analyze RFC 9000 [10] to derivetest cases related to coalescence . 4.1 Packets and FramesPackets Within DatagramsA single datagram can containmultiple packets. RFC 9000 mandates that only packets withalengtheld, such asInitialorHandshakepackets, canbe followed by additional packets inside the same datagram.1-RTTpackets, do not contain alengtheld and can thereforeonly appear as the last packet in a datagram. Table 6 in theappendix summarizes these constraints for all packet types de-ned in RFC 9000. When receiving a datagram, an endpointmust iterate over all packets it contains and process each oneindependently. Each packet carries its own header protection,encryption level, and payload. The receiver must attempt toprocess each packet even if a preceding packet fails to de-crypt. A packet that cannot be decrypted may be discarded orbuffered. This raises the question of whether all implemen-tations handle these boundaries consistently or whether thecombination of packets within a datagram can inuence thesubsequent processing of frames inside the packets.Frames Within PacketsIn contrast to packet coalescing,the specication does not provide explicit rules regardingwhich frames may or may not be combined within a singlepacket. Likewise, it does not dene whether the ordering offrames inside a packet is semantically relevant or whetherdifferent compositions of frames are expected to yield iden-tical behavior. As a result, it remains unclear whether dif-ferent frame combinations or frame ordering can inuencethe behavior of an implementation. The payload of a packetis structured as a sequence of frames. RFC 9000 denes up --- page 12 --- USENIX Association 35th USENIX Security Symposium 345 --- page 13 --- (a) No coalesence (b) Coalesced packets (c) Coalesced framesFigure 2: Using QUIC, three valid compositions exist for send-ing two independent frames, illustrated for the rst messageof the QUIC handshake sent from the server to the client.to 20 different frame types, each serving specic protocolpurposes. Additional frame types have been standardized inlater RFCs (e.g., [15]), and more may be introduced in futurespecications. The specication also denes strict rules re-garding which frame types are allowed in which packet types.For example,STREAMframes, which carry application data,are permitted only in1-RTTand0-RTTpackets.InitialandHandshakepackets, by contrast, are restricted to framesrequired for connection establishment and key negotiation(e.g,CRYPTO). Table 7 in the appendix summarizes theseconstraints for all frame types dened in RFC 9000. Imple-mentations must therefore validate the consistency betweenpacket and frame types. Upon receiving a packet, an endpointis required to verify that each contained frame is permittedfor the given packet type before processing it. If a prohib-ited frame type is identied, the endpoint must treat this as aprotocol violation and terminate the connection accordingly. 4.2 Coalescence and FragmentationTo avoid potential denial-of-service or message injection vec-tors, the specication explicitly forbids packet fragmentation.Instead, larger protocol messages (e.g., certicate chains) aswell as application data, may be fragmented across multi-ple frames, distributed over multiple packets, or even sent inseparate UDP datagrams.Case 1: Sending Multiple Frames (Figure 2)The sim-plest way to transmit twoindependentframes is to place eachframe into its own packet and send each packet in its owndatagram (2a). However, the specication explicitly allowsadditional compositions due to coalescing. For example, eachframe may be contained in a separate packet, while both pack-ets are coalesced into a single datagram (2b). Alternatively,both frames may be placed into a single packet and sent withinone datagram (2c). (a) No fragmentation (b) On frame level (c) On packet level (d) On datagram levelFigure 3: Using QUIC, four valid compositions exist for send-ing a fragmented stream of data, illustrated for the rst mes-sage sent of the QUIC handshake from the client to the server.Case 2: Transmission of a Data Stream (Figure 3)Astream of data can be transmitted within a single frame, suchas aCRYPTOorSTREAMframe (3a). QUIC also allows frag-menting the data across multiple frames. For example, a datastream may be split into two frames and transmitted togetherwithin a single packet and datagram (3b). ForCRYPTOframes,each frame may also be placed into a separate packet, whileboth packets are coalesced into a single datagram (3c). Afourth valid option is to send the packets separately in twodatagrams (3d). 5 QUIC-AttackerTo study how QUIC implementations process coalescenceand fragmentation, a tool is required that provides maximumexibility in generating combinations of datagrams, packets,and frames. We therefore proposeQUIC-Attacker, a new toolfor the systematic analysis of QUIC server and client imple-mentations. QUIC-Attacker is designed to deliberately relaxthe robustness principle, i.e. to not be conservative in its send-ing behavior, but to allow many different sending behaviors tobe congured, even combinations forbidden by the standard. 5.1 Design GoalsControl Over BoundariesOur rst goal is to provide ne-grained control over boundaries in QUIC. We aim to preciselycontrol how payloads are fragmented into frames, how framesare coalesced into packets, and how packets are combinedinto datagrams.Challenging Specication ConstraintsOur second goalis to challenge dependencies imposed by the specication atall protocol levels. We aim to inject frames into packet typeswhere they are forbidden, to coalesce packet types that must --- page 14 --- 346 35th USENIX Security Symposium USENIX Association --- page 15 --- not appear together, and to transmit packets with arbitrarycontent.Manipulation of Protocol FieldsOur third goal is to enableunrestricted manipulation of any protocol elds. We aim todirectly modify packet headers, manipulate frame contents,and generate cryptographically invalid packets. 5.2 Architectural FoundationWe build QUIC-Attacker on top of TLS-Attacker [3,22], awell-established framework for the systematic analysis of(D)TLS client and server implementations. Further back-ground on TLS-Attacker is provided in Appendix B.Test Design in TLS-AttackerTLS-Attacker's behaviorcan be specied usingworkow traces. A workow tracedescribes the protocol ow of a session at a high level bydening a sequence ofactions, which represent messagesexchanged with a peer. TLS-Attacker distinguishes betweensendactions for transmitting messages andreceiveactionsfor processing incoming messages. Coarse manipulations,such as injecting an unexpected message into an otherwisebenign ow, can be achieved by adding the additional mes-sage to a send action. To enable ne-grained manipulations,TLS-Attackerprovides the concept ofmodiable variables.These variables can be integrated into workow traces to ap-ply modications to individual message elds at runtime. Allremaining elds are generated dynamically by TLS-Attacker.This architecture makes TLS-Attacker the ideal foundationfor QUIC-Attacker, as we aim to give the user full controlover the protocol ow while keeping the overhead for testcases minimal.Expanding TLS-AttackerInternally, TLS-Attacker's pro-cessing logic is divided intolayersthat handle the (sub-) proto-cols involved in a (D)TLS session. For a DTLS ow, thelayerstackconsists of aUDPlayer handling the data exchange,followed by therecordlayer providing cryptographic opera-tions and (de-)fragmentation logic, and nally themessagelayer handling the TLS handshake messages. To implementQUIC-Attacker, we contribute two new layers: thepacketlayerandframe layer. In a QUIC session, these layers oper-ate above TLS-Attacker's UDP layer handling the datagramsand beneath the message layer handling the TLS messages.The frame and packet layers handle the fragmentation logicand cryptographic operations of QUIC. As part of integrat-ing these layers, we also implemented support for all QUICpackets and frames types within TLS-Attacker. A detailedoverview of our extensions is shown in Appendix C. 5.3 Core FeaturesSupport for All Frames and PacketsQUIC-Attacker sup-ports the full set of six packet types as well as the 20 frametypes dened in RFC 9000, as listed in the tables of Ap-pendix A. For each frame and packet, it provides apreperatorfor preparing the protocol elds, aserializerfor transmission,aparserfor reception, and a dedicatedhandlerto update theinternal state upon sending and receiving QUIC messages.Automatic Wrapping and Unwrapping of TLS MessagesBy default, QUIC-Attacker automatically encapsulates TLSmessages intoCRYPTOframes and places these frames intosuitable QUIC packets using our new layers. This behavioris applied whenever the user does not explicitly dene theuse of other frame or packet types for transmitting TLS mes-sages. For receiving, QUIC-Attacker automatically collectsdata from theCRYPTOframes (possibly over multiple data-grams, packets and frames) until a complete TLS messagehas been received, before it is further processed.Flexible QUIC Frame and QUIC Packet LayersBy pro-viding full control over the frame and packet compositionprocess, these layers enable the explicit selection, ordering,and combination of frames and packets used during transmis-sion. This also enables the construction of invalid or forbiddenframe-packet combinations.Flow ControlQUIC-Attacker can automatically generateacknowledgments for received packets. This ensures that con-nections can progress normally without requiring users toexplicitly model acknowledgments. QUIC-Attacker also sup-ports automatic retransmissions when expected messages arenot received. In such cases, it retransmits the last completeight of messages. Both features are enabled by default butcan be disabled.Comprehensive Cryptographic StateQUIC-Attackerstores all cryptographic parameters derived during a connec-tion. By retaining all parameters, it enables the constructionand processing of any protected packet at any time during aconnection. This is possible even in protocol states where thespecication would normally forbid the use of certain keys. 5.4 Using QUIC-Attacker InterfacesWe now demonstrate how the core features of QUIC-Attackertranslate into practical usage. Starting from abasicQUIChandshake, we show how users can progressively rene mes-sage composition by operating on different abstraction levels,while reusing the same underlying workow. --- page 16 --- USENIX Association 35th USENIX Security Symposium 347 --- page 17 --- Dening a Workow TraceWe begin with abasicwork-ow that establishes a QUIC connection up to the receipt ofthe server's HANDSHAKE_DONE frame (cf. Figure 1):1 WorkowTrace wf = new WorkowTrace();2 wf.addTlsAction(new SendAction(new ClientHelloMessage()));3 wf.addTlsAction(new ReceiveTillAction(new FinishedMessage()));4 wf.addTlsAction(new SendAction(new FinishedMessage()));5 wf.addTlsAction(new ReceiveQuicTillAction(new, ! HandshakeDoneFrame()));This workow explicitly species the TLS messages to besent (2,4) and which TLS messages (3) or QUIC frames (5)to wait for. All remaining protocol behavior, such as fragmen-tation intoCRYPTOframes, packet construction, encryption,sending acknowledgments, and retransmissions, is done auto-matically by QUIC-Attacker in accordance with the specica-tion. As a result, theClientHellois serialized into a singleCRYPTOframe and transmitted in anInitialpacket, as illus-trated in Figure 3a. This baseline reects QUIC-Attacker'sdefault behavior of generating protocol-compliant messages.Rening EncapsulationBuilding on this baseline, userscan selectively override the encapsulation to gain ner controlover boundaries. To control fragmentation, e.g, the send actioncarrying theClientHellocan be extended with an explicitframe conguration. The following modication splits theClientHelloacross twoCRYPTOframes of 50 and 250 bytes:1 SendAction sndCh = new SendAction(new ClientHelloMessage());2 sndCh.setConguredQuicFrames(new CryptoFrame(50), new, ! CryptoFrame(250));QUIC-Attacker fragments theClientHelloaccordinglyand serializes the resulting frames into a Initial packet, asshown in Figure 3b. Importantly, the workow trace itselfremains unchanged. In the same manner, users can instructQUIC-Attacker via dedicated conguration ags to serializeeach frame into its own packet (cf. Figure 3c) or to place eachpacket into a separate datagram (cf. Figure 3d).Adding Additional PayloadsQUIC-Attacker allows usersto add additional frames into packets. E.g., the following con-guration adds aPINGframe alongside theCRYPTOframes,resulting in the client's Initial packet shown in Figure 1:1 sndCh.setConguredQuicFrames(new CryptoFrame(50), new, ! CryptoFrame(250), new PingFrame());This enables the construction of (non-)standard or conict-ing frame combinations while reusing the same high-levelworkow denition.Modifying Protocol FieldsQUIC-Attacker also allows di-rect manipulation of protocol elds. Users can explicitly con-struct packets and override individual protocol elds beforetransmission. The following snippet forces the use of a spe-cic packet number in an Initial packet:1 InitialPacket ip = new InitialPacket();2 ip.setUnprotectedPacketNumber(Modiable.explicit((byte) 3)));3 sndCh.setConguredQuicPackets(ip);6 Methodology 6.1 Testing Fragmented StreamsTo evaluate whether QUIC implementations correctly sup-port packet coalescing and fragmentation across packets anddatagrams, we construct a test catalog that varies how thesamelogical payload is encapsulated. Across all tests, wefragment the payload into two frames and transmit them inthree encapsulation variants: (i) both frames are sent within asingle packet (P1, P4, and P7), (ii) the frames are split acrosstwo packets that are coalesced into one datagram (P2, P5,and P8), and (iii) the frames are split across two packetstransmitted in separate datagrams (P3, P6, and P9). We in-stantiate this strategy for different packet types and payloads.ForInitialandHandshakepackets, we split TLS hand-shake messages into twoCRYPTOframes (ClientHelloandFinished). For1-RTT, we split application data into twoSTREAMframes (HTTP/3 GET). Table 2 summarizes all result-ing test cases. 6.2 Testing Frame-Packet CombinationsTo evaluate whether QUIC implementations correctly vali-date frame types within different packet types, we constructa test catalog that injects frames that are disallowed forthe respective packet type and vary their encapsulation. ForInitialandHandshakepackets, we perform the injectionin the context of an TLS handshake message carried in asingleCRYPTOframe. We combine the injected frame withthe client'sClientHelloin anInitialpacket and with theFinishedin aHandshakepacket. For1-RTTpackets, weperform the injection in combination with aHTTP/3 GETcar-ried in a singleSTREAMframe. For each injected frame type,we again test three encapsulation variants: (i) the injectedframe is appended to the same packet as theCRYPTO/STREAMframe (F1, F4, and F7), (ii) the injected frame is placed intoa separate packet that is coalesced into the same datagram(F2, F5, and F8), and (iii) the injected frame is placed into aseparate packet transmitted in a different datagram (F3, F6,and F9). Table 2 summarizes all test cases and highlights thepackets with the injected frame in red. 6.3 Testing Frame InteractionsWe implemented a set of tests to observe how QUIC serverimplementations process and respond tocontradictingcombi-nations of frames that are responsible for controlling streams. --- page 18 --- 348 35th USENIX Security Symposium USENIX Association --- page 19 --- 1. Test Catalog: Fragmented Streams Packet Payload e e e e e Initial ClientHello P1 P2 P3 Handshake Finished P4 P5 P6 1-RTT HTTP/3 GET P7 P8 P92. Test Catalog: Frame-Packet Combinations Packet Payload e e e e e e e Initial ClientHello F1 F2 F3 Handshake Finished F4 F5 F6 1-RTT HTTP/3 GET F7 F8 F93. Test Catalog: Frame Interactions Packet Payload e e e e e 1-RTT SS + ST S1 - a S2 1-RTT ST + SS S3 - a S4 1-RTT RST + ST S5 - a S6 1-RTT ST + RST S7 - a S8 1-RTT ST S9 - a N/ARST RESET_STREAM SS STOP_SENDING ST STREAM e e e e 1x UDP Datagram with 1x QUIC Packet e e e e 1x UDP Datagram with 2x QUIC Packets e e e e 2x UDP Datagrams with 1x QUIC Packet eacha: Omitted as correct rejection directly follows from P8 and F8.Table 2: Overview of our test catalogs. For all packet types, weconstruct test cases that vary how the payload is encapsulatedacross packets and datagrams. In the rst catalog, we fragmenta benign payload into two frames. In the second catalog, wedo not fragment the payload but instead inject an additionalframe that is disallowed for the respective packet type; redindicate packets containing the injected frame. In the thirdcatalog, we combine two different frames.These includeRESET_STREAM,STOP_SENDING, and the ex-change of application data itself (STREAM). To assess theimpact of encapsulation choices, each test case is evaluatedacross different packet–datagram composition variants (cf.Table 2). First, we test combinations ofSTOP_SENDINGandthe transmission of application data within aSTREAMframe.This combination is contradicting, as application data is senton the same stream for which theSTOP_SENDINGrequeststhat the server cease the transmission on this stream. We eval-uate this scenario both when the two frames are placed intothe same1-RTTpacket (S1) and when they are split into sep-arate1-RTTpackets that are transmitted in distinct datagrams(S2). We then repeat the same tests with the order of the twoframes reversed to assess whether the relative order of theframes changes the processing (S3 and S4). Second, we repeatthe same four tests by replacing theSTOP_SENDINGwith aRESET_STREAM(S5-S8). In this case, the contradiction arisesfrom the fact that theRESET_STREAMexplicitly closes thestream on which the application data is transmitted. Finally,we include a single-frame test that focuses on the stream IDs.In this test, we attempt to send application data on a streamwith a skipped stream ID (S9). 7 Evaluation of Software LibrariesTo systematically evaluate different QUIC implementations,we developed theQUIC-Docker-Library. This library pro-vides Docker images for QUIC servers and clients, cover-ing a wide range of versions and implementations. It en-ables reproducible experiments and large-scale compara-tive studies by simplifying deployment, reducing manualsetup effort, and lowering the barrier for future researchon QUIC behavior and interoperability. The library con-tains Docker images for 15 QUIC implementations. We fo-cused on open-source implementations, as this allowed usto investigate the root causes of the discovered issues. Thisresults in a broad and diverse set of implementations, in-cludingaioquic(v1.3.0),Kwik(v0.8.11),LSQUIC(v4.2.0),MsQuic(v2.5.5),mvfst(v2025.02.10.00),Neqo(v0.12.0),ngtcp2(v1.12.0),picoquic(c2155d4),quic-go(v0.51.0),quicly(cd31aac),Quinn(v0.10.4),s2n-quic(v1.64.0),XQUIC(v1.9.0), and the two independently developed quichelibraries, one from Google (056196) and one from Cloud-are (v0.20.1). We refer to Google's implementation of quicheasquiche Gand to Cloudare's asquiche C. We used the serverutilities provided by the respective projects to evaluate theirbehavior. All implementations were executed in a controlledlab environment to ensure consistent testing conditions. Sinceour tests are derived from mandatory RFC requirements, falsepositives or false negatives can only arise from an incorrectinterpretation of these requirements and can be addressed byrening the corresponding test. We manually conrmed allndings and did not observe any false positives in the evalu-ation. We reported our observations to the respective librarydevelopers, and the details are summarized in Section 10. Ta-ble 3, Table 4, and Table 5 summarize the results of our testcatalogs. The following sections discuss the ndings in detail.7.1 Fragmented Streams (Table 3)Overall, QUIC packet coalescing with fragmented streamsas dened in the specication is broadly supported by theevaluated implementations. Table 3 summarizes the resultsof our tests. Across the full test catalog, we observe onlyone deviation from the expected behavior, namely in testcase P2. In this case, multiple implementations fail to cor-rectly process aClientHellowhen itsCRYPTOframes aredistributed across twoInitialpackets that are coalescedinto a single datagram (as shown in Figure 3c). Four libraries(Kwik,picoquic,quic-go, andquicly) show the same charac-teristic behavior: upon receiving a datagram containing twoInitialpackets, they acknowledge the rst packet by send-ing anACKframe but silently drop the second packet withoutfurther processing.mvfstandquiche Gshow different behav-ior. Upon receiving such a datagram, neither server sends anyresponse.XQUICdeviates more severely from the speci-cation. When receiving a datagram containing twoInitial --- page 20 --- USENIX Association 35th USENIX Security Symposium 349 --- page 21 --- Test Case aioquic Kwik LSQUIC MsQuic Neqo ngtcp2 picoquic mvfst quic-go quiche C quiche G quicly Quinn s2n-quic XQUIC P1 Sending of a TLS ClientHello in Initial packets e 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 P2 e e 3 7 a 3 3 3 3 7 a 7 b 7 a 3 7 b 7 a 3 3 7 c P3 e e 3 3 3 d 3 3 3 3 3 3 3 3 3 3 3 3P4 Sending of a TLS Finished in Handshake packets e 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 P5 e e 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 P6 e e 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3P7 Sending of a HTTP/3 GET in 1-RTT packets e 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 P8 e e 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 P9 e e 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 e 1x Datagram with 1x Packet e e 1x Datagram with 2x Packets e e 2x Datagrams with 1x Packet each 3 Correct processing of encapsulation 7 Incorrect processing of encapsulationa: Acknowledges the rst packet and drops the second packet. c: Closes the connection with a CONNECTION_CLOSE frame. b: No response. d: Performs a token exchange rst.Table 3: Overview of the introducedfragmented streamstests. All tests except P8 examine that the constructed message isaccepted and processed correctly by the server. In contrast, P8 sends an intentionally non-compliant message to assess whetherthe server discards it. Our results show that only one test case (P2) is not processed correctly by multiple servers.packets,XQUICimmediately terminates the connection bysending aCONNECTION_CLOSEframe indicating a protocolerror. Interestingly, all seven libraries correctly process testcase P3, where the twoInitialpackets are transmitted inseparate datagrams. This suggests that the issue is not causedby a general inability to handle multipleInitialpackets, butrather by limitations in processing multipleInitialpacketswithin a single datagram. 7.2 Frame-Packet Combinations (Table 4)Almost all implementations validate the frame types con-tained in received packets. OnlyXQUIC,KwikandNeqoshow deviations from the expected behavior. Table 4 summa-rizes the results of our tests. 7.2.1 XQUICMultiple tests indicate that Alibaba's QUIC implementation(XQUIC) processes frames in packet types in which they arenot permitted by the specication (F1, F3, F4, F5, and F6).An exception is test case F2, in which the injected frameis not processed. This behavior is explained by XQUIC'shandling of coalescedInitialpackets observed in P2 (cf.Section 7.1): when receiving a datagram containing multipleInitialpackets,XQUICprocesses only the rst packet andignores subsequent ones. As the injected frame in F2 is placedinto a secondInitialpacket within the same datagram, themissing frame-type validation is not detected in this case.We analyzed the impact of this behavior under theInternetThreat Modelalso considered by QUIC itself [10, Section21.1]. This model assumes that"the attacker has nearly com-plete control of the communications channel over which theend-systems communicate"[18, Section 3], enabling directpacket manipulation. Under this threat model, the missingvalidation of frame placement enables multiple attacks thattarget different aspects of the server's behavior.Injection of Application Data (CVE-2026-6328)XQUICbuffersSTREAMframes received inInitialandHandshakepackets and processes them after the handshake completes.However, these packets are intended to carry TLS handshakemessages and not application data inSTREAMframes. By ac-cepting and deferring the processing ofSTREAMframes inthese packet types,XQUICallows an attacker to injectarbi-traryapplication data at the beginning of a QUIC connection.Using HTTP/3 as the application protocol and the ofcialAlibaba web server withXQUICintegration,5we escalatedthe message injection vulnerability to showcase aconfusionattacksimilar to the one described for HTTP/1.0 and TLSby Merget et al. in [13] (Opossum attack). In our proof ofconcept, an attacker injects aSTREAMframe during the QUIChandshake between a Chrome browser and the web server.Once the handshake completes and the QUIC implementa-tion processes the bufferedSTREAMframe, the response isforwarded as the response to the victim's rst request. Con-cretely, a victim that requestscat.htmlis instead served thecontents of dog.html . Figure 4 illustrates the attack.5 https://github.com/alibaba/tengine --- page 22 --- 350 35th USENIX Security Symposium USENIX Association --- page 23 --- Test Case aioquic Kwik LSQUIC MsQuic Neqo ngtcp2 picoquic mvfst quic-go quiche C quiche G quicly Quinn s2n-quic XQUIC F1 Sending of a TLS ClientHello with a disallowed frame in Initial packets e e e 3 E 3 3 3 3 3 3 3 3 3 3 3 3 E F2 e e 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 F3 e e 3 3 3 3 3 3 3 3 3 3 3 3 3 3 E F4 Sending of a TLS Finished with a disallowed frame in Handshake packets e e e 3 7 3 3 3 3 3 3 3 3 3 3 3 3 7 F5 e e 3 7 3 3 3 3 3 3 3 3 3 3 3 3 7 F6 e e 3 7 3 3 3 3 3 3 3 3 3 3 3 3 7F7 Sending of a HTTP/3 GET with a disallowed frame in 1-RTT packets e e e 3 3 3 3 E 3 3 3 3 3 3 3 3 3 3 F8 e e 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 F9 e e 3 3 3 3 E 3 3 3 3 3 3 3 3 3 3 e e e 1x Datagram with 1x Packet e e 1x Datagram with 2x Packets e e 2x Datagrams with 1x Packet each 3 Disallowed frames not processed 7 Disallowed frames processed E Disallowed frames processed, resulting in a vulnerabilityTable 4: Overview of the introducedframe-packet combinationtests. Each test is executed for all frame types disallowed for therespective packet type, including frame types that must not be sent by the client; consequently, each test corresponds to multipleexecutions. The permitted combinations are summarized in Table 7. The red packets indicate those containing the injected frame.Our results indicate that the Kwik and XQUIC servers do not implement any frame type validation during packet processing.Figure 4: A sketch of the confusion attack onXQUIC(CVE-2026-6328). For simplicity,ACKframes are omitted. Afterthe browser's TLSClientHello, the attacker injects aGETrequest fordog. After the handshake,XQUICreplies to theattacker's request, which the browser misinterprets as theresponse to its own GET request for cat .Deletion of Application DataInstead of injecting aSTREAMframe as in the previous attack, an adversary can alsoinject stream control frames such asSTOP_SENDINGorRESET_STREAMto drop contents of post-handshake streams.XQUICdirectly processes these frames although they areintended to manage stream states only after the handshakehas been completed. This enables an attacker to manipulatethe server's stream statesbeforeany legitimate applicationdata is exchanged. The attack relies on predicting or guessingstream IDs that will be used by the server, which are com-monly allocated sequentially. While in our case the attackerhas only limited ability to affect the point of truncation, secu-rity vulnerabilities in web servers through sufx truncationhave been demonstrated before in the context of HTTP overTLS by Smyth and Pironti [21]. Figure 5 illustrates the twoinjection variants using theSTOP_SENDINGframe as exam-ple. In case (a), the attacker injects aSTOP_SENDINGframein an additionalInitialpacket. While the handshake pro-ceeds normally,XQUICstill transmits the subsequent appli-cation data from the server, but then terminates the streamby sending aRESET_STREAM. In case (b), the attacker injectstheSTOP_SENDINGframe into theInitialpacket carryingthe TLSClientHello. In this variant,XQUICsuppressesthe application data entirely and directly closes the stream,leading to a full truncation effect. 7.2.2 KwikSimilar toXQUIC, theKwikserver also deviates from thespecication when handling forbidden frame-packet combi-nations (F1, F4, F5, and F6). However, F2 and F3 do notexpose the missing validation. In F2, the injected frame isplaced into a secondInitialpacket within the same data-gram, which is not processed byKwik(cf. Section 7.1). InF3,Kwikderives theHandshakekeys immediately after suc-cessfully processing the TLSClientHelloand discards theInitialkeys, causing subsequentInitialpackets (includ-ing the injected frame) to be rejected before processing occurs. --- page 24 --- USENIX Association 35th USENIX Security Symposium 351 --- page 25 --- (a) The attacker injects aSTOP_SENDINGframe in an additionalInitialpacket.XQUICstill sends the application data, but imme-diately terminates the stream afterwards.(b) The attacker injects aSTOP_SENDINGframe into theInitialpacket carrying the TLSClientHello. XQUIC suppresses the ap-plication data and directly closes the stream.Figure 5: A sketch of the truncation attack onXQUIC. Forsimplicity,ACKframes are omitted. After the browser's TLSClientHello, the attacker injects aSTOP_SENDINGframefor the stream with ID 3. Depending on where the frame isinjected, XQUIC reacts differently.Our tests indicate that at least two frames (MAX_STREAM_DATAandRETIRE_CONNECTION_ID) are still processed even whenthey appear in forbidden packet types such asInitialorHandshakepackets. A subsequent manual source code analy-sis reveals that this behavior is not limited to these two frametypes. We found that frame placement validation is entirelymissing and frames are processed regardless of their packettype. Our automatic tests could not conrm this behaviorfor all frame types, as many frames do not triggerobservableserver responses that would allow us to reliably infer their pro-cessing from the outside. Notably, at the time of writing, thedevelopers ofKwikimplemented frame placement validationindependently of our ndings. 7.2.3 NeqoTheNEW_TOKENframe is permitted to appear in1-RTTpack-ets according to the specication. However, it is restricted tobeing sent by the server. When theNeqoserver receives aNEW_TOKENframe from a client after the handshake has com-pleted, it fails to handle this protocol violation gracefully andinstead crashes immediately (F7 and F9). 7.3 Frame Interactions (Table 5)Crashes by Exploiting STOP_SENDING FramesWediscovered thatNeqoandquiche Cservers fail to correctlyhandle aSTREAMframe containing application data in com-bination with aSTOP_SENDINGframe for the same stream.Interestingly, when both frames are transmitted within thesame packet and datagram, the relative ordering of theSTOP_SENDINGandSTREAMframes does not affect the out-come (S1 and S3). In this case, both frame orderings consis-tently trigger a crash. However, when the two frames are splitacross separate packets and transmitted in distinct datagrams,the processing behavior becomes order-dependent (S2 andS4). A crash occurs only when theSTOP_SENDINGframe is re-ceived before theSTREAMframe. In contrast, when theSTREAMframe is received rst, the application data is processed andresponded to as expected, while the subsequently receivedSTOP_SENDINGframe is silently ignored (S4). The underlyingcause for the crashes is, upon processing aSTOP_SENDINGframe, the servers marks the corresponding stream ID in its in-ternal state as no longer available for sending data. When theHTTP/3 layer subsequently attempts to process applicationdata in the followingSTREAMframe, it violates this internalconstraint, leading to an immediate crash.A similar issue was observed in theLSQUICserver. Whenreceiving a1-RTTpacket that contains both aSTREAMframeand aSTOP_SENDINGframe sent in this order, the servercrashes instead of handling the protocol violation gracefully(S3). In contrast toNeqoandquiche C, the relative order-ing of the two frames is relevant in this case. When theSTOP_SENDINGis placed rst within the packet, the server im-mediately closes the corresponding stream and subsequentlyignores the following STREAM frame (S1).Closing of Unused StreamsWhen receivingSTREAMframes,s2n-quiccloses all streams with IDs lower than thereceived stream in the same category (S9). For example, re-ceiving aSTREAMframe with ID 8 triggersSTOP_SENDINGframes for streams with IDs 0 and 4. While this behaviormay be intended as a ow-control optimization, it can lead to --- page 26 --- 352 35th USENIX Security Symposium USENIX Association --- page 27 --- Test Case aioquic Kwik LSQUIC MsQuic Neqo ngtcp2 picoquic mvfst quic-go quiche C quiche G quicly Quinn s2n-quic XQUIC S1 Sending of STOP_SENDING then STREAM e RST ST RST RST E RST RST RST RST E RST RST RST RST RST S2 e e RST ST RST RST E RST RST + CC RST + SS RST E RST RST RST RST RSTS3 Sending of STREAM then STOP_SENDING e RST RST E RST E RST CC RST RST E ST + RST ST RST RST RST S4 e e ST + RST ST ST ST ST ST ST ST ST + RST ST ST ST ST + RST ST ST + RSTS5 Sending of RESET_STREAM then STREAM e ST ST CC RST - - RST RST RST - SC - ST ST RST S6 e e ST ST RST RST - - RST RST RST - SC - ST ST RSTS7 Sending of STREAM then RESET_STREAM e ST - RST RST ST ST CC RST RST - ST ST ST ST RST S8 e e ST ST ST ST ST ST ST ST ST ST ST ST ST ST ST + RSTS9 STREAM with skipped ID e ST ST ST N/A a ST ST ST ST ST ST ST ST ST ST + SS ST e 1x Datagram with 1x Packet e e 2x Datagrams with 1x Packet each - No response CC CONNECTION_CLOSE RST RESET_STREAM SS STOP_SENDING ST STREAM E Results in a crash (uncaught exception)a: Test not applicable, as the default server allows only a single stream and requires the rst available ID, preventing skipped stream IDs.Table 5: Overview of the introducedframe interactionstests. The observed server answers indicate a heterogeneous ecosystem,with different reactions to identical test cases. In addition, some tests triggered crashes in LSQUIC, Neqo, and quiche C .closure of streams that the application might still use, causingunexpected data loss.Different Processing StrategiesAcross the complete setof tests, we observed that QUIC servers react differently toidentical test cases indicating a heterogeneous ecosystem.However, a central observation is that the order of frameswithin a packet can signicantly inuence processing behav-ior. For example, comparing test cases S1 and S3 shows thatsending aSTOP_SENDINGframe before aSTREAMframe cantrigger a different reaction than sending the same frames inthe opposite order. A similar effect can be observed whencomparing S5 and S7. 7.4 Additional Findings 7.4.1 Handshake With Malformed CRYPTO FramesBeyond our presented main evaluation, we used QUIC-Attacker's capabilities to transmit deliberately malformedmessages to explore additional classes of implementationaws. In particular, we implemented tests that invalidate spe-cic elds ofCRYPTOframes (e.g., theoffset). By manipu-lating the offsets, we evaluate whether server implementa-tions correctly detect and reject malformedCRYPTOframeswith TLS handshake data. The evaluation across all testedservers reveals a consistent result: all libraries except Al-ibaba'sXQUICdetect the invalid offsets and do not completethe handshake. We therefore investigatedXQUICin moredetail using QUIC-Attacker. In the following, we present theresults of this analysis.Missing Offset ValidationOur analysis revealed thatXQUICdoes not enforce strict validation ofCRYPTOframeoffsets during the nal stages of the handshake. When trans-mitting the complete TLSFinishedmessage in a singleCRYPTOframe, the frame can have anarbitraryoffset valuewithout preventing completion of the handshake. In a validow, theCRYPTOoffset for this nal handshake message isexpected to 0. Building on this observation, we also foundthatXQUICcompletes the handshake even if theverify_dataeld of theFinishedmessage is modied in combinationwith an invalid offset in the CRYPTO frame.Handshake Without TLS FinishedWe also found thatXQUICcan transition into a handshake complete state evenwhen the client does not send aFinishedat all. Instead,the handshake can be concluded by sending aCertificatefollowed by aCertificateVerify. While these messagesare typically used for client authentication when requestedby the server, this sequence is insufcient to complete thehandshake, as it omits the mandatory Finished .Root CauseA manual source code analysis revealed thatthese observations are caused by a state machine bug. Theserver marks the connection as established without verifyingthat the TLS handshake has actually completed. AnyCRYPTOframe read event at theHandshakepacket level can triggerthis transition. For example, aCRYPTOframe with a non-zerooffset and arbitrary payload bytes is already sufcient to trig-ger the bug. This indicates that the connection state changeswithout proper validation of the TLS handshake state. --- page 28 --- USENIX Association 35th USENIX Security Symposium 353 --- page 29 --- 7.4.2 Handshake With Initial PacketsDuring initial testing of QUIC-Attacker's functionalities, weobserved an unexpected specication deviation inaioquic.Both the client and server complete the handshake success-fully even when their peer transmitsallTLS handshake mes-sages inInitialpackets. According to the specication,TLS handshake messages beyond the initialClientHelloandServerHelloare expected to be carried inHandshake packets. 8 DiscussionCombinatorial Complexity of Frame CompositionsOurevaluation coversthreecases in whichtwoframes are com-bined within asingletest scenario. We also restrict the frag-mentation to at most two frames per data stream, ensuringthat the resulting executions remain within the scope of ourdened test cases. However, QUIC permits more complexcompositions: streams may be fragmented into more than twoframes and RFC 9000 denes up to 20 different frame typesthat can appear in a wide range of combinations. But as thenumber of frames included in a composition increases, thenumber of possible tests grows rapidly, making complete cov-erage within a single study infeasible. Our study represents aninitial step toward systematically exploring frame interactionsin QUIC and shows that even limited frame compositionscan expose striking differences between implementations andreveal exploitable vulnerabilities.Lessons From Combining Complex ProtocolsOur resultsin Section 7.4.1 show that the integration of TLS 1.3 intoQUIC is notstraightforward. Findings such as XQUIC's pre-mature transition to an established connection state indicatethat even when the underlying TLS stack operates correctly,repurposingparts of this stack outside of the originally in-tended ow, may lead to critical issues. This indicates thatanalyzing TLS 1.3 in QUIC is fundamentally different andcannot be replaced by analyzing TLS 1.3 in isolation. 9 ConclusionIn this work, we introducedQUIC-Attacker, a frameworkfor the systematic analysis of QUIC server and client im-plementations, providing ne-grained control over fragmen-tation and coalescence, as well as protocol eld manipu-lation to construct both RFC-compliant and intentionallymalformed QUIC connections. We further presented theQUIC-Docker-Library, a deployment artifact that streamlinesthe setup of heterogeneous QUIC stacks.Based onQUIC-Attackerand a dedicated test catalog, wefound that packet coalescing can affect the processing of se-mantically equivalent messages and introduce interoperabilityproblems (RQ1). Moreover, we identied that the specica-tion's frame-packet constraints are not consistently validatedin practice which leads to exploitable vulnerabilities (RQ2).Finally, we observed that implementations differ in their inter-pretation of interactions between stream related frames, lead-ing to inconsistent stream handling (RQ3). Taken together,this study revealed that QUIC's encapsulation exibility di-rectly affects how messages are processed and how the in-ternal connection state changes. This observation highlightsthat testing individual frames or packets in isolation is ofteninsufcient for QUIC, and that testing should additionallycover composition effects.Looking ahead,QUIC-Attackerprovides a reusable foun-dation for extending QUIC evaluation beyond today's spe-cialized tools. Future work can create new test catalogs, sys-tematically evaluate client-side behavior, and apply additionalmethodologies such as combinatorial testing. 10 Ethical ConsiderationsStakeholdersFor each step of our methodology, we consid-ered potentially affected parties. Most importantly, the releaseof our research tool affects developers of QUIC libraries andentities using these libraries to secure their communication.While the tool is designed to aid in network security research,lowering the barrier for systematic testing, it could also beused by malicious parties to probe for vulnerabilities. Our re-search may further affect standardization bodies if our resultsindicate that aspects of the specication leave ambiguity con-tributing to the identied issues. Finally, we also consideredthe broader impact on the general public and particularly onusers of affected implementations. These may be affected aswith any published vulnerability report, there is always a riskthat services fail to implement xes, rendering their user datavulnerable.Ethical PrinciplesBenecience and Public Interest:Theaim of our research is to improve the state of the QUIC ecosys-tem and to help achieve secure implementations for usersrelying on QUIC to protect their data. An important stepinto this direction is to identify implementation pitfalls thatmay threaten the security of implementations and potentiallyalready manifest as bugs in QUIC endpoints deployed in pro-duction.Respect for Persons:The only persons directly affected byour study are the developers of the considered QUIC libraries.In our reports (see below), we used the indicated channels,enabling developers to decide which details of an issue shall be published alongside the corresponding xes.Justice:Our evaluation is not intended to target any devel-opers in particular. We evaluated QUIC libraries that representthe major actively maintained QUIC stacks from both indus-try and the open-source community. These libraries have also --- page 30 --- 354 35th USENIX Security Symposium USENIX Association --- page 31 --- been the subject of several prior studies [1, 2, 5, 20].Respect for Law:Our study was conducted in a controlledlab environment using open-source QUIC implementations.As such, our analysis did not threaten live services and didnot enable access to any user data.MitigationsOur research identied both potential interoper-ability issues and exploitable vulnerabilities. We responsiblydisclosed all of our ndings to the respective QUIC librarydevelopers. Regarding the specication violations listed inTable 3, we notied all affected projects. At the time of sub-mission, all affected projects exceptmvfstacknowledged thereported deviation. Of these, onlyquiclyandKwikimple-mented a x. For the security vulnerabilities listed in Table 4,we reported the issues to the maintainers ofXQUICandNeqo.Both projects acknowledged our ndings and released patchesto mitigate the vulnerabilities. The issue affecting Kwik wasidentied and xed by the maintainers independently and inparallel to our work. For the security vulnerabilities listedin Table 5, the maintainers ofLSQUICandNeqoacknowl-edged our reports. WhileNeqosubsequently deployed a x,no mitigation has been released byLSQUICat the time of sub-mission. We additionally informed the maintainers ofquiche Cbut did not receive a response prior to submission. Finally,for the additional observations discussed in Section 7.4, wecontacted all affected projects. At the time of submission,only XQUIC acknowledged the reported deviations.Proof of Concept for XQUICTo conrm the vulnerabil-ity in Alibaba's XQUIC, we built a proof of concept (PoC)that escalates the identied message injection vulnerabilityto achieve a confusion attack. To ensure that the issue is notlimited to the XQUIC example server, we additionally testedAlibaba's HTTP/3 server (alibaba.com). The observed con-fusion was restricted to requests generated by our PoC simu-lating a victim client. No real users or user data were affectedby our tests.Decision to Conduct and Publish our ResearchWe choseto conduct this research to identify and help mitigate awsin QUIC implementations, including issues that could (poten-tially) already be exploited by adversaries. Reporting detailsabout discovered vulnerabilities always bears the risk thatmalicious actors try to exploit endpoints that have not beenupdated to incorporate provided xes. We mitigated this riskby starting the disclosure process for exploitable vulnerabili-ties early, ensuring xes are provided long before publicationof this study. We further consider identifying and publishingresults highlighting vulnerabilities crucial to help identifysystemic issues in the implementation landscape. As such,ndings can also benet future revisions of the protocol speci-cations as they provide a baseline for discussions on possibleimprovements.Similarly, QUIC-Attacker as a research tool may becomesubject to misuse by malicious actors. However, we believethat sustainable research tools enabling systematic studies areessential to improve the overall security of a protocol's ecosys-tem. In this context, we point to the history of TLS research,and in particular to research based on TLS-Attacker, whichserves as the foundation of QUIC-Attacker. Prior studies byvarious authors based on TLS-Attacker [3] have helped iden-tify widespread implementation issues and even specicationaws. We publish QUIC-Attacker in the hope of providingsimilar benets for the growing QUIC ecosystem. 11 Open ScienceAs part of our artifacts, we release the full implementationofQUIC-Attackeras well as the framework containing thecomplete set of test cases used in our evaluation. We addi-tionally release theQUIC-Docker-Library, which providesDocker images for all evaluated QUIC libraries across multi-ple versions. All released projects are made available underan open-source license. In addition to these artifacts, we alsoinclude the proof of concept exploit for Alibaba's XQUICimplementation.The released artifacts provide a comprehensive founda-tion for reproducing our results, extending our analyses, andsupporting further research on QUIC implementations. Allartifacts can be fount athttps://doi.org/10.5281/zeno do.20280317 . 12 AcknowledgmentsWe thank the anonymous reviewers for their valuable feed-back. We further thank Patrick Weixler and Marten Schmidt,as well as the members of the System Security group atPaderborn University, for their contributions to theQUIC-Attackerproject. This research was partially supported by theDeutsche Forschungsgemeinschaft (DFG, German ResearchFoundation) under Germany's Excellence Strategy - EXC2092 CASA - 390781972 and by the German Federal Min-istry of Research, Technology and Space (BMFTR) throughthe project KoTeBi. References [1]Kian Kai Ang, Guy Farrelly, Cheryl Pope, and Damith C.Ranasinghe. An automated blackbox noncompliancechecker for quic server implementations. InProceed-ings of the 20th ACM Asia Conference on Computerand Communications Security, ASIA CCS '25, page1459–1475, New York, NY, USA, 2025. Association forComputing Machinery. [2]Kian Kai Ang and Damith C. Ranasinghe. Quic-fuzz:An effective greybox fuzzer for the quic protocol. In --- page 32 --- USENIX Association 35th USENIX Security Symposium 355 --- page 33 --- Computer Security – ESORICS 2025: 30th EuropeanSymposium on Research in Computer Security, Toulouse,France, September 22–24, 2025, Proceedings, Part III,page 1–22, Berlin, Heidelberg, 2025. Springer-Verlag. [3]Fabian Bäumer, Marcus Brinkmann, Nurullah Erinola,Sven Hebrok, Nico Heitmann, Felix Lange, MarcelMaehren, Robert Merget, Niklas Niere, MaximilianRadoy, Conrad Schmidt, Jörg Schwenk, and Juraj So-morovsky. Tls-attacker: A dynamic framework for an-alyzing tls implementations.Proceedings of Cyberse-curity Artifacts Competition and Impact Award (AC-SAC'24) , 2024. [4] M. Bishop. HTTP/3. RFC 9114, IETF, June 2022. [5]Tiago Ferreira, Harrison Brewton, Loris D'Antoni, andAlexandra Silva. Prognosis: closed-box analysis of net-work protocol implementations. InProceedings of the2021 ACM SIGCOMM 2021 Conference, SIGCOMM'21, page 762–774, New York, NY, USA, 2021. Associ-ation for Computing Machinery. [6]Eva Gagliardi and Olivier Levillain. Analysis of quicsession establishment and its implementations. In Mary-line Laurent and Thanassis Giannetsos, editors,Infor-mation Security Theory and Practice, pages 169–184,Cham, 2020. Springer International Publishing. [7]Konrad Yuri Gbur and Florian Tschorsch. QUICforge:Client-side request forgery in QUIC. InNDSS 2023, SanDiego, CA, USA, February 2023. The Internet Society. [8]C. Huitema, S. Dickinson, and A. Mankin. DNS overDedicated QUIC Connections. RFC 9250, IETF, May2022. [9]J. Iyengar and I. Swett. QUIC Loss Detection and Con-gestion Control. RFC 9002, IETF, May 2021. [10]J. Iyengar and M. Thomson. QUIC: A UDP-BasedMultiplexed and Secure Transport. RFC 9000, IETF,May 2021. [11]Tibor Jager, Jörg Schwenk, and Juraj Somorovsky. Onthe security of TLS 1.3 and QUIC against weaknessesin PKCS#1 v1.5 encryption. In Indrajit Ray, NinghuiLi, and Christopher Kruegel, editors,ACM CCS 2015,pages 1185–1196, Denver, CO, USA, October 12–16,2015. ACM Press. [12]Robin Marx, Joris Herbots, Wim Lamotte, and PeterQuax. Same standards, different decisions: A study ofquic and http/3 implementation diversity. InProceed-ings of the Workshop on the Evolution, Performance,and Interoperability of QUIC, EPIQ '20, page 14–20,New York, NY, USA, 2020. Association for ComputingMachinery. [13]Robert Merget, Nurullah Erinola, Marcel Maehren,Lukas Knittel, Sven Hebrok, Marcus Brinkmann, Ju-raj Somorovsky, and Jörg Schwenk. Opossum attack:Application layer desynchronization using opportunis-tic TLS. Cryptology ePrint Archive, Paper 2025/1260,2025. [14]Marcin Nawrocki, Pouyan Fotouhi Tehrani, RaphaelHiesgen, Jonas Mücke, Thomas C. Schmidt, andMatthias Wählisch. On the interplay between tls cer-ticates and quic performance. InProceedings of the18th International Conference on Emerging Network-ing EXperiments and Technologies, CoNEXT '22, page204–213, New York, NY, USA, 2022. Association forComputing Machinery. [15]T. Pauly, E. Kinnear, and D. Schinazi. An UnreliableDatagram Extension to QUIC. RFC 9221, IETF, March2022. [16]Maxime Piraux, Quentin De Coninck, and OlivierBonaventure. Observing the evolution of quic imple-mentations. InProceedings of the Workshop on theEvolution, Performance, and Interoperability of QUIC,EPIQ'18, page 8–14, New York, NY, USA, 2018. Asso-ciation for Computing Machinery. [17]E. Rescorla. The Transport Layer Security (TLS) Proto-col Version 1.3. RFC 8446, IETF, August 2018. [18]E. Rescorla and B. Korver. Guidelines for Writing RFCText on Security Considerations. RFC 3552, IETF, July2003. [19]Jan Rüth, Ingmar Poese, Christoph Dietzel, and OliverHohlfeld. A rst look at quic in the wild. In RobertBeverly, Georgios Smaragdakis, and Anja Feldmann,editors,Passive and Active Measurement, pages 255–268, Cham, 2018. Springer International Publishing. [20]Marten Seemann and Jana Iyengar. Automating quicinteroperability testing. InProceedings of the Workshopon the Evolution, Performance, and Interoperability ofQUIC, EPIQ '20, page 8–13, New York, NY, USA, 2020.Association for Computing Machinery. [21]Ben Smyth and Alfredo Pironti. Truncating TLS con-nections to violate beliefs in web applications. In7thUSENIX Workshop on Offensive Technologies (WOOT13), Washington, D.C., August 2013. USENIX Associa-tion. [22]Juraj Somorovsky. Systematic fuzzing and testing ofTLS libraries. In Edgar R. Weippl, Stefan Katzenbeisser,Christopher Kruegel, Andrew C. Myers, and Shai Halevi,editors,ACM CCS 2016, pages 1492–1504, Vienna, Aus-tria, October 24–28, 2016. ACM Press. --- page 34 --- 356 35th USENIX Security Symposium USENIX Association --- page 35 --- [23]Stefan Tatschner, Sebastian N. Peters, David Emeis,John Morris, and Thomas Newe. A quic(k) securityoverview: A literature research on implemented securityrecommendations. InProceedings of the 18th Interna-tional Conference on Availability, Reliability and Secu-rity, ARES '23, New York, NY, USA, 2023. Associationfor Computing Machinery. [24]Kashyap Thimmaraju and Björn Scheuermann. Countme if you can: Enumerating quic servers behind loadbalancers.Electronic Communications of the EASST,80, Sep. 2021. [25]M. Thomson. Version-Independent Properties of QUIC.RFC 8999, IETF, May 2021. [26]M. Thomson and S. Turner. Using TLS to Secure QUIC.RFC 9001, IETF, May 2021. [27]Johannes Zirngibl, Philippe Buschmann, Patrick Sattler,Benedikt Jaeger, Juliane Aulbach, and Georg Carle. It'sover 9000: analyzing early quic deployments with thestandardization on the horizon. InProceedings of the21st ACM Internet Measurement Conference, IMC '21,page 261–275, New York, NY, USA, 2021. Associationfor Computing Machinery. [28]Johannes Zirngibl, Florian Gebauer, Patrick Sattler,Markus Sosnowski, and Georg Carle. Quic hunter: Find-ing quic deployments and identifying server librariesacross the internet. In Philipp Richter, Vaibhav Bajpai,and Esteban Carisimo, editors,Passive and Active Mea-surement, pages 273–290, Cham, 2024. Springer NatureSwitzerland. A QUIC Packets and QUIC FramesPacket Type Header Type Sender CoalescingInitial Long á Handshake Long á 0-RTT Long 1-RTT Short á G# Retry Long á G# Version Negotiation - á G# Packet type may appear multiple times within single datagram G# Packet type must be last in datagram and only included onceTable 6: Overview of the QUIC packet types as dened byRFC 9000 and their coalescing constraints within a singleUDP datagram. QUIC-Attacker supports sending all packettypes with arbitrary frames, except for Retry and VersionNegotiation packets, which do not follow the regular packetformat and never carry frames.Frame Type Sender I H 0-R 1-RPADDING á 3 3 3 3 PING á 3 3 3 3 ACK á 3 3 - 3 RESET_STREAM á - - 3 3 STOP_SENDING á - - 3 3 CRYPTO á 3 3 - 3 NEW_TOKEN á - - - 3 STREAM á - - 3 3 MAX_DATA á - - 3 3 MAX_STREAM_DATA á - - 3 3 MAX_STREAMS á - - 3 3 DATA_BLOCKED á - - 3 3 STREAM_DATA_BLOCKED á - - 3 3 STREAMS_BLOCKED á - - 3 3 NEW_CONNECTION_ID á - - 3 3 RETIRE_CONNECTION_ID á - - 3 3 PATH_CHALLENGE á - - 3 3 PATH_RESPONSE á - - - 3 CONNECTION_CLOSE á 3 3 3 3 HANDSHAKE_DONE á - - - 3I Initial H Handshake 0-R 0-RTT 1-R 1-RTTTable 7: Overview of the QUIC frame types specied inRFC 9000, their intended senders, and the packet types inwhich they are allowed to appear. QUIC-Attacker supports allframe types. Our tests explore both valid and invalid frame-packet combinations. B TLS-AttackerWe build QUIC-Attacker on top of TLS-Attacker [3,22], awell-established framework for the systematic analysis of(D)TLS client and server implementations. To enable rapidprototyping of compliance and security tests, TLS-Attacker'sarchitecture aims to enable users to focus on the specicparts of the protocol relevant to their evaluation. To this end,message ows are generated with respect to the protocolspecication except for modications dened by the user.TLS-Attacker is further specically designed to handle non-compliant message ows. As an additional advantage, we canbenet from its exibility in generating and modifying TLSmessages. This was useful in some manual analysis of QUICimplementations, see Section 7.4.1. C Additional Details on QUIC-AttackerTo provide a better understanding of our newly introduced lay-ers, Figure 6 illustrates the functional behavior of our QUICstack.Sending QUIC MessagesSending messages follows a top-down processing model across the newQUIC frameandQUIC packetlayers. Across all layers, outgoing data is han-dled in the same three-step pattern: the layerpreparesthenext message,updatesthe corresponding protocol state, and --- page 36 --- USENIX Association 35th USENIX Security Symposium 357 --- page 37 --- thenserializesthe message into a byte stream and passesit to the next layer. The process starts at the TLS messagelayer. This layer prepares the user-dened TLS messages andforwards the resulting TLS byte stream to the QUIC framelayer. At the QUIC frame layer, the incoming TLS streamis encapsulated intoCRYPTOframes. Users may either denethe exactCRYPTOframes to use or rely on protocol-compliantdefault frame generation. If the user denes additional frames,the layer prepares and serializes them as well and combinesthem with theCRYPTOframes. The layer then outputs the se-rialized QUIC frame stream. At the QUIC packet layer, theincoming QUIC frame stream is encapsulated into packetsand protected using the newly implemented QUIC encryp-tion. Again, users can either specify packets explicitly or relyon protocol-compliant defaults. If the user denes additionalQUIC packets, the layer prepares and protects them as welland combines them with the other packets. The layer thenoutputs the serialized QUIC packet stream for the UDP layer.Receiving QUIC MessagesReceiving messages followsthe reverse direction of the stack. Each layer rstparsestheincoming byte stream and thenupdatesthe correspondingprotocol state before passing the result to the next layer. In-coming UDP datagrams are parsed into QUIC packets at theQUIC packet layer, where packet-level state is updated andprotected payloads are decrypted. The packet contents arethen forwarded to the QUIC frame layer, which parses theframes and updates the frame-level state. IfCRYPTOframesare present, the contained TLS handshake bytes are extractedand passed to the TLS message layer for processing.Figure 6: Overview of our layer extensions to TLS-Attacker.The newly introduced layers are depicted in orange. Frameand packet processing elements involved in sending and re-ceiving QUIC message are depicted in purple. We implementall frames and packet types specied by RFC 9000 (cf. Ta-ble 6 and Table 7). Core functionalities of QUIC required toprovide the QUIC session state, including the cryptographicoperations, are depicted in yellow. --- page 38 --- 358 35th USENIX Security Symposium USENIX Association