# Denial of Service by memory exhaustion in net/imap

net-imap allocates memory for server-declared literal sizes without limit, letting a malicious IMAP server exhaust client memory and crash it.

- Payout: hidden
- Severity: medium
- Program: Internet Bug Bounty
- Found by: masamune_
- Disclosed: 2025-04-27
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/3108869
- Library page: https://bugbountylibrary.com/r/h1%3A3108869
- Tags: area:devices domain:network impact:dos kind:bounty platform:hackerone sev:medium tech:ruby technique:source-review vuln:dos

**Target:** IMAP client library response reader (Net::IMAP)
**Root cause:** When parsing a response literal `{N}\r\n`, the reader calls IO#read(N), which immediately allocates N bytes before any data arrives; no cap on literal size is enforced.
**Steps:**
1. Connect Net::IMAP client to attacker-controlled server
2. Server sends a response containing a literal header like `{1234567890}\r\n`
3. Client receiver thread calls IO#read with that size, allocating the full buffer immediately
4. Server sends no further data; memory stays allocated, repeat with larger sizes to exhaust memory
**How found:** Code reading of the response reader: noticed IO#read(size) allocates the full buffer up front and that no limit exists on accepted literal sizes.
**Exploitation:** A malicious or compromised IMAP server (or user-supplied hostname) sends an oversized literal byte count; the client's receiver thread allocates the declared buffer without receiving the payload, causing memory exhaustion and crash.
**Insight:** Protocol length prefixes that map directly to a single read/allocation are a DoS primitive; check whether the client caps declared sizes before allocating, especially when the peer is user-supplied.