GHSA-vxj7-4xrp-5vr4 is a medium-severity (CVSS 5.9) CWE-74 vulnerability in aiosmtplib. O3 Security confirms whether GHSA-vxj7-4xrp-5vr4 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
aiosmtplib: STARTTLS response injection
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-vxj7-4xrp-5vr4.
Real-World Exposure
aiosmtplibReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Impact
When a connection is upgraded with STARTTLS, aiosmtplib reads the server's 220 go-ahead reply and immediately performs the TLS handshake without discarding any data still sitting in the receive buffer. Bytes the protocol read off the plaintext socket before the handshake survive across the plaintext→TLS boundary (the asyncio transport is swapped in place, so the protocol object and its buffer are reused), and are then parsed as though they had arrived inside the TLS session.
Who is affected: Any caller that uses STARTTLS by passing start_tls=True or start_tls=None when the server advertises STARTTLS, and whose traffic can be intercepted by an active network attacker on the plaintext leg of the connection.
A man in the middle can send, in a single segment immediately after the client's STARTTLS command, the 220 reply followed by attacker-chosen response lines (e.g. 220 Go ahead\r\n250-mx.evil\r\n250 AUTH LOGIN\r\n). aiosmtplib consumes only the 220, leaves the injected lines buffered, completes the handshake, and then parses the attacker's pre-staged plaintext as the first post-TLS server response. This also desynchronizes every subsequent command/response pair inside the "encrypted" session.
Not affected: Connections using implicit/direct TLS (use_tls=True) have no plaintext phase and are not vulnerable. The attack requires an active man in the middle via network compromise; a passive eavesdropper cannot exploit it.
Patches
A fix is available in aiosmtplib 5.1.2. All earlier versions that support STARTTLS are affected; upgrade to 5.1.2 or later.
The fix treats any data buffered after the 220 STARTTLS reply and before the handshake as a protocol violation, per RFC 3207 §4.2 ("the client MUST discard any knowledge obtained from the server … which was not obtained from the TLS negotiation itself").
Workarounds
If you cannot upgrade immediately:
- Use implicit TLS instead of STARTTLS. Connect with
use_tls=True. This removes the plaintext phase entirely. - If STARTTLS is unavoidable, restrict connections to servers reached over a trusted network path.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | aiosmtplib | all versions | 5.1.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for aiosmtplib. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update aiosmtplib to 5.1.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vxj7-4xrp-5vr4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-vxj7-4xrp-5vr4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-vxj7-4xrp-5vr4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vxj7-4xrp-5vr4 in your dependencies?
O3 detects GHSA-vxj7-4xrp-5vr4 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.