[GHSA-mfx4-hv73-q22v] AIOHTTP: HTTP request smuggling via WebSocket upgrade

[JVBotelho]

Updates

• References

Comments
Adding two references documenting public reproduction of this issue.

The advisory notes that no public exploit code was known at publication.
That is now out of date: a containerised lab pinning aiohttp 3.14.1 and
3.14.2 reproduces the parser behaviour end to end, with proof-of-concept
code in Python and Rust.

The analysis adds one detail that is operationally relevant and not in the
current advisory: the WebSocket proxy configuration published in the Nginx
documentation is the configuration that produces the desync, and
await request.read() returns zero bytes on the affected request, so the
body cannot be drained from application code. The write-up covers detection
and mitigation alongside the reproduction.

No changes proposed to severity, affected versions, CWE, or description —
the existing values match what I measured, including the CVSS v4 vector
(VC:N/VI:L), which is consistent with the demonstrated impact being blind
handler invocation rather than response disclosure.

Disclosure: I am the author of both references.

[github]

Hi there @Dreamsorcerer! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[Dreamsorcerer]

Publishing (and then advertising) exploit code is not being helpful (except to malicious attackers)..
We deliberately don't publish exact details in our advisories to avoid aiding and accelerating potential attacks.

[JVBotelho]

Understood — closing this.

Briefly, so my reasoning isn't a mystery: the fix shipped in 3.14.2 and the
patch commit is already linked from the advisory, so I approached this as
post-patch analysis rather than a drop. The write-up leads with mitigation
and covers what the desync looks like in proxy logs, because the finding I
thought was worth documenting is that the WebSocket configuration in the
Nginx docs is the one that's affected, that seemed useful to people running
that setup.

I understand you see the tradeoff differently, and this is your project and
your advisory. I'm not going to push a link into it over your objection.

Thanks for the fix and the fast turnaround on it.