# imap: StartTLS stripping attack (CVE-2016-0772).

Ruby net/imap starttls silently ignores non-OK server responses, letting a MITM strip STARTTLS and capture plaintext LOGIN/AUTH credentials.

- Payout: hidden
- Severity: medium
- Program: Ruby
- Found by: sighook
- Disclosed: 2021-07-08
- CVE: CVE-2021-32066, CVE-2016-0772
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/1178562
- Library page: https://bugbountylibrary.com/r/h1%3A1178562
- Tags: area:oss domain:oss impact:data-leak kind:bounty platform:hackerone sev:medium tech:ruby technique:source-review vuln:auth-bypass vuln:info-disclosure vuln:misconfiguration

**Target:** Ruby net/imap library starttls method
**Root cause:** starttls only calls start_tls_session when the tagged response is OK; any NO/BAD or unexpected response is silently ignored instead of raising, so the caller proceeds unencrypted.
**Steps:**
1. Run `python striptls.py -l 0.0.0.0:9999 -r imap.yandex.ru:143 -x IMAP.StripWithError`
2. Client: `imap = Net::IMAP.new('0.0.0.0', 9999); imap.starttls; imap.login('myLOGIN','myPASSWORD')`
3. Proxy rewrites server reply to `RUBY0001 BUG unhandled command`
4. starttls returns without error; client sends `RUBY0002 LOGIN myLOGIN myPASSWORD` in cleartext through proxy
**How found:** Code reading of starttls showed the OK branch was the only path invoking TLS, with no else/raise; hypothesis that a failed negotiation is silently swallowed was confirmed with a stripping proxy.
**Exploitation:** MITM positioned between client and IMAP server intercepts the STARTTLS command and returns a non-OK tagged response; the library silently continues, so subsequent LOGIN/AUTHENTICATE credentials traverse the network in plaintext and are captured by the attacker.
**Insight:** When auditing TLS-upgrade helpers, check whether the failure branch raises or silently returns; a missing else after the OK check is a classic stripping vector, and default usessl=false makes it reachable.