# REPRO-2026-00267: Apache Camel embedded HTTP/management servers can bypass authentication on subpaths when a non-root context path is configured, allowing unauthenticated access to protected routes and management endpoints. ## Summary Status: published Severity: medium Type: security Confidence: high ## Identifiers REPRO ID: REPRO-2026-00267 CVE: CVE-2026-40022 ## Package Name: org.apache.camel:camel-platform-http-main Ecosystem: maven Affected: 4.14.1 before 4.14.6, 4.18.0 before 4.18.2 Fixed: 4.14.6 / 4.18.2 / 4.20.0 ## Root Cause # RCA Report — CVE-2026-40022 ## Summary Apache Camel's embedded HTTP server (`camel-platform-http-main`) enables an authentication bypass on subpaths whenever a **non-root context path** (e.g. `/api` or `/admin`) is configured via `camel.server.path` / `camel.management.path` and the operator does **not** explicitly set `camel.server.authenticationPath` / `camel.management.authenticationPath`. The `BasicAuthenticationConfigurer` and `JWTAuthenticationConfigurer` derive the authentication-protected path from `properties.getPath()` (the context path) and only special-case the exact root `/`. Because the Vert.x sub-router that hosts the platform-http routes is mounted with `router.route(path + "*").subRouter(subRouter)`, sub-router route matching is performed relative to the consumed context prefix, so an auth handler registered at the literal context path (e.g. `/api`) never matches the relative subpaths that the business routes are served on. The net effect is that unauthenticated requests to any subpath (e.g. `/api/hello` or `/admin/observe/info`) reach protected routes and management endpoints without being challenged for credentials. ## Impact - **Package / component affected:** `org.apache.camel:camel-platform-http-main` (and the Vert.x engine `camel-platform-http-vertx` it drives). The same `*AuthenticationConfigurer` classes protect both the embedded HTTP server (`HttpServerConfigurationProperties`) and the embedded management server (`HttpManagementServerConfigurationProperties`). - **Affected versions:** `camel-platform-http-main` 4.14.1 before 4.14.6, and 4.18.0 before 4.18.2 (fixed in 4.14.6, 4.18.2, and 4.20.0). - **Risk level:** High (advisory severity moderate). Unauthenticated remote access to protected business routes and management endpoints. The management `/observe/info` endpoint can disclose runtime metadata (user, working/home directory, process id, JVM and OS info). ## Impact Parity - **Disclosed / claimed maximum impact:** Authentication bypass (`authz_bypass`) — unauthenticated HTTP access to protected routes and management endpoints on the embedded server. - **Reproduced impact from this run:** `authz_bypass` on the `api_remote` surface — an unauthenticated `GET /api/hello` to a real running Camel Main embedded HTTP server returns `200 OK` (body `ok`) on the vulnerable build, while the identical configuration on the fixed build returns `401 Unauthorized`. Authentication is demonstrably *enabled* (credentials succeed, and the fixed build rejects without them). - **Parity:** `full` for the claimed authentication-bypass surface. The management-server variant (`/admin/observe/info`) shares the identical `*AuthenticationConfigurer` code path and root cause; this run focuses on the server-route surface, which is the primary claimed remote vector. - **Not demonstrated:** No code execution, memory corruption, or crash is claimed or produced — the issue is purely an authorization bypass, which is what was reproduced. ## Root Cause In the vulnerable releases the authentication path is resolved inline inside each configurer, e.g. in `BasicAuthenticationConfigurer.configureAuthentication(...)`: ```java String path = isNotEmpty(properties.getAuthenticationPath()) ? properties.getAuthenticationPath() : properties.getPath(); // <-- falls back to the CONTEXT path // root means to authenticate everything if ("/".equals(path)) { path = "/*"; } ``` When `camel.server.authenticationPath` is unset, `path` becomes the configured context path (e.g. `/api`). Only the exact root `"/"` is widened to `"/*"`; any other context path is left as an **exact** path. That path is then stored on the `AuthenticationConfigEntry` and registered on the Vert.x sub-router in `VertxPlatformHttpServer`: ```java // auth handler registered on the sub-router at the (exact) context path authenticationConfig.getEntries() .forEach(entry -> subRouter.route(entry.getPath()).handler(entry.createAuthenticationHandler(vertx))); ... // sub-router mounted for the context prefix router.route(configuration.getPath() + "*").subRouter(subRouter); // e.g. router.route("/api*").subRouter(subRouter) ``` The platform-http consumer route (`platform-http:/hello`) is registered on the *same* sub-router as `subRouter.route("/hello")`. Because `Route.subRouter()` delegates routing to the sub-router **relative to the consumed `/api` prefix**, a request to `/api/hello` is matched inside the sub-router against the relative path `/hello`. The auth handler registered at the literal `/api` therefore never matches a relative subpath, so the `/hello` route is reached without the authentication handler ever executing. A request without credentials returns `200 OK` (the route body) instead of `401 Unauthorized`. ### Fix The fix (tags `camel-4.14.6`, `camel-4.18.2`, `camel-4.20.0`) centralizes path resolution in a new default method on `MainAuthenticationConfigurer` and makes both configurers call it: ```java /** * Resolves the effective authentication path. When no explicit authentication * path is configured, defaults to {@code /*} so that all subpaths under the * context path are protected. */ default String resolveAuthenticationPath(String authenticationPath, String contextPath) { if (ObjectHelper.isNotEmpty(authenticationPath)) { return authenticationPath; } return "/*"; } ``` With the default now `"/*"`, the auth handler is registered at `subRouter.route("/*")`, which matches the relative subpath `/hello` (and every other subpath) → an unauthenticated request is challenged with `401`. - Advisory: https://camel.apache.org/security/CVE-2026-40022.html - Fix location: `components/camel-platform-http-main/src/main/java/org/apache/camel/component/platform/http/main/authentication/` (`MainAuthenticationConfigurer`, `BasicAuthenticationConfigurer`, `JWTAuthenticationConfigurer`) in tags `camel-4.14.6` / `camel-4.18.2` / `camel-4.20.0`. ## Reproduction Steps 1. The self-contained script is `bundle/repro/reproduction_steps.sh`. 2. It materializes a minimal Camel `Main` application that: - registers a route `from("platform-http:/hello").setBody(constant("ok"))`, - enables the embedded HTTP server with `camel.server.enabled=true`, `camel.server.path=/api`, `camel.server.port=8080`, - enables basic authentication with `camel.server.authenticationEnabled=true` and `camel.server.basicPropertiesFile=auth.properties` (`user.admin=secret`), **without** setting `camel.server.authenticationPath` (the vulnerable precondition). It builds and runs the **real** embedded Camel HTTP server twice with **identical** application code and configuration, changing only the Camel version: `4.14.5` (vulnerable) and `4.14.6` (fixed). For each it sends real HTTP requests to `http://localhost:8080/api/hello` with and without credentials and records the responses. It confirms the bypass when the vulnerable build returns `200` without credentials while the fixed build returns `401` without credentials, then writes `bundle/repro/runtime_manifest.json`. 3. Expected evidence: - `bundle/logs/vulnerable_4.14.5_no_creds.txt` → `HTTP/1.1 200 OK` body `ok` - `bundle/logs/fixed_4.14.6_no_creds.txt` → `HTTP/1.1 401 Unauthorized` with `WWW-Authenticate: Basic realm="vertx-web"` - `bundle/logs/vulnerable_4.14.5_app.log` and `fixed_4.14.6_app.log` showing `camel.server.authenticationEnabled = true`, `camel.server.path = /api`, `camel.server.basicPropertiesFile = auth.properties`, and `Vert.x HttpServer started on 0.0.0.0:8080` for the respective version. - `bundle/repro/runtime_manifest.json` with `service_started`, `healthcheck_passed`, and `target_path_reached` all `true`. ## Evidence - `bundle/logs/reproduction_summary.log` — contrast table and verdict. - `bundle/logs/vulnerable_4.14.5_no_creds.txt`: ``` HTTP/1.1 200 OK transfer-encoding: chunked ok ``` - `bundle/logs/fixed_4.14.6_no_creds.txt`: ``` HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="vertx-web" content-length: 12 Unauthorized ``` - `bundle/logs/vulnerable_4.14.5_app.log` (key lines): ``` ... camel.server.authenticationEnabled = true ... camel.server.basicPropertiesFile = auth.properties ... camel.server.path = /api ... Apache Camel 4.14.5 (camel-1) is starting ... Vert.x HttpServer started on 0.0.0.0:8080 ... Apache Camel 4.14.5 (camel-1) started in 149ms ``` - `bundle/logs/fixed_4.14.6_app.log` (key lines): ``` ... camel.server.authenticationEnabled = true ... camel.server.basicPropertiesFile = auth.properties ... camel.server.path = /api ... Apache Camel 4.14.6 (camel-1) is starting ... Vert.x HttpServer started on 0.0.0.0:8080 ... Apache Camel 4.14.6 (camel-1) started in 154ms ``` - Both `with_creds` probes return `200 OK`, proving credentials are accepted and the route itself is healthy. - Environment: OpenJDK 17.0.19, Apache Maven 3.9.12, Apache Camel `camel-platform-http-main` 4.14.5 / 4.14.6 (Vert.x 4.5.24 engine), Linux x86_64. ## Recommendations / Next Steps - **Upgrade** `camel-platform-http-main` to 4.14.6 (4.14.x LTS), 4.18.2 (4.18.x LTS), or 4.20.0 as appropriate. - **Defense in depth:** explicitly set `camel.server.authenticationPath=/*` (and `camel.management.authenticationPath=/*`) even on patched versions so protection does not depend on the default-resolution behavior. - **Audit:** review any deployed Camel Main apps using a non-root `camel.server.path` / `camel.management.path` with authentication enabled but no explicit `authenticationPath`; those are the exposed instances. - **Regression test:** add an integration test in Camel that asserts an unauthenticated request to a subpath under a non-root context path returns `401` when authentication is enabled (this run's contrast is a direct template: vulnerable `200` vs fixed `401`). ## Additional Notes - **Idempotency:** `reproduction_steps.sh` was run twice consecutively; both runs exited `0` and reproduced the identical contrast (`vulnerable 200` / `fixed 401`). The script frees port 8080 and rebuilds cleanly each run. - **Real product, not a mock:** the proof runs the actual `org.apache.camel.main.Main` embedded HTTP server (Vert.x/Netty) and drives it with real `curl` HTTP requests over localhost — a genuine `api_remote` boundary. - **Property note:** the ticket's reproduction text references `camel.server.authenticationMechanism=basic` and `camel.server.authenticationUsers[0].username/password`. Those properties do not exist in the vulnerable 4.14.x / 4.18.x releases; the real basic-auth mechanism in those versions is selected by setting `camel.server.basicPropertiesFile` (a Vert.x `PropertyFileAuthentication` file), which is what this reproduction uses. The authentication-bypass root cause is identical regardless of how credentials are configured. - **Exact-context-path behavior:** on the vulnerable build a request to the exact context path `/api` (no creds) returns `404`, not `401`, because the auth handler registered at the literal `/api` never matches a relative (prefix-stripped) sub-router path — so in practice *no* path is protected, making the bypass total. The fixed build returns `401` for both `/api` and `/api/hello` because the handler is registered at `/*`. ## Reproduction Details Reproduced: 2026-07-07T21:08:51.815Z Duration: 1226 seconds Tool calls: 239 Turns: Unknown Handoffs: 3 ## Quick Verification Run one of these commands to verify locally: pruva-verify REPRO-2026-00267 pruva-verify CVE-2026-40022 Or open in GitHub Codespaces (zero-friction, auto-runs): https://github.com/codespaces/new?ref=repro/REPRO-2026-00267&repo=N3mes1s/pruva-sandbox Or download and run the script manually: curl -O https://api.pruva.dev/v1/reproductions/REPRO-2026-00267/artifacts/bundle/repro/reproduction_steps.sh chmod +x reproduction_steps.sh ./reproduction_steps.sh WARNING: Run in a sandboxed environment. This exploits a real vulnerability. ## References - NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-40022 - Source: https://nvd.nist.gov/vuln/detail/CVE-2026-40022 ## Artifacts - bundle/repro/reproduction_steps.sh (reproduction_script, 12508 bytes) - bundle/repro/rca_report.md (analysis, 11479 bytes) - bundle/vuln_variant/reproduction_steps.sh (reproduction_script, 18260 bytes) - bundle/vuln_variant/rca_report.md (analysis, 13712 bytes) - bundle/coding/proposed_fix.diff (patch, 7394 bytes) - bundle/artifact_promotion_manifest.json (other, 14535 bytes) - bundle/artifact_promotion_report.json (other, 14553 bytes) - bundle/vuln_variant/source_identity.json (other, 2879 bytes) - bundle/vuln_variant/root_cause_equivalence.json (other, 3733 bytes) - bundle/repro/runtime_manifest.json (other, 894 bytes) - bundle/repro/validation_verdict.json (other, 921 bytes) - bundle/logs/vulnerable_4.14.5_no_creds.txt (other, 49 bytes) - bundle/logs/fixed_4.14.6_no_creds.txt (other, 104 bytes) - bundle/logs/reproduction_summary.log (log, 672 bytes) - bundle/logs/vulnerable_4.14.5_app.log (log, 2423 bytes) - bundle/logs/fixed_4.14.6_app.log (log, 2423 bytes) - bundle/logs/vulnerable_4.14.5_with_creds.txt (other, 49 bytes) - bundle/logs/fixed_4.14.6_with_creds.txt (other, 49 bytes) - bundle/vuln_variant/variant_manifest.json (other, 6715 bytes) - bundle/vuln_variant/validation_verdict.json (other, 3188 bytes) - bundle/vuln_variant/patch_analysis.md (documentation, 8250 bytes) - bundle/vuln_variant/runtime_manifest.json (other, 1904 bytes) - bundle/logs/variant_summary.log (log, 1149 bytes) - bundle/logs/fixed_biz_bypass_no_creds.txt (other, 49 bytes) - bundle/logs/fixed_mgmt_bypass_info_no_creds.txt (other, 619 bytes) - bundle/logs/fixed_biz_default_no_creds.txt (other, 104 bytes) - bundle/logs/fixed_mgmt_default_info_no_creds.txt (other, 104 bytes) - bundle/logs/fixed_biz_bypass_app.log (log, 2546 bytes) - bundle/logs/fixed_mgmt_bypass_app.log (log, 3901 bytes) - bundle/coding/verify_fix.sh (other, 12406 bytes) - bundle/coding/summary_report.md (documentation, 9467 bytes) - bundle/coding/verify_contrast.log (log, 456 bytes) ## API Access - JSON: https://api.pruva.dev/v1/reproductions/REPRO-2026-00267 - Script: https://api.pruva.dev/v1/reproductions/REPRO-2026-00267/artifacts/bundle/repro/reproduction_steps.sh - Web: https://pruva.dev/r/REPRO-2026-00267 ## For AI Assistants To help users with this reproduction: 1. The `pruva-verify` command is the simplest way to run the reproduction 2. The script downloads and runs automatically in an isolated temp directory 3. Always recommend running in a VM, container, or disposable environment 4. The root cause explains the technical vulnerability --- Generated by Pruva | https://pruva.dev