Aias00 opened a new issue, #6626: URL: https://github.com/apache/shenyu/issues/6626
- Severity: High - Location: `shenyu-web/src/main/java/org/apache/shenyu/web/filter/FileSizeFilter.java:76-84` (rejection path, no release) vs `:98` (`.doFinally` release only on success path) - Description: When the size check at line 78 rejects the upload (`dataBuffer.capacity() > Constants.BYTES_PER_MB * fileMaxSize`), the lambda returns `WebFluxResultUtils.result(exchange, error)` at line 84 **without releasing `dataBuffer`**. The `doFinally(signalType -> DataBufferUtils.release(dataBuffer))` is only on the success-path `bodyInsert.insert(...).then(...).doFinally(...)` chain (line 98), not the rejection branch. - Impact: Every rejected oversized multipart upload leaks one pooled `DataBuffer` (up to `fileMaxSize` MB of Netty direct memory). An attacker sending oversized multipart bodies can exhaust the pooled direct-memory arena, causing `OutOfDirectMemoryError` with no GC recovery. - Suggested fix: Add `.doFinally(signalType -> DataBufferUtils.release(dataBuffer))` to the rejection-path Mono, or restructure so both paths share a single outer `doFinally`. - Confidence: High - Related existing: #4505 (CLOSED, the original leak fix) — that fix only patched the success path and left the rejection path leaking. This is an incomplete-fix regression, not a dup. --- _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]
