What is the CVSS score of CVE-2026-40048?

CVE-2026-40048 has a CVSS 3.1 base score of 7.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.1%.

Which versions of Apache Camel are affected by CVE-2026-40048?

Apache Camel versions 4.18.0-4.18.1 and 4.19.0-4.19.x contain a deserialization vulnerability in the PQC component allowing arbitrary code execution if an attacker can write malicious objects to the…. A patch is available.

How to fix or mitigate CVE-2026-40048?

Within 24 hours, identify all systems running Apache Camel 4.18.x or 4.19.x with PQC component enabled and audit key storage directory permissions to determine current exposure. Within 7 days, upgrade affected deployments to Apache Camel 4.18.2 (for 4.18.x line) or 4.20.0 (for 4.19.x line). Within 30 days, implement file integrity monitoring on key storage directories and enforce strict file-system access controls that permit write access only to the Camel application service account.

Apache Camel CVE-2026-40048

EUVD-2026-25790 HIGH

Deserialization of Untrusted Data (CWE-502)

2026-04-27 security@apache.org

GHSA-v3vg-332r-mw99

Path Traversal Java Deserialization RCE Apache Camel

7.8

CVSS 3.1 · Vendor: apache

Severity by source

Vendor (apache) PRIMARY

7.8 HIGH

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

vuln.today AI

7.8 HIGH

Attacker needs local write access to the key directory (AV:L, PR:L); once a malicious file is placed, deserialization reliably yields full code execution (C/I/A:H).

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

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

Red Hat

7.8 HIGH

qualitative

Primary rating from Vendor (apache).

CVSS VectorVendor: apache

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 24, 2026 - 02:07 vuln.today

Patch released

Apr 28, 2026 - 19:43 nvd

Patch available

CVSS changed

Apr 27, 2026 - 16:22 NVD

7.8 (None) 7.8 (HIGH)

Patch available

Apr 27, 2026 - 10:01 EUVD

EUVD ID Assigned

Apr 27, 2026 - 09:22 euvd

EUVD-2026-25790

CVE Published

Apr 27, 2026 - 09:16 nvd

HIGH 7.8

Blast Radius

ecosystem impact

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

5 maven packages depend on org.apache.camel:camel-pqc (3 direct, 2 indirect)

Ecosystem-wide dependent count for version 4.18.2.

DescriptionCVE.org

The Camel-PQC FileBasedKeyLifecycleManager class deserializes the contents of <keyId>.key files in the configured key directory using java.io.ObjectInputStream without applying any ObjectInputFilter or class-loading restrictions. The cast to java.security.KeyPair is evaluated only after readObject() has already returned, so any readObject() side effects in the deserialized object run before the type check. An attacker who can write to the key directory used by a Camel application - for example through a path traversal into the directory, misconfigured filesystem permissions on the volume where keys are stored, a compromised key provisioning pipeline, or a symlink attack - can place a crafted serialized Java object that, when deserialized during normal key lifecycle operations, results in arbitrary code execution in the context of the application.

This issue affects Apache Camel: from 4.19.0 before 4.20.0, from 4.18.0 before 4.18.2.

Users are recommended to upgrade to version 4.20.0, which fixes the issue by replacing java.io.ObjectInputStream-based key and metadata storage with standard PKCS#8 (private key) / X.509 SubjectPublicKeyInfo (public key) Base64 JSON encoding. For users on the 4.18.x LTS releases stream, upgrade to 4.18.2.

AnalysisAI

Arbitrary code execution in Apache Camel's PQC component (camel-pqc) arises because FileBasedKeyLifecycleManager deserializes <keyId>.key files with java.io.ObjectInputStream and no ObjectInputFilter or class allow-listing. Because the KeyPair cast happens only after readObject() returns, malicious gadget-chain side effects execute before any type check, letting an attacker who can plant a crafted serialized object in the key directory run code as the application. It affects Camel 4.19.0 before 4.20.0 and 4.18.0 before 4.18.2, carries CVSS 7.8, and has no public exploit identified at time of analysis; EPSS is very low at 0.07%.

Technical ContextAI

The flaw is a classic Java deserialization weakness (CWE-502) in the camel-pqc integration component, which manages post-quantum/asymmetric key material on disk. FileBasedKeyLifecycleManager reads each <keyId>.key file straight into an ObjectInputStream and calls readObject() expecting a java.security.KeyPair, but ObjectInputStream reconstructs whatever class the byte stream names, invoking that class's readObject()/readResolve() and finalizer logic during reconstruction - well before the (KeyPair) cast can reject it. With a suitable gadget chain on the classpath (e.g. Commons-Collections, Spring, or other libraries common in Camel deployments), this reconstruction yields code execution. CPE data scopes the issue to cpe:2.3:a:apache:camel across the listed 4.18.x/4.19.x ranges. Version 4.20.0 removes ObjectInputStream entirely, storing keys as PKCS#8 (private) and X.509 SubjectPublicKeyInfo (public) in Base64 JSON, which is not code-bearing.

RemediationAI

Vendor-released patch: upgrade to Apache Camel 4.20.0, or 4.18.2 on the 4.18.x LTS stream; these replace ObjectInputStream-based key/metadata storage with PKCS#8 and X.509 SubjectPublicKeyInfo Base64 JSON encoding, eliminating the deserialization path (see https://camel.apache.org/security/CVE-2026-40048.html). Note that after upgrading, existing serialized .key files are in the old format, so plan for key re-provisioning/migration to the new encoding. Where immediate patching is not possible, reduce exposure by restricting filesystem permissions on the configured key directory so only the Camel process account can write to it, mounting that volume without attacker-writable paths, and disabling symlink following to blunt the symlink and path-traversal vectors; audit any key-provisioning pipeline that feeds the directory. As a hardening measure, deploy a JVM-wide serialization filter (jdk.serialFilter / ObjectInputFilter) to reject unexpected classes - the trade-off is potential breakage if other components rely on Java serialization, so test before rolling out. Red Hat customers should track https://access.redhat.com/security/cve/CVE-2026-40048 for downstream fixed builds.