Vulnerability-Lookup

Vulnerability from cleanstart

Published

2026-03-04 00:39

Modified

2026-03-03 12:59

Summary

Security fixes for GHSA-4cx2-fc23-5wg6, GHSA-6xw4-3v39-52mm, GHSA-72qj-48g4-5xgx, GHSA-mr3q-g2mv-mr4q, GHSA-p543-xpfm-54cp, GHSA-vc5p-v9hr-52mj, GHSA-vqg5-3255-v292 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

URL

Type

	https://github.com/cleanstart-dev/cleanstart-secu…	ADVISORY
	https://osv.dev/vulnerability/GHSA-4cx2-fc23-5wg6	WEB
	https://osv.dev/vulnerability/GHSA-6xw4-3v39-52mm	WEB
	https://osv.dev/vulnerability/GHSA-72qj-48g4-5xgx	WEB
	https://osv.dev/vulnerability/GHSA-mr3q-g2mv-mr4q	WEB
	https://osv.dev/vulnerability/GHSA-p543-xpfm-54cp	WEB
	https://osv.dev/vulnerability/GHSA-vc5p-v9hr-52mj	WEB
	https://osv.dev/vulnerability/GHSA-vqg5-3255-v292	WEB

JSON

To clipboard

{
  "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-EW93264",
  "modified": "2026-03-03T12:59:01Z",
  "published": "2026-03-04T00:39:32.590174Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://github.com/cleanstart-dev/cleanstart-security-advisories/tree/main/advisories/2026/CLEANSTART-2026-EW93264.json"
    },
    {
      "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-72qj-48g4-5xgx"
    },
    {
      "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"
    }
  ],
  "related": [],
  "schema_version": "1.7.3",
  "summary": "Security fixes for GHSA-4cx2-fc23-5wg6, GHSA-6xw4-3v39-52mm, GHSA-72qj-48g4-5xgx, GHSA-mr3q-g2mv-mr4q, GHSA-p543-xpfm-54cp, GHSA-vc5p-v9hr-52mj, GHSA-vqg5-3255-v292 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-4cx2-fc23-5wg6",
    "GHSA-6xw4-3v39-52mm",
    "GHSA-72qj-48g4-5xgx",
    "GHSA-mr3q-g2mv-mr4q",
    "GHSA-p543-xpfm-54cp",
    "GHSA-vc5p-v9hr-52mj",
    "GHSA-vqg5-3255-v292"
  ]
}

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-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-VC5P-V9HR-52MJ

Vulnerability from github – Published: 2025-12-18 21:31 – Updated: 2025-12-19 22:08

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 ?

6.3 (Medium)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "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-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-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-4CX2-FC23-5WG6

Vulnerability from github – Published: 2025-08-13 12:31 – Updated: 2025-10-17 13:58

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 ?

6.3 (Medium)


                  
                    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

Show details on source website

JSON

To clipboard

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

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.

Detection rules are retrieved from Rulezet.

Action not permitted

Vulnerability from cleanstart

GHSA-6XW4-3V39-52MM

Summary

Details

Impact

Mitigation

GHSA-MR3Q-G2MV-MR4Q

Summary

Details

Resources

GHSA-VC5P-V9HR-52MJ

GHSA-P543-XPFM-54CP

Summary

Details

Impact

Mitigation

GHSA-72QJ-48G4-5XGX

Summary

Details

PoC

Impact

GHSA-4CX2-FC23-5WG6

Tags

Sightings

Nomenclature