CVE-2026-40022: 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.

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