Aias00 opened a new issue, #6627: URL: https://github.com/apache/shenyu/issues/6627
- Severity: Medium - Location: `shenyu-web/src/main/java/org/apache/shenyu/web/filter/FileSizeFilter.java:62-64` (constructor sets `-1`), `:76` (`bodyToMono(DataBuffer.class)` reads entire body), `:78` (size check fires only after full buffering) - Description: The constructor sets `maxInMemorySize(-1)` (unlimited). `serverRequest.bodyToMono(DataBuffer.class)` at line 76 reads the **entire** multipart body into a single in-memory `DataBuffer` with no size cap. The size check at line 78 only fires **after** the full body is already buffered. An attacker can send a 10 GB multipart body; the gateway buffers all 10 GB, then rejects it as "too large" — but the OOM damage is already done. - Impact: Memory-exhaustion DoS. A single malicious request can crash the gateway process. - Suggested fix: Set `maxInMemorySize` to a bounded value (e.g. `fileMaxSize * BYTES_PER_MB`) so the codec rejects oversized bodies during buffering, or switch to a streaming size-check. - Confidence: High - Related existing: #4405 / #4505 — those are about the API and the leak; the DoS aspect of `-1` is not in either. --- _Identified during the 2026-08-02 deep re-scan; full list in [`docs/scan2-2026-08-02/00-consolidated-critical-high.md`](docs/scan2-2026-08-02/00-consolidated-critical-high.md)._ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
