[BUG] FileSizeFilter leaks pooled DataBuffer on oversized-file rejection path

[Aias00]

• 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: [BUG] FileSizeFilter make memory leak #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.

[github-actions]

👋 Hello @yuluo-yx

A new issue has been opened by @Aias00:

• Title: [BUG] FileSizeFilter leaks pooled DataBuffer on oversized-file rejection path
• Link: [BUG] FileSizeFilter leaks pooled DataBuffer on oversized-file rejection path #6626

Please review when you have time. Thank you! 🙏