1 line
4.8 KiB
JSON
1 line
4.8 KiB
JSON
{"version":"0.9.2","created_at":"2025-10-13 16:37:10 +0200","results":[{"type":"unpatched_gem","gem":{"name":"rack","version":"3.2.2"},"advisory":{"path":"/home/wiseadvice/.local/share/ruby-advisory-db/gems/rack/CVE-2025-61780.yml","id":"CVE-2025-61780","url":"https://github.com/rack/rack/security/advisories/GHSA-r657-rxjc-j557","title":"Rack has a Possible Information Disclosure Vulnerability","date":"2025-10-10","description":"## Summary\n\nA possible information disclosure vulnerability existed in\n`Rack::Sendfile` when running behind a proxy that supports\n`x-sendfile` headers (such as Nginx). Specially crafted headers\ncould cause `Rack::Sendfile` to miscommunicate with the proxy and\ntrigger unintended internal requests, potentially bypassing\nproxy-level access restrictions.\n\n## Details\n\nWhen `Rack::Sendfile` received untrusted `x-sendfile-type` or\n`x-accel-mapping` headers from a client, it would interpret them\nas proxy configuration directives. This could cause the middleware\nto send a \"redirect\" response to the proxy, prompting it to reissue\na new internal request that was\n**not subject to the proxy's access controls**.\n\nAn attacker could exploit this by:\n1. Setting a crafted `x-sendfile-type: x-accel-redirect` header.\n2. Setting a crafted `x-accel-mapping` header.\n3. Requesting a path that qualifies for proxy-based acceleration.\n\n## Impact\n\nAttackers could bypass proxy-enforced restrictions and access internal\nendpoints intended to be protected (such as administrative pages).\nThe vulnerability did not allow arbitrary file reads but could\nexpose sensitive application routes.\n\nThis issue only affected systems meeting all of the following conditions:\n\n* The application used `Rack::Sendfile` with a proxy that supports\n `x-accel-redirect` (e.g., Nginx).\n* The proxy did **not** always set or remove the `x-sendfile-type`\n and `x-accel-mapping` headers.\n* The application exposed an endpoint that returned a body\n responding to `.to_path`.\n\n## Mitigation\n\n* Upgrade to a fixed version of Rack which requires explicit\n configuration to enable `x-accel-redirect`:\n\n ```ruby\n use Rack::Sendfile, \"x-accel-redirect\"\n ```\n\n* Alternatively, configure the proxy to always set or strip\n the headers (you should be doing this!):\n\n ```nginx\n proxy_set_header x-sendfile-type x-accel-redirect;\n proxy_set_header x-accel-mapping /var/www/=/files/;\n ```\n\n* Or in Rails applications, disable sendfile completely:\n\n ```ruby\n config.action_dispatch.x_sendfile_header = nil\n ```\n","cvss_v2":null,"cvss_v3":5.8,"cve":"2025-61780","osvdb":null,"ghsa":"r657-rxjc-j557","unaffected_versions":[],"patched_versions":["~> 2.2.20","~> 3.1.18",">= 3.2.3"],"criticality":"medium"}},{"type":"unpatched_gem","gem":{"name":"rack","version":"3.2.2"},"advisory":{"path":"/home/wiseadvice/.local/share/ruby-advisory-db/gems/rack/CVE-2025-61919.yml","id":"CVE-2025-61919","url":"https://github.com/rack/rack/security/advisories/GHSA-6xw4-3v39-52mm","title":"Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing","date":"2025-10-10","description":"## Summary\n\n`Rack::Request#POST` reads the entire request body into memory for\n`Content-Type: application/x-www-form-urlencoded`, calling\n`rack.input.read(nil)` without enforcing a length or cap. Large\nrequest bodies can therefore be buffered completely into process\nmemory before parsing, leading to denial of service (DoS) through\nmemory exhaustion.\n\n## Details\n\nWhen handling non-multipart form submissions, Rack’s request\nparser 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\nloaded into a Ruby `String`. This occurs before query parameter\nparsing or enforcement of any `params_limit`. As a result, Rack\napplications without an upstream body-size limit can experience\nunbounded memory allocation proportional to request size.\n\n## Impact\n\nAttackers can send large `application/x-www-form-urlencoded` bodies\nto consume process memory, causing slowdowns or termination by the\noperating system (OOM). The effect scales linearly with request\nsize and concurrency. Even with parsing limits configured, the\nissue occurs *before* those limits are enforced.\n\n## Mitigation\n\n* Update to a patched version of Rack that enforces form parameter\n limits using `query_parser.bytesize_limit`, preventing unbounded\n reads of `application/x-www-form-urlencoded` bodies.\n* Enforce strict maximum body size at the proxy or web server layer\n (e.g., Nginx `client_max_body_size`, Apache `LimitRequestBody`).\n","cvss_v2":null,"cvss_v3":7.5,"cve":"2025-61919","osvdb":null,"ghsa":"6xw4-3v39-52mm","unaffected_versions":[],"patched_versions":["~> 2.2.20","~> 3.1.18",">= 3.2.3"],"criticality":"high"}}]} |