Skip to main content

Apache Camel MLLP CVE-2026-85260

| EUVDEUVD-2026-104196 MEDIUM
Insertion of Sensitive Information into Log File (CWE-532)
2026-10-19 apache GHSA-9gc9-j9wv-mmw8
5.5
CVSS 3.1 · Vendor: apache
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Gain read access to application/aggregated logs
  2. Exploit
    MLLP routes HL7 clinical messages
  3. Execution
    logPhi default (or ignored paths) writes payloads
  4. Impact
    Harvest PHI from log entries

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A09:2025 - Security Logging & Alerting Failures
ASVS 5.0
V16 - Security Logging and Error Handling Log data sanitization
Exploitation Conditions

Requires the camel-mllp component to be in active use carrying HL7 clinical messages (a healthcare-integration deployment) AND read access to the application logs where payloads are written. Exposure occurs by default because logPhi defaulted to true, and critically two code paths wrote payload content to the log regardless of the logPhi setting - so even a deployment that explicitly set logPhi=false remained exposed on those paths until upgrading. Limiting factors: this is not remotely triggerable as an active attack (AV:L) - the 'attacker' must already be able to read the logs; impact is confined to deployments using MLLP/HL7; and severity scales with how broadly logs are aggregated and accessed. Mitigation short of upgrade is setting logPhi=false plus restricting log access, with the caveat that two paths keep logging until the fix (4.18.5/4.22.1/4.23.0) is applied.

Impact

This is a genuine data-exposure defect but a low-urgency one in attacker terms. The CVSS 5.5 vector (AV:L/AC:L/PR:L/UI:N/C:H/I:N/A:N) correctly frames it as a local, low-privilege confidentiality-only issue rather than a remotely weaponizable flaw: there is no code execution, no integrity or availability impact, and the 'attack' is really passive - PHI is written to ordinary application logs, and whoever can read those logs gains the data. No EPSS score, KEV listing, or public POC was provided, which is consistent with a logging/information-disclosure bug that has no exploit to write: exploitation status is 'no public exploit identified at time of analysis.' The real risk is driven by exposure and compliance (HL7 patient data landing in logs governed by general log retention/aggregation/access controls, not clinical-record controls), not by ease of remote attack. Two caveats to flag explicitly: (1) the CVSS C:H assumes the reader of the logs is not authorized for the PHI, so real impact depends entirely on who can access the logs - a well-segregated log store lowers it, a centralized SIEM/log-aggregation pipeline widens exposure considerably; (2) the defaulted-to-true behavior plus two paths that logged regardless of the setting mean many deployments were exposed out of the box, so the practical breadth is larger than the modest CVSS number suggests. Priority should be set by regulatory exposure (HIPAA/PHI handling), not by the 5.5 base score alone.

Exploit ScenarioDerived

An Apache Camel deployment using the camel-mllp component to route HL7 clinical messages runs with default settings, so full HL7 payloads containing patient data are written to application logs; even operators who set logPhi=false remain exposed on two code paths that log payloads regardless. Anyone with read access to those logs - a log-aggregation platform, SIEM, backup, or a lower-privileged operator - can harvest protected health information. No public exploit is required, as this is passive information disclosure rather than an active attack.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 19, 2026

Apache Camel's camel-mllp component writes HL7 clinical message payloads containing protected health information into ordinary application logs, because the logPhi option defaulted to true and two additional code paths logged payload content even when an operator had explicitly set logPhi=false. Deployments running Camel 4.0.0 through 4.18.4, or 4.19.0 through 4.22.0, that use the MLLP transport for healthcare integration are exposed out of the box; anyone who can read the resulting logs - local authenticated users per the CVSS vector (AV:L/PR:L, C:H) - can recover patient data that was never meant to land in general-purpose log storage with its broader retention, aggregation and access surface. This is a genuine data-exposure defect but a low-urgency one in attacker terms, since it is not remotely triggerable and merely requires pre-existing log read access; no public exploit code was identified at time of analysis, and vendor patches are available. Note that simply setting logPhi=false is not a complete workaround, as two code paths continue to log payloads until the fix is applied.

RemediationAI

Vendor-released patch: upgrade to Apache Camel 4.23.0 for mainline users, to 4.18.5 if you are on the 4.18.x LTS stream, or to 4.22.1 if you are on the 4.22.x LTS stream; the fixes are delivered through upstream pull requests https://github.com/apache/camel/pull/25832, https://github.com/apache/camel/pull/25944 and https://github.com/apache/camel/pull/25946, and the advisory at https://camel.apache.org/security/CVE-2026-85260.html is the notice of the changed default. Be aware that the upgrade itself changes behaviour: logPhi now defaults to false, so any deployment that relied on payload logging for troubleshooting or audit must explicitly set logPhi=true after upgrading, or those log lines will disappear - treat this as an intentional configuration decision and document it, since re-enabling payload logging reintroduces the PHI-in-logs exposure. If you cannot upgrade immediately, set logPhi=false on every MLLP endpoint, but understand the trade-off that this is only a partial mitigation: two code paths will keep writing payload content to the log until the patched version is installed, so pair it with concrete log-side controls - restrict read access to the application log files and the log aggregation platform to the minimum set of operators, shorten retention on those indices, and suppress or redact forwarding of the Camel loggers that emit MLLP payloads to shared SIEM or centralized stores. Each of these has a cost: narrowed access can slow incident triage, shortened retention reduces forensic history, and redaction rules must be reverted cleanly after upgrading to avoid silently dropping unrelated log data. Where logs already contain HL7 payloads, treat the affected log stores as clinical-data repositories and purge them in line with your HIPAA or equivalent breach-assessment obligations.

Affected VersionsENISA

Apache Camel 4.19.0 <4.22.1
Apache Camel 4.0.0 <4.18.5

Affected Packages

euvd apache_camel fix: 4.18.5, 4.22.1

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

MLLP (Minimal Lower Layer Protocol) is the simple TCP framing protocol widely used to exchange HL7 v2 clinical messages between hospital systems - ADT feeds, orders, results and similar traffic that routinely carries patient identifiers and clinical detail. Apache Camel's camel-mllp component implements an MLLP consumer/producer pair, and its component metadata exposed an advanced boolean option, logPhi, whose stated purpose was to control 'Whether to log PHI' (protected health information). The defect is CWE-532 (Insertion of Sensitive Information into Log File): the option's defaultValue was true in both the generated catalog descriptors (catalog/camel-catalog/.../mllp.json and components/camel-mllp/src/generated/resources/META-INF/.../mllp.json), so a deployment that configured nothing silently inherited payload logging, and additionally two internal code paths in MllpComponent emitted payload content irrespective of the flag, defeating the opt-out. The result is that clinical payload data flowed into the standard logging framework and thus into whatever sinks, retention policies and access controls the deployment applies to application logs generally, rather than into a system governed as clinical records. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects that the exposure is realized by a locally positioned, authenticated reader of those logs - confidentiality-only impact, high for the data concerned, with no integrity or availability effect and an unchanged scope. The associated fixes lower the default to false and route all payload logging through the honoured option. Affected CPE coverage is expressed generically as cpe:2.3:a:apache_software_foundation:apache_camel, so version-range matching rather than a component-specific CPE must be used to identify exposure.

Know when Apache Camel gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (apache) PRIMARY 5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
vuln.today AI 5.5 MEDIUM

PHI disclosure via local log access requires some privilege to read logs (PR:L, AV:L); no integrity or availability impact, and confidentiality is high because full patient payloads are exposed.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

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
None
Availability
None

DescriptionCVE.org

Insertion of Sensitive Information into Log File vulnerability in Apache Camel MLLP component.

This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.

The camel-mllp component carries a logPhi option that governs whether HL7 payload content may be written to the log. It defaulted to true, so a deployment that did nothing logged protected health information out of the box. Two further paths wrote payload content to the log regardless of the setting, so even an operator who had turned logPhi off was still exposed on those paths. MLLP is used to carry HL7 clinical messages, so the content concerned is patient data, and it reached ordinary application logs where it is subject to whatever retention, aggregation and access the deployment applies to logs generally rather than to clinical records.

Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. logPhi now defaults to false and is honoured on the paths that previously ignored it. This is a changed default: a deployment that relied on payload logging must now set logPhi=true explicitly. Because the upgrade guide for a change like this lives on the main branch only, operators upgrading within the 4.18.x or 4.22.x lines should treat this advisory as the notice of that change. For deployments that cannot upgrade immediately, set logPhi=false and be aware that two paths will continue to log payload content until the fix is applied; restrict access to the logs accordingly.

Threat Intelligence Overview

EPSS Score
0.2%
Top 96% exploitable
Prevalence
Medium
widely-used integration framework, but MLLP component is healthcare-HL7-specific
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation
None
System Exposure· derived
Small
Automatable
No
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

28
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +28
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

CVE-2026-33453 CRITICAL POC
10.0 Apr 27

Remote code execution in Apache Camel's camel-coap component (versions 4.14.0-4.14.5, 4.18.0 before 4.18.1, and 4.19.0)

CVE-2026-40858 HIGH POC
8.8 Apr 27

Unsafe Java deserialization in Apache Camel's camel-infinispan component allows arbitrary code execution when the ProtoS

CVE-2026-78162 CRITICAL
10.0 Oct 19

Unauthenticated remote code execution affects the camel-hazelcast component of Apache Camel 4.0.0 through 4.18.4 and 4.1

CVE-2026-71300 CRITICAL
9.8 Aug 24

Header-injection in the Apache Camel camel-atmosphere-websocket producer lets an external sender hijack WebSocket messag

CVE-2026-78329 CRITICAL
9.8 Aug 24

Header-filter bypass in the Apache Camel Undertow component (4.11.0-4.14.8, 4.15.0-4.18.3, and 4.19.0-4.21.x) lets remot

CVE-2026-47323 CRITICAL
9.8 May 19

Remote code execution in Apache Camel 3.18.0-4.14.5 and 4.15.0-4.18.1 stems from CXF and Knative HeaderFilterStrategy im

CVE-2026-33454 CRITICAL
9.4 Apr 27

Message header injection in Apache Camel's camel-mail component (3.0.0 before 4.14.6 and 4.15.0 before 4.18.1) lets an a

CVE-2026-46590 HIGH
8.8 Jul 06

Remote code execution via unsafe Java deserialization affects the camel-pqc component of Apache Camel 4.18.0-4.18.2 and

CVE-2026-27172 HIGH
8.8 Apr 27

Unsafe Java deserialization in Apache Camel's camel-consul component (ConsulRegistry / ConsulRegistryUtils.deserialize)

CVE-2026-88900 HIGH
8.8 Oct 19

Unauthenticated deserialization of attacker-controlled messages in Apache Camel's camel-jgroups consumer can lead to rem

CVE-2026-83531 HIGH
8.8 Oct 19

Expression language injection in the Apache Camel dynamic-router-control endpoint allows a party who can place a message

CVE-2026-78165 HIGH
8.8 Oct 19

Deserialization of untrusted data in the Apache Camel Spring Redis component (camel-spring-redis) allows an authenticate

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy