Vulnerability-Lookup

Vulnerability from cleanstart

Published

2026-07-30 07:10

Modified

2026-07-30 09:34

Summary

Security fixes in logstash-fips 9.0.8-r2

Details

Package logstash-fips version 9.0.8-r2 fixes 8 vulnerabilities: ghsa-6xw4-3v39-52mm, ghsa-p543-xpfm-54cp, ghsa-w9pc-fmgc-vxvw, ghsa-wpv5-97wm-hp9c, ghsa-72qj-48g4-5xgx...

References

URL

Type

https://github.com/elastic/logstash

WEB

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Alpine",
        "name": "logstash-fips"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.0.8-r2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "9.0.8-r2"
      ]
    }
  ],
  "credits": [],
  "database_specific": {},
  "details": "Package logstash-fips version 9.0.8-r2 fixes 8 vulnerabilities: ghsa-6xw4-3v39-52mm, ghsa-p543-xpfm-54cp, ghsa-w9pc-fmgc-vxvw, ghsa-wpv5-97wm-hp9c, ghsa-72qj-48g4-5xgx...",
  "id": "CLEANSTART-2026-IZ28086",
  "modified": "2026-07-30T09:34:00Z",
  "published": "2026-07-30T07:10:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/elastic/logstash"
    }
  ],
  "related": [],
  "schema_version": "1.7.3",
  "summary": "Security fixes in logstash-fips 9.0.8-r2",
  "upstream": [
    "ghsa-6xw4-3v39-52mm",
    "ghsa-p543-xpfm-54cp",
    "ghsa-w9pc-fmgc-vxvw",
    "ghsa-wpv5-97wm-hp9c",
    "ghsa-72qj-48g4-5xgx",
    "ghsa-22h5-pq3x-2gf2",
    "ghsa-c2f4-jgmc-q2r5",
    "ghsa-mr3q-g2mv-mr4q"
  ]
}

GHSA-22H5-PQ3X-2GF2

Vulnerability from github – Published: 2025-03-03 22:07 – Updated: 2025-11-04 00:32

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

3.2 (Low)


                  
                    CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N

2.1 (Low)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "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-6XW4-3V39-52MM

Vulnerability from github – Published: 2025-10-10 17:33 – Updated: 2025-10-13 15:46

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 of application/x-www-form-urlencoded bodies.
Enforce strict maximum body size at the proxy or web server layer (e.g., Nginx client_max_body_size, Apache LimitRequestBody).

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "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

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

5.7 (Medium)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "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-C2F4-JGMC-Q2R5

Vulnerability from github – Published: 2025-09-17 18:26 – Updated: 2025-09-19 14:41

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

1.2 (Low)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "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-MR3Q-G2MV-MR4Q

Vulnerability from github – Published: 2025-10-10 20:28 – Updated: 2025-10-13 15:46

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

2.7 (Low)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "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-P543-XPFM-54CP

Vulnerability from github – Published: 2025-10-07 17:26 – Updated: 2025-10-13 15:29

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)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "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-W9PC-FMGC-VXVW

Vulnerability from github – Published: 2025-10-07 17:27 – Updated: 2025-10-13 15:29

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)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "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-WPV5-97WM-HP9C

Vulnerability from github – Published: 2025-10-07 17:28 – Updated: 2025-10-13 15:30

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)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "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)"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.

Action not permitted

Vulnerability from cleanstart

Details

Affected versions

Credits

Summary

Details

Impact

Mitigation

Summary

Details

PoC

Impact

Impact

Patches

Workarounds

References

Summary

Details

Resources

Summary

Details

Impact

Mitigation

Summary

Details

Impact

Mitigation

Summary

Details

Impact

Mitigation

Tags

Sightings

Nomenclature