https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 16:44:09 +0000 https://cve.radiocsirt.org/vuln/cleanstart-2026-be61221 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: opensearch-dashboards-fips</p> <p>Multiple security vulnerabilities affect the opensearch-dashboards-fips package. These issues are resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: opensearch-dashboards-fips</p> <p>Multiple security vulnerabilities affect the opensearch-dashboards-fips package. These issues are resolved in later releases. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-be61221 https://cve.radiocsirt.org/vuln/euvd-2026-318078 EUVD-2026-318078 https://cve.radiocsirt.org/vuln/euvd-2026-318078 https://cve.radiocsirt.org/vuln/fkie_cve-2026-44456 <p>Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.16, bodyLimit() does not reliably enforce maxSize for requests without a usable Content-Length (e.g. Transfer-Encoding: chunked). Oversized requests can reach handlers and return 200 instead of 413. This vulnerability is fixed in 4.12.16.</p> <p>Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.16, bodyLimit() does not reliably enforce maxSize for requests without a usable Content-Length (e.g. Transfer-Encoding: chunked). Oversized requests can reach handlers and return 200 instead of 413. This vulnerability is fixed in 4.12.16.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-44456 https://cve.radiocsirt.org/vuln/ghsa-9vqf-7f2p-gf9v <p><strong>Affected:</strong> npm: hono</p> <p>## Summary</p> <p>`bodyLimit()` does not reliably enforce `maxSize` for requests without a usable `Content-Length` (e.g. `Transfer-Encoding: chunked`). Oversized requests can reach handlers and return `200` instead of `413`.</p> <p>## Details</p> <p>For chunked / unknown-length requests, `bodyLimit()` wraps the body in a stream that counts bytes asynchronously, then runs the handler before the size decision is final. The `413` is only applied afterwards by checking `c.error`.</p> <p>This lets the limit be bypassed when:</p> <p>- the handler does not read the body, - the handler reads only the first chunk(s) and returns, or - the handler reads the body but swallows the read error in `try/catch`.</p> <p>In all three cases the handler returns `200` before the limit check completes (or its result is observed).</p> <p>The fix is to enforce the size decision before `next()` runs, instead of retrofitting the response via `c.error` afterwards.</p> <p>## Impact</p> <p>Applications relying on `bodyLimit()` as a hard boundary can be bypassed: oversized chunked requests can reach handler logic and return successful responses. Per-request data exposure is bounded by `maxSize`, but the documented guarantee — &#34;oversized requests are rejected before business logic runs&#34; — does not hold.</p> <p>## Credits</p> <p>- @lalalala5678 (slow chunked / early return variants) - @Jvr2022 (error handling bypass)</p> <p><strong>Affected:</strong> npm: hono</p> <p>## Summary</p> <p>`bodyLimit()` does not reliably enforce `maxSize` for requests without a usable `Content-Length` (e.g. `Transfer-Encoding: chunked`). Oversized requests can reach handlers and return `200` instead of `413`.</p> <p>## Details</p> <p>For chunked / unknown-length requests, `bodyLimit()` wraps the body in a stream that counts bytes asynchronously, then runs the handler before the size decision is final. The `413` is only applied afterwards by checking `c.error`.</p> <p>This lets the limit be bypassed when:</p> <p>- the handler does not read the body, - the handler reads only the first chunk(s) and returns, or - the handler reads the body but swallows the read error in `try/catch`.</p> <p>In all three cases the handler returns `200` before the limit check completes (or its result is observed).</p> <p>The fix is to enforce the size decision before `next()` runs, instead of retrofitting the response via `c.error` afterwards.</p> <p>## Impact</p> <p>Applications relying on `bodyLimit()` as a hard boundary can be bypassed: oversized chunked requests can reach handler logic and return successful responses. Per-request data exposure is bounded by `maxSize`, but the documented guarantee — &#34;oversized requests are rejected before business logic runs&#34; — does not hold.</p> <p>## Credits</p> <p>- @lalalala5678 (slow chunked / early return variants) - @Jvr2022 (error handling bypass)</p> https://cve.radiocsirt.org/vuln/ghsa-9vqf-7f2p-gf9v