oscerd/cve-2026-85260Runnable Spring Boot and Quarkus reproducer for CVE-2026-85260, demonstrating camel-mllp PHI logging in affected versions and suppression after the fix.
Runnable proof-of-concept reproducer for the Apache Camel vulnerability where the camel-mllp component's logPhi
option defaulted to true, so a deployment that did nothing wrote HL7 payload content — patient data — to the
application log out of the box. (Two further code paths logged payload content regardless of the setting, so even an
operator who had turned logPhi off was still exposed on those paths.) MLLP carries HL7 clinical messages, so the
content concerned is PHI, and it reached ordinary application logs, subject to whatever retention, aggregation and
access the deployment applies to logs rather than to clinical records.
| Runtime | Directory | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-mllp 4.22.0 (affected; fixed 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.29.0 + camel-quarkus-mllp (Camel 4.15.0, affected; fixed control CQ 3.40.0 / Camel 4.22.1) |
Both modules demonstrate the affected and the fixed behaviour.
An MLLP consumer (TCP server) receives HL7 messages. The component logs the received payload at DEBUG (so the MLLP
loggers are raised to DEBUG, and logs are written to mllp-phi.log). The driver acts as an HL7 sender: it frames an
HL7 message whose PID (patient-name) field carries a benign marker PHI-MARKER-DOE-JANE-5E1F in the MLLP envelope
and sends it, then reads the log file.
Two messages are sent on the one connection on purpose: the consumer processes the first from its validation read, and the second through its receive loop — which is the path that logs the received payload.
logPhi defaults to true, so the log contains Received 170 byte message MSH|…PID|…| PHI-MARKER-DOE-JANE-5E1F^Jane… — the patient data verbatim.logPhi defaults to false, so the log shows <PHI suppressed> instead.# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected: PHI in the log; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85260-mllp-phi-logging-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack # fixed: <PHI suppressed>; >>> Not exploited
# Camel Quarkus
cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected (Camel 4.15.0): PHI in the log
docker compose down
# Patched control: CQ 3.40.0 ships Camel 4.22.1
mvn clean package -Dcamel-quarkus.version=3.40.0 -Dquarkus.platform.version=3.40.0
java -jar target/quarkus-app/quarkus-run.jar &
curl -s http://localhost:8080/exploit/attack # fixed: <PHI suppressed>
| Property | Value |
|---|---|
| Component | camel-mllp (logPhi default; TcpSocketConsumerRunnable, MllpSocketBuffer, Hl7Util) |
| CWE | CWE-532 (Insertion of Sensitive Information into Log File) |
| Severity | MEDIUM |
| Attack vector | HL7 messages received by an MLLP consumer running with default settings and DEBUG logging |
| Impact | Protected health information (patient data) written to ordinary application logs |
| Affected Versions | From 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1 |
| Fixed Versions | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24454 |
| Credit | Claude Security Scan Tool |
Advisory: https://camel.apache.org/security/CVE-2026-85260.html
The fix changes the logPhi default from true to false in
MllpComponent, and routes payload logging through new convertToLoggableString/toLoggableStringAndReset helpers
(and the Hl7Util PHI_SUPPRESSED_REPLACEMENT_VALUE = "<PHI suppressed>"), so the paths that previously ignored the
flag now honour it. This is a changed default: a deployment that relied on payload logging must now set
logPhi=true explicitly.
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.
This repository is published for educational and defensive purposes: to help Apache Camel users understand the vulnerability, verify whether they are affected, and confirm that upgrading resolves it. The HL7 message and its "patient" data are inert, made-up local fixtures. Do not use this material against systems you do not own or operate.