CVE-2026-40022: Verified Repro With Script Download

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.

• 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(...):

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:

// 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:

/**
 * 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 /*.

A distinct authentication-bypass variant of CVE-2026-40022 reproduces on the patched Apache Camel camel-platform-http-main 4.14.6 (and by extension 4.18.2 / 4.20.0). The official fix (commit a9ebee94af976ac2afd7906d2e76673067d8be86) only changes the default path resolution: when camel.server.authenticationPath / camel.management.authenticationPath is not set, the auth handler is now registered at /* on the Vert.x sub-router, so all subpaths are protected. Explicit authenticationPath values are still returned verbatim by the new MainAuthenticationConfigurer.resolveAuthenticationPath (which receives but ignores the contextPath argument) and are registered relative to the sub-router. The user-facing Javadoc describes authenticationPath as "the HTTP url path ... that is protected", which encourages an operator to set it to the context prefix (e.g. /api or /admin). Because that value is matched relative to the consumed context prefix, authenticationPath=/api protects only /api/api, not /api/hello; authenticationPath=/admin protects only /admin/admin, not /admin/observe/info. On the patched 4.14.6 build, an unauthenticated GET /api/hello still returns 200 OK, and an unauthenticated GET /admin/observe/info still returns 200 OK with a JSON body leaking runtime metadata (user, user.dir, user.home, pid, JVM vendor/version, OS name/version/arch). This is the same root cause and the same sink as the parent CVE, reached via a different data path (explicit authenticationPath equal to the context prefix) that the fix does not cover.

Fix Coverage / Assumptions

• Invariant the fix relies on: when authenticationPath is unset, default the registered auth path to /* so every subpath under the context is protected.
• Code paths the fix explicitly covers: the unset/default branch of BasicAuthenticationConfigurer and JWTAuthenticationConfigurer (both the HttpServerConfigurationProperties and HttpManagementServerConfigurationProperties overloads). The fix's own test BasicAuthenticationSelectivePathTest covers exactly one explicit form, /secure/*, asserted as deliberate selective protection (/api/secure/data → 401, /api/public → 200).
• What the fix does NOT cover: any explicit authenticationPath that equals or starts with the context path (/api, /api/*, /admin, /admin/*). resolveAuthenticationPath returns such values verbatim; they are registered relative to the sub-router and therefore do not match the real subpaths. There is no normalization, no startup warning, and no doc clarification; the contextPath parameter to resolveAuthenticationPath is dead code.

Variant / Alternate Trigger

Two entry points, same data-path pattern (explicit authenticationPath set to the context prefix), same sink:

1. Embedded HTTP server (business routes):
   • Config: camel.server.path=/api, camel.server.authenticationEnabled=true, camel.server.basicPropertiesFile=auth.properties, camel.server.authenticationPath=/api (explicit, the doc-encouraged form).
   • Attack: unauthenticated GET http://host:8080/api/hello.
   • Sink: VertxPlatformHttpServer.addAuthenticationHandlersStartingFromMoreSpecificPaths → subRouter.route(entry.getPath()) where entry.getPath() = /api (relative), mounted under router.route("/api*").subRouter(subRouter). The relative /api matches only absolute /api/api; /api/hello is served without the auth handler.
2. Embedded management server (info disclosure):
   • Config: camel.management.path=/admin, camel.management.infoEnabled=true, camel.management.authenticationEnabled=true, camel.management.authenticationPath=/admin (explicit).
   • Attack: unauthenticated GET http://host:8081/admin/observe/info.
   • Same sink via the management sub-router; the /observe/info route (ManagementHttpServer.setupInfo, registered at relative /observe/info) is reached without auth and returns runtime metadata JSON.

Files/functions involved:

• org.apache.camel.component.platform.http.main.authentication.MainAuthenticationConfigurer.resolveAuthenticationPath(String, String)

• BasicAuthenticationConfigurer.configureAuthentication(...) / JWTAuthenticationConfigurer.configureAuthentication(...) (server + management overloads)

• org.apache.camel.component.platform.http.vertx.VertxPlatformHttpServer (sub-router mount + addAuthenticationHandlersStartingFromMoreSpecificPaths)

• org.apache.camel.component.platform.http.main.ManagementHttpServer.setupInfo (info-disclosure endpoint)

• org.apache.camel.main.HttpServerConfigurationProperties / HttpManagementServerConfigurationProperties (authenticationPath Javadoc)

• Package/component affected: org.apache.camel:camel-platform-http-main (driving camel-platform-http-vertx). The same *AuthenticationConfigurer classes and the same VertxPlatformHttpServer engine protect both the embedded HTTP server and the embedded management server.

• Affected/tested versions: confirmed on fixed 4.14.6 (also reproduced on vulnerable 4.14.5 for contrast). The explicit-path branch is unchanged between the two, so 4.18.2 / 4.20.0 are expected to behave identically.

• Risk level: High. Unauthenticated remote access to protected business routes; unauthenticated remote disclosure of runtime metadata (OS, JVM, pid, username, working directory, home directory) via the management /observe/info endpoint.

Impact Parity

• Disclosed/claimed maximum impact (parent CVE): authz_bypass — unauthenticated HTTP access to protected routes and management endpoints.
• Reproduced impact from this variant run: authz_bypass on the api_remote surface, on the patched build. Unauthenticated GET /api/hello → 200 OK (body ok); unauthenticated GET /admin/observe/info → 200 OK with a JSON body disclosing user, user.dir, user.home, pid, JVM and OS details. Credentials are accepted (with-creds → 200), and the default case is correctly fixed (401), proving authentication is genuinely enabled and the route is healthy.
• Parity: full for the claimed authentication-bypass surface, plus a concrete information-disclosure demonstration on the management surface.
• Not demonstrated: no code execution, memory corruption, or crash is claimed or produced — the issue is an authorization bypass (with info disclosure), which is what was reproduced.

Root Cause

VertxPlatformHttpServer mounts the platform-http routes on a sub-router: router.route(configuration.getPath() + "*").subRouter(subRouter). Inside that sub-router, route matching is performed relative to the consumed context prefix. The authentication handler is registered on the same sub-router at entry.getPath():

authenticationConfig.getEntries().stream()
    .sorted(this::compareUrlPathsSpecificity)
    .forEach(entry -> subRouter.route(entry.getPath()).handler(entry.createAuthenticationHandler(vertx)));

The CVE's root cause was that, when authenticationPath was unset, entry.getPath() became the exact context path (e.g. /api), which as a relative path matches only /api/api. The fix made the unset case resolve to /* (which, as a relative path, matches every subpath). But the same root cause persists for any explicit authenticationPath that includes the context prefix: the value is returned verbatim by resolveAuthenticationPath and registered relative to the sub-router, so it never matches the real subpaths. The fix addressed the default-resolution branch only; it did not normalize, validate, or warn about explicit values, and the user-facing Javadoc continues to describe authenticationPath in absolute-URL-path terms that invite the vulnerable configuration.

• Fix commit: a9ebee94af976ac2afd7906d2e76673067d8be86
• Advisory: https://camel.apache.org/security/CVE-2026-40022.html

Reproduction Steps

1. The self-contained script is bundle/vuln_variant/reproduction_steps.sh.
2. It materializes a minimal Camel Main application (route from("platform-http:/hello").setBody(constant("ok"))) with camel-platform-http-main + camel-management + camel-console, builds it against the vulnerable 4.14.5 and the fixed 4.14.6 using a shared Maven cache, and for each version runs four configurations against the real embedded Vert.x HTTP server:
   • business server, explicit camel.server.authenticationPath=/api (BYPASS)
   • business server, default (no authenticationPath) (CONTROL)
   • management server, explicit camel.management.authenticationPath=/admin (BYPASS)
   • management server, default (CONTROL) For each it sends real curl requests with and without credentials to /api/hello and /admin/observe/info and records the responses. It writes bundle/vuln_variant/runtime_manifest.json and bundle/logs/variant_summary.log.
3. Expected evidence (on the fixed 4.14.6):
   • bundle/logs/fixed_biz_default_no_creds.txt → HTTP/1.1 401 (fix works)
   • bundle/logs/fixed_biz_bypass_no_creds.txt → HTTP/1.1 200 OK body ok (BYPASS)
   • bundle/logs/fixed_mgmt_default_info_no_creds.txt → HTTP/1.1 401 (fix works)
   • bundle/logs/fixed_mgmt_bypass_info_no_creds.txt → HTTP/1.1 200 OK JSON with user, dir, home, pid, JVM/OS (BYPASS + info disclosure)
   • bundle/logs/fixed_biz_bypass_app.log showing camel.server.authenticationPath = /api and Vert.x HttpServer started on Apache Camel 4.14.6. Exit 0 = bypass reproduced on the fixed version.

Evidence

• bundle/logs/variant_summary.log — contrast table + verdict.
• bundle/logs/fixed_biz_bypass_no_creds.txt:

  HTTP/1.1 200 OK
  transfer-encoding: chunked
  
  ok
  

• bundle/logs/fixed_biz_default_no_creds.txt:

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: Basic realm="vertx-web"
  

• bundle/logs/fixed_mgmt_bypass_info_no_creds.txt:

  HTTP/1.1 200 OK
  content-type: application/json
  {"os":{"name":"Linux",...},"java":{"pid":179835,"vendor":"Ubuntu","name":"OpenJDK 64-Bit Server VM","vmVersion":"17.0.19+10-1-26.04.2-Ubuntu","version":"17.0.19","user":"vscode","dir":"/data/.../camel-auth-variant","home":"/home/vscode"},"camel":{"name":"camel-1","version":"4.14.6",...}}
  

• bundle/logs/fixed_mgmt_default_info_no_creds.txt → HTTP/1.1 401 (control).
• bundle/logs/fixed_biz_bypass_app.log (key lines): camel.server.authenticationPath = /api, camel.server.path = /api, Apache Camel 4.14.6 (camel-1) is starting, Vert.x HttpServer started on 0.0.0.0:8080.
• Vulnerable 4.14.5 contrast: every case returns 200 no-creds (original CVE for defaults; same explicit-prefix bypass), confirming the fix changed only the default branch.
• Environment: OpenJDK 17.0.19, Apache Maven 3.9.12, Apache Camel camel-platform-http-main 4.14.5 / 4.14.6 (Vert.x engine), Linux x86_64.

Recommendations / Next Steps

• Normalize explicit authenticationPath against the context path. In resolveAuthenticationPath, if the explicit value equals or starts with contextPath, strip the prefix and (when the remainder is empty or /) widen to /* so "protect the context" actually protects all subpaths. This uses the currently-dead contextPath argument.
• Emit a startup warning when an explicit authenticationPath does not start with / or does not cover any registered subpath, so a doc-encouraged misconfiguration is not silent.
• Fix the Javadoc for setAuthenticationPath (server + management) to state that the path is relative to the context path, that a wildcard is required to protect subpaths, and that unset = protect everything under the context.
• Add a regression test for the context-prefix case: camel.server.path=/api
  • camel.server.authenticationPath=/api must yield 401 for /api/hello (and the management equivalent for /admin/observe/info).
• Defense in depth for operators: until a fixed release is available, explicitly set camel.server.authenticationPath=/* / camel.management.authenticationPath=/*, and avoid setting these to the context prefix.

Additional Notes

• Bypass vs alternate trigger: This is a bypass — it reproduces on the patched 4.14.6 (exit 0), while the parent CVE's default case is correctly fixed (401) on the same build with identical app code.
• Idempotency: reproduction_steps.sh was run twice consecutively; both runs exited 0 with the identical contrast (fixed default 401 / fixed explicit-prefix 200 / vulnerable all-200). The script frees ports 8080/8081 and rebuilds cleanly each run.
• Scope honesty: Camel's advisory scopes CVE-2026-40022 to the "not explicitly set" case, which the fix closes. This variant is therefore best framed as an incomplete fix + documentation footgun: the same auth-bypass sink is reachable on the patched build via a doc-encouraged explicit authenticationPath. The fix's own BasicAuthenticationSelectivePathTest blesses selective protection with a relative sub-path (/secure/*) as by-design; the untested, undocumented context-prefix case (/api, /admin) is the gap.
• Real product, not a mock: the proof runs the actual org.apache.camel.main.Main embedded Vert.x/Netty HTTP server and drives it with real curl over localhost — a genuine api_remote boundary.