Exploit for CVE-2026

# CVE-2026-79986 — camel-azure-files: consumer builds the remote path from the 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 ** 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.

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 .

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.

| **Camel Spring Boot** | [`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/`](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. `/`az.sharedKey` to point the exact affected route at an Azure File

curl -s # prints the explanation + links to the runnable PoCs

| **Component** | `camel-azure-files` (`azure-files` scheme) |

| **CWE** | CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) |

| **Attack vector** | A -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]( |

Advisory:

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.

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.

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.