GHSA-q2mw-fvj9-vvcw
Fix: ruby/net-imap@6091f7dGHSA-q2mw-fvj9-vvcw is a CWE-407 vulnerability in net-imap. O3 Security confirms whether GHSA-q2mw-fvj9-vvcw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
net-imap has quadratic complexity when reading response literals
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-q2mw-fvj9-vvcw.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
net-imap💎net-imap💎net-imapReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Net::IMAP::ResponseReader has quadratic time complexity when reading large responses containing many string literals. A hostile server can send responses which are crafted to exhaust the client's CPU for a denial of service attack.
Details
For each literal in a response, ResponseReader rescans the entire growing response buffer. The regular expression that is used to scan the response buffer runs in linear time. With many literals, this becomes O(n²) total work. The regular expression should run in constant time: it is anchored to the end and only the last 23 bytes of the buffer are relevant.
Because the algorithmic complexity is super-linear, this bypasses protection from max_response_size: a response can stay well below the default size limit while still causing very large CPU cost.
Net::IMAP::ResponseReader runs continuously in the receiver thread until the connection closes.
Impact
This consumes disproportionate CPU time in the client's receiver thread. A hostile server could use this to exhaust the client's CPU for a denial of service attack.
For a response near the default max_response_size, each individual regexp scan could take between 100 to 200ms on common modern hardware, and this may be repeated 200k times per megabyte of response. While the regexp is scanning, it retains the Global VM lock, preventing other threads from running.
Although other threads should not be completely blocked, their run time will be significantly impacted.
Mitigation
- Upgrade to a patched version of net-imap that reads responses more efficiently.
- Do not connect to untrusted IMAP servers.
- When connecting to untrusted servers, a much smaller
max_response_size(for example: 8KiB) will limit the impact. Although this is too small for fetching unpaginated message bodies, it should be enough for most other operations.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | net-imap | ≥ 0.6.0&&< 0.6.4 | 0.6.4 |
| 💎RubyGems | net-imap | ≥ 0.5.0&&< 0.5.14 | 0.5.14 |
| 💎RubyGems | net-imap | all versions | 0.4.24 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for net-imap. 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 net-imap to 0.6.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-q2mw-fvj9-vvcw 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-q2mw-fvj9-vvcw 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-q2mw-fvj9-vvcw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Red Hat has rated this flaw as Moderate because a malicious IMAP server can trigger excessive CPU consumption in applications using the affected Net::IMAP library, resulting in a denial-of-service condition. Successful exploitation requires interaction with a hostile server, and the impact is limited to resource…
Frequently Asked Questions
Is GHSA-q2mw-fvj9-vvcw in your dependencies?
O3 detects GHSA-q2mw-fvj9-vvcw across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.