What is the CVSS score of EUVD-2026-41847?

EUVD-2026-41847 has a CVSS 3.1 base score of 9.8 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.3%.

Which versions of Apache Camel are affected by EUVD-2026-41847?

A critical vulnerability in Apache Camel's Keycloak component (versions 4.15.0-4.18.2, 4.19.0-4.20.x) undermines core authentication defenses by accepting any Bearer token-whether legitimate, forged,…. A patch is available.

How to fix or mitigate EUVD-2026-41847?

Within 24 hours: Audit all systems running Apache Camel 4.15.0-4.18.2 or 4.19.0-4.20.x to identify camel-keycloak deployments and routes with code-execution capability. Within 7 days: Implement compensating controls (configure KeycloakSecurityPolicy with non-empty requiredRoles or requiredPermissions; deploy token validation at API gateway; restrict network access to Camel services). Within 30 days: Monitor vendor advisories for patch release or plan migration to unaffected versions (4.14.x or earlier, or 4.21.x when available).

Apache Camel EUVD-2026-41847

| CVE-2026-53913 CRITICAL

Improper Authentication (CWE-287)

2026-07-05

GHSA-qvc3-6q9x-95pj

Authentication Bypass RCE Apache Camel

9.8

CVSS 3.1 · Vendor

Severity by source

Vendor (CNA) PRIMARY

9.8 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

9.8 CRITICAL

Network-reachable endpoint, default config is vulnerable (AC:L), no credential needed to send a non-null Bearer string (PR:N), full access to protected route yields high C/I/A.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (CNA).

CVSS VectorVendor

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

CVSS changed

Jul 07, 2026 - 13:22 NVD

9.8 (CRITICAL)

Patch available

Jul 06, 2026 - 10:01 EUVD

Analysis Generated

Jul 05, 2026 - 20:26 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

4 maven packages depend on org.apache.camel:camel-keycloak (2 direct, 2 indirect)

Ecosystem-wide dependent count for version 4.15.0.

Description PRE-NVD

Disclosed via oss-security. NVD scoring and full description are pending.

Articles & Coverage 5

News 15 New Kubernetes Vulnerabilities - 8 Critical, 7 High Severity Jul 06, 2026 News 15 New Java Vulnerabilities - 8 Critical, 7 High Severity Patched Jul 06, 2026 News 15 New Apache Vulnerabilities - 8 Critical, 7 High Severity Patched Jul 06, 2026 News 15 New Java Vulnerabilities - 8 Critical, 7 High Severity Patched Jul 05, 2026 News Critical Authentication Bypass in Apache Camel camel-keycloak - CVE-2026-53913 Jul 05, 2026

AnalysisAI

Authentication bypass in Apache Camel's camel-keycloak component (versions 4.15.0-4.18.2 and 4.19.0-4.20.x) allows any caller presenting a non-null Authorization: Bearer header value - including an arbitrary string or a forged, unsigned JWT - to bypass Keycloak token verification entirely and access routes protected by KeycloakSecurityPolicy. The cryptographic token checks (signature, issuer, expiry) are embedded exclusively inside role and permission validation routines that are never invoked when requiredRoles and requiredPermissions are empty, which is the documented default 'Basic Setup.' Where the protected route connects to a code-execution-capable Camel producer, this authentication bypass can escalate to unauthenticated remote code execution; no public exploit has been identified at time of analysis.

Technical ContextAI

The vulnerability resides in KeycloakSecurityProcessor.beforeProcess(), the entry-point processor for KeycloakSecurityPolicy in org.apache.camel:camel-keycloak. The processor runs three checks in sequence: (1) reject requests with no Bearer token, (2) validate roles only if requiredRoles is non-empty, and (3) validate permissions only if requiredPermissions is non-empty. The entire cryptographic verification of the bearer token - JWT signature validation, issuer and expiry checks for local JWTs, or active-state and issuer validation for token introspection against Keycloak - is embedded exclusively within checks (2) and (3). Since both requiredRoles and requiredPermissions default to empty per the documented Basic Setup, neither secondary check executes, and token verification is never reached. This is a structural CWE-636 (Not Failing Securely / Fail-Open) and CWE-306 (Missing Authentication for Critical Function) pattern: the security gate silently grants access in its default state. The setting allowTokenFromHeader also defaults to true, so tokens are read from the inbound HTTP Authorization: Bearer header, making the attack surface network-reachable without any special delivery mechanism. This defect is structurally distinct from CVE-2026-23552, which added an issuer check inside the verification routine - here the verification routine is never entered at all, so that earlier fix did not address this bypass path.

RemediationAI

Upgrade to Apache Camel 4.18.3 if on the 4.18.x LTS stream, or to 4.21.0 for the latest release stream; both were released in early July 2026 and confirmed by the Apache Camel security advisory at https://camel.apache.org/security/CVE-2026-53913.html to contain the fix. The fix restructures KeycloakSecurityProcessor.beforeProcess() so that cryptographic token authentication always executes when a Bearer token is present, independently of role and permission configuration; role and permission checks now run only after successful authentication, and an invalid or unverifiable token is rejected identically to a missing token (the fix is in GitHub PR #23958, commit 1477cb4e87b2c301f1cdcddca5b153fbbef6934b on main, and backported to camel-4.18.x as commit b62170072348cc4073ddf705ad716aa3678d6c09). For deployments that cannot upgrade immediately, three compensating controls are available: first, configure a non-empty requiredRoles or requiredPermissions on every KeycloakSecurityPolicy - this forces the verification path to execute, but introduces a role management burden and may restrict legitimate access if roles are not correctly assigned to all callers; second, set allowTokenFromHeader to false where tokens are not expected from the HTTP request header - this blocks the primary attack vector but may break existing header-based authentication flows for legitimate clients; third, perform token verification at the framework layer (e.g., an API gateway or Camel interceptor/filter) upstream of the KeycloakSecurityPolicy - this adds defense-in-depth but requires careful scope to ensure no routes are inadvertently left unprotected by the upstream verifier. JIRA ticket CAMEL-23738 contains additional commit-level detail.