CVE-2026-79986 — camel-azure-files: consumer builds the remote path from the share listing without containment

Reproducer repository for the Apache Camel vulnerability where the azure-files consumer — which derives from the same RemoteFileConsumer base class as the other remote-file consumers and composes the remote path through a plain concatenation helper — builds the remote path of each polled file by concatenating the configured directory with the name reported in the Azure File share listing, with no containment check. A listing name that is not a single path segment therefore resolved outside the polled directory for retrieval and, with delete/move/preMove/ moveFailed/readLock=rename, deletion or rename.

This reproducer is author-only — see below — and is the Azure-Files sibling of the runnable CVE-2026-79983 (camel-ftp) and CVE-2026-79984 (camel-mina-sftp), which demonstrate the identical root cause and fix end to end against an embedded malicious server.

Why author-only

1. As the advisory states, reaching the issue "requires a listing name that is not a single path segment, which the Azure Files REST service does not normally return; the exposure was corrected on the same basis as the other remote-file consumers rather than from a demonstrated proof of concept against this scheme."
2. A live run additionally requires a real Azure Storage account and File share.

So this repository carries the exact affected consumer wiring (a real camel-azure-files route, see AzureFilesRoute.java / AzureFilesRoutes.java), documents the mechanism and fix, and defers the runnable end-to-end demonstration to the FTP and SFTP reproducers above.

Runtime	Directory	Stack
Camel Spring Boot	camel-spring-boot/	Spring Boot 3.5.13 + camel-azure-files 4.22.0 (affected; fixed 4.22.1)
Camel Quarkus	camel-quarkus/	Quarkus 3.29.0 + camel-quarkus-azure-files 3.29.0 (Camel 4.15.0, affected)

Both modules compile and start cleanly without Azure credentials (the route is defined with autoStartup=false). Set -Daz.enabled=true with az.account/az.share/az.sharedKey to point the exact affected route at an Azure File share of your own.

cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack   # prints the explanation + links to the runnable PoCs
docker compose down

Vulnerability Summary

Property	Value
Component	camel-azure-files (azure-files scheme)
CWE	CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)
Severity	HIGH
Attack vector	A share-listing name (server-supplied) that is not a single path segment
Impact	Read — and, with delete/move/readLock=rename, delete or rename — files outside the polled directory, using the endpoint's credentials
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-24487
Credit	Dilrevx from NSSL, SJTU

Advisory: https://camel.apache.org/security/CVE-2026-79986.html

The fix

The azure-files consumer now applies the same containment check as the other remote-file consumers: a resolved path that falls outside the polled directory is skipped with a warning, so a listing name carrying traversal segments no longer reaches the retrieve/delete/rename operand.

Mitigation if you cannot upgrade

Constrain the consumer with filter/antInclude/include to accept only single-segment names, and avoid delete/move/preMove/moveFailed/readLock=rename against shares whose listings are not fully trusted.

Disclaimer

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. Do not use this material against systems you do not own or operate.