Add server.request.body.filenames AppSec address for Vert.x 3.4, 4.0 and 5.0

[jandro996]

What Does This Do

Instruments RoutingContextImpl.fileUploads() in the Vert.x Web 3.4, 4.0 and 5.0 modules to fire the server.request.body.filenames AppSec IG event, enabling WAF-level detection and blocking on uploaded file names.

New callsites

• vertx-web-3.4: new RoutingContextFilenamesAdvice (returns Set<FileUpload>), wired in RoutingContextImplInstrumentation
• vertx-web-4.0: new RoutingContextFilenamesAdvice (returns Collection<FileUpload> to cover both Set in 4.0.x and List in 4.5.x+), wired in RoutingContextImplInstrumentation
• vertx-web-5.0: new RoutingContextFilenamesAdvice (returns List<FileUpload>) + new RoutingContextImplInstrumentation

All three advice classes use FileUpload.class as the CallDepthThreadLocalMap key (public interface, avoids IllegalAccessError when ByteBuddy inlines the advice into RoutingContextImpl).

Test server fixes

All four VertxTestServer variants (3.4, 4.0/test, 4.0/latestDep, 5.0) had a broken BODY_MULTIPART handler that used setExpectMultipart(true) + an async endHandler, bypassing BodyHandler. This prevented fileUploads() from ever being populated. Replaced with:

1. BodyHandler.create() registered as a prior handler on the same route
2. A synchronous handler that calls ctx.fileUploads() before convertFormAttributes(ctx)

testBodyMultipart() continues to pass because BodyHandler also populates formAttributes().

Added .gitignore files in each module root to suppress the file-uploads/ temporary directories that BodyHandler.create() creates on disk during test execution.

NettyMultipartHelper fix

Vert.x's internal NettyFileUpload throws UnsupportedOperationException from getHttpDataType(). Added a try-catch to skip such items silently - they are handled by Vert.x's own instrumentation. Without the fix, the exception was swallowed by ByteBuddy's suppress = Throwable.class but incremented INSTRUMENTATION_ERROR_COUNT, causing the Vert.x 5.0 integration tests to fail with "1 instrumentation error". Coverage is provided by the Vert.x 5.0 forked tests in this PR.

vertx-rx-3.5 fix

VertxRxCircuitBreakerHttpServerForkedTest extends VertxHttpServerForkedTest (vertx-web-3.4) and inherited the new testBodyFilenames() { true } override. Its internal test server (VertxRxCircuitBreakerWebTestServer) uses the legacy expectMultipart + endHandler pattern without BodyHandler or fileUploads(), so the filename tag is never emitted. Added an explicit testBodyFilenames() { false } override, consistent with the existing testBodyJson(), testRequestBody(), and testSessionId() overrides in the same class.

Motivation

solves APPSEC-61873 (partial - Vert.x coverage)

Additional Notes

Double-instrumentation in 5.0 tests: the vertx-web-5.0 test module includes vertx-web-4.0 as testImplementation, so both RoutingContextImplInstrumentation classes are applied in the same test run. Using Collection<FileUpload> in the 4.0 advice (instead of Set<FileUpload>) was necessary to avoid a ByteBuddy type-mismatch error when Vert.x 4.5.x+ changed the return type of fileUploads() from Set to List. Once the type error was gone, both advices coexist correctly via the shared CallDepthThreadLocalMap key.

Static reflection pattern: FILE_UPLOAD_REF is defined as a static final Reference in each RoutingContextImplInstrumentation (not a VertxVersionMatcher constant) because it is only needed by that single class. The 5.0 instrumentation uses HTTP_HEADERS_INTERNAL (io.vertx.core.internal.http.HttpHeadersInternal, absent in 4.x) as the version discriminator to prevent the 5.0 advice from applying to Vert.x 4.x classloaders.

JVM constraint: vertx-web-3.4 and vertx-web-4.0 default test set maxJavaVersion = VERSION_15; tests must be run with -PtestJvm=11 via forkedTest (not test).

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors

Jira ticket: APPSEC-61873

Note: Once your PR is ready to merge, add it to the merge queue by commenting /merge. /merge -c cancels the queue request. /merge -f --reason "reason" skips all merge queue checks; please use this judiciously, as some checks do not run at the PR-level. For more information, see this doc.

[jandro996]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Delightful!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[dd-octo-sts]

Hi! 👋 Thanks for your pull request! 🎉

To help us review it, please make sure to:

• Add at least one type, and one component or instrumentation label to the pull request

If you need help, please check our contributing guidelines.

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Startup Time

Scenario	This PR	master	Change
insecure-bank / iast	13,950 ms	14,049 ms	-0.7%
insecure-bank / tracing	12,944 ms	13,010 ms	-0.5%
petclinic / appsec	16,610 ms	16,485 ms	+0.8%
petclinic / iast	16,546 ms	16,655 ms	-0.7%
petclinic / profiling	16,456 ms	16,644 ms	-1.1%
petclinic / tracing	16,028 ms	15,796 ms	+1.5%

Commit: ef19609f · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[dd-octo-sts]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-06-04 08:21:55 UTC ℹ️ Start processing command /merge

---

2026-06-04 08:22:00 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-06-04 09:33:33 UTC ℹ️ MergeQueue: This merge request was merged