Following our company motto, today we're sharing a powerful tool and methodology for penetration testers and security professionals, designed to make your job easier. Recent research demonstrates that race condition vulnerabilities, traditionally considered hard to verify and highly unreliable, are now completely deterministic and critical to fix.
Historically, a race condition has been treated as a stochastic timing bug: two requests arrive so close together that a server performs an action that is normally not permitted, such as letting a single-use discount code be redeemed multiple times. For years, these bugs were treated as flaky and unreliable to exploit in the wild.
To date, Single-Packet Attacks (SPA) relied entirely on aligning multiple request frames into a single network packet over the wire. However, SPA cannot work effectively when proxy buffering is enabled at the edge. Reverse proxies, edge servers, and load balancers buffer, deserialise, and re-batch incoming frames before forwarding them, completely destroying network-level packet alignment before the requests ever reach backend application frameworks.
Even if packets bypass edge buffering intact, modern runtimes like Go (net/http) and .NET (Kestrel) remain uniquely resilient against SPA due to their strict internal I/O handling. These frameworks parse stream frames sequentially off the underlying socket buffer, applying state-machine and flow-control checks per stream before handing requests off to application logic. As requests are dispatched across Go goroutines or .NET ThreadPool workers, the runtime scheduler introduces sub-millisecond execution offsets between threads. This combination of serial socket parsing and asynchronous dispatch jitter staggers execution, rendering traditional SPA flaky and ineffective against modern stacks and necessitating Server-Side Race Orchestration (SSRO) to achieve deterministic concurrency.
Presented at Black Hat USA 2026 Briefings by Foregenix's own Efstratios Chatzoglou, alongside researchers Georgios Kambourakis, Vyron Kampourakis, and Angelos Stavrou, the briefing"Chaos by Design: The Death of Stochastic Race Conditions in HTTP/3" obsoletes the old paradigm. The research proves that attackers no longer need to rely on network timing, they can now deterministically orchestrate the server itself.
By exploiting HTTP/3, the newest version of the web's core protocol, attackers can leverage two novel attack classes: Temporal Hijacking and Server-Side Race Orchestration (SSRO). These methods shift timing control to the protocol's internal state. By manipulating QPACK Head-of-Line (HoL) blocking, dynamic table saturation, and RFC 9218 priorities, attackers can build an internal "crowded waiting room" directly within the proxy’s memory.
Instead of fighting proxy buffers, SSRO exploits them, achieving 96.4% execution precision and triggering transaction-limit violations at 20 times the intended cap. With 87% of 10,000 top-ranked domains found vulnerable, this is a pervasive architectural issue that demands immediate attention.
To automate these attacks, Efstratios released TimeOrch, an open-source HTTP/3 orchestration framework. All source code and modules are available on our GitHub repository: https://github.com/efchatz/timeorch.
| Engine Component | Function |
| timeorch (Core CLI) | The main execution engine used to manage QUIC connections and trigger server-side timing exploits. |
| Probe Engine | Fingerprints edge proxies to evaluate QPACK capacities, QUIC stream limits, and proxy buffering behaviors. |
| SSRO Module | Executes Server-Side Race Orchestration by saturating QPACK dynamic tables and inducing controlled Head-of-Line (HoL) blocking (RFC 9204). |
| Temporal Hijacking | Manipulates RFC 9218 stream priorities and QPACK decompression delays to force out-of-order execution in backend application logic. |
To exploit an SSRO vulnerability using TimeOrch, an attacker first confirms that the target supports QUIC and utilizes a proxy that handles QPACK decompression.
The exploitation process is highly orchestrated:
Connect to the HTTP/3 interface and deliberately saturate the QPACK dynamic table.
Fragment QUIC streams to induce intentional Head-of-Line (HoL) blocking in the proxy.
This forces the proxy to buffer all subsequent incoming requests in a suspended state, creating a "crowded waiting room" in memory.
Release the blocking frame, prompting the proxy to instantly dump the entire batch of requests into the backend over the local network loopback.
Because this release happens internally on the server side, network jitter is eliminated, allowing requests to execute concurrently across application worker threads. Figure 1 visualizes this process.
We initiate the SSRO attack against a target endpoint using timeorch.py with case 2, subcase 2.1. In this scenario, we attempt to exploit a coupon redemption endpoint using the payload {"coupon_code": "RACE2024"}.
Bash
% python3 timeorch.py --case 2 --subcase 2.1 --domain target-app.shop --endpoint /s1/pg/attack --encoding json --body '{"coupon_code": "RACE2024"}' --timeout 4
[ 0.150s] Phase 1: Sending 10 POSTs to https://target-app.shop/s1/pg/attack with application/json and (Body size: 27 bytes)
[ 0.152s] Phase 1 complete. Sleeping 2.0s...
[ 2.155s] Phase 2: Releasing instructions...
[ 2.211s] Response 8 [Status 200] | Body: {"success":true,"code":"RACE2024"}
[ 2.211s] Response 20 [Status 200] | Body: {"success":true,"code":"RACE2024"}
[ 2.211s] Response 4 [Status 200] | Body: {"success":true,"code":"RACE2024"}
[ 2.212s] Response 12 [Status 200] | Body: {"success":true,"code":"RACE2024"}
[ 2.213s] Response 0 [Status 200] | Body: {"success":true,"code":"RACE2024"}
[ 2.214s] Response 32 [Status 200] | Body: {"success":true,"code":"RACE2024"}
[ 2.214s] Response 24 [Status 200] | Body: {"success":true,"code":"RACE2024"}
[ 2.214s] Response 28 [Status 200] | Body: {"success":true,"code":"RACE2024"}
[ 2.214s] Response 16 [Status 200] | Body: {"success":true,"code":"RACE2024"}
[ 3.218s] Done.
Phase 1 (0.150s - 0.152s): TimeOrch pre-stages 10 POST requests directly into the proxy's internal memory buffer while forcing HoL blocking.
Phase 2 (2.155s): The tool sends the final unblocking frame, instantly releasing all held instructions to the backend application server.
Execution (2.211s - 2.214s): Within a window of just 3 milliseconds, the backend server processes all queued requests concurrently. Every request returns a 200 OK status with {"success":true,"code":"RACE2024"}, confirming multiple redemptions of a single-use coupon code.
Standard mitigations for race conditions often rely on web application firewalls (WAFs) or network-level rate limiting, neither of which are effective against SSRO since the attack exploits the very proxy buffers meant to protect the backend. Shockingly, many major vendors currently dismiss these architectural findings as "working as intended" under strict protocol RFC interpretations.
Until structural protocol patches are issued, organisations must defend their backends by:
Adopting Pessimistic Locking: Developers must implement strict pessimistic locking on critical state transitions (e.g., database rows handling financial transactions or inventory limits) to survive these microsecond-level execution bursts.
Hardening Binaries: Infrastructure teams should configure or recompile edge proxy and load balancer binaries with security-hardened settings that strictly limit internal buffering and QPACK capacities. Specifically, set SETTINGS_QPACK_MAX_TABLE_CAPACITY and SETTINGS_QPACK_BLOCKED_STREAMS to 0, the default values specified in RFC 9204 to prevent dynamic table saturation and eliminate HoL blocking at the edge server.
Chaos by Design proves that we must rethink our approach to timing vulnerabilities. By shifting from network timing to server-side orchestration, the TimeOrch framework gives security teams the power to test for these issues deterministically, proving that what was once considered a "flaky" bug is now a reliable, weaponised exploit vector.