GHSA-Q2MW-FVJ9-VVCW
Vulnerability from github – Published: 2026-05-04 22:02 – Updated: 2026-05-14 20:48Summary
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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.6.3"
},
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0.6.0"
},
{
"fixed": "0.6.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.13"
},
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.0"
},
{
"fixed": "0.5.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.4.23"
},
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.24"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42245"
],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-04T22:02:56Z",
"nvd_published_at": "2026-05-09T20:16:28Z",
"severity": "LOW"
},
"details": "### Summary\n\n`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\u0027s CPU for a denial of service attack.\n\n### Details\n\nFor 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\u00b2) 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.\n\nBecause 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.\n\n`Net::IMAP::ResponseReader` runs continuously in the receiver thread until the connection closes.\n\n### Impact\n\nThis consumes disproportionate CPU time in the client\u0027s receiver thread. A hostile server could use this to exhaust the client\u0027s CPU for a denial of service attack.\n\nFor 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.\n\nAlthough other threads should not be _completely_ blocked, their run time will be significantly impacted.\n\n### Mitigation\n\n* Upgrade to a patched version of net-imap that reads responses more efficiently.\n* Do not connect to untrusted IMAP servers.\n* 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.",
"id": "GHSA-q2mw-fvj9-vvcw",
"modified": "2026-05-14T20:48:14Z",
"published": "2026-05-04T22:02:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/security/advisories/GHSA-q2mw-fvj9-vvcw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42245"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/commit/6091f7d6b1f3514cafbfe39c76f2b5d73de3ca96"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/commit/88d95231fc8afef11c1f074453f7d75b68c9dfda"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/commit/de685f91a4a4cc75eb80da898c2bf8af08d34819"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby/net-imap"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/releases/tag/v0.4.24"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/releases/tag/v0.5.14"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/releases/tag/v0.6.4"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2026-42245.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "net-imap has quadratic complexity when reading response literals"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.