# CVE-2026-46591: Apache Camel-Neo4j: JSON property names from the CamelNeo4jMatchProperties header are interpolated into the Cypher WHERE clause without validation, allowing Cypher injection (incomplete remediation of CVE-2025-66169)

> Attackers can inject Cypher queries via JSON keys in the CamelNeo4jMatchProperties header to read, modify, or delete database nodes.

- **Severity:** High 8.2 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 6 Jul 2026
- **Updated:** 6 Jul 2026
- **Also known as:** GHSA-q86m-qjpm-vqcw

## What is CVE-2026-46591?

CVE-2026-46591 is a high-severity code injection vulnerability in Apache Camel, published on 6 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

Improper Neutralization of Special Elements in Data Query Logic vulnerability in Apache Camel Neo4J component.

The camel-neo4j producer builds the Cypher WHERE clause for its match/retrieve and delete operations from the CamelNeo4jMatchProperties map. CVE-2025-66169 addressed Cypher injection through the property values by binding them as query parameters ($paramN), but the property names (the JSON keys of that map) were still concatenated into the query string verbatim in Neo4jProducer.retrieveNodes() and deleteNode(). A property name containing Cypher syntax therefore alters the structure of the executed query. Where a route maps untrusted input into the CamelNeo4jMatchProperties map - for example by passing a request body as the match map, or from a consumer that does not filter inbound Camel* headers - an attacker who controls the JSON key names can inject arbitrary Cypher and read, modify or delete any node or relationship in the Neo4j database. The CamelNeo4jMatchProperties header is itself Camel-prefixed and is filtered by the HTTP header-filter strategy, so a plain HTTP client cannot set it directly; the issue is reachable through routes that deliberately or inadvertently carry untrusted data into that header.
This issue affects Apache Camel: from 4.10.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.

Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, do not populate the CamelNeo4jMatchProperties map from untrusted input: validate or allow-list the property names (for example against ^[A-Za-z_][A-Za-z0-9_]*$) before the Neo4j producer, and ensure that any consumer feeding such a route filters inbound Camel* / camel* headers so the match header cannot be supplied by an external sender.

Weakness: CWE-943 (Improper Neutralization of Special Elements in Data Query Logic)

## Which versions are affected by CVE-2026-46591?

6 open source packages ship an affected version, including org.apache.camel:camel-neo4j. It affects 1 product.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `org.apache.camel:camel-neo4j` | Maven | From 4.10.0 | 4.14.8 |
| `org.apache.camel:camel-neo4j` | Maven | From 4.10.0 | 4.14.8 |
| `org.apache.camel:camel-neo4j` | Maven | From 4.15.0 | 4.18.3 |
| `org.apache.camel:camel-neo4j` | Maven | From 4.15.0 | 4.18.3 |
| `org.apache.camel:camel-neo4j` | Maven | From 4.19.0 | 4.21.0 |
| `org.apache.camel:camel-neo4j` | Maven | From 4.19.0 | 4.21.0 |

Products: Apache Camel.

## How do I fix CVE-2026-46591?

Upgrade org.apache.camel:camel-neo4j to a fixed version for your release line: 4.14.8, 4.18.3 or 4.21.0.

## Is CVE-2026-46591 being exploited?

There is no known exploitation of CVE-2026-46591 in the wild and no public exploit code.

Public exploit code:

- Reproducer for CVE-2026-46591: Apache Camel camel-neo4j Cypher injection via property names in CamelNeo4jMatchProperties, enabling authorization bypass / cross-label data exfiltration (fixed in 4.14.8/4.18.3/4.21.0) (github_poc): https://github.com/oscerd/CVE-2026-46591

## Other vulnerabilities in Apache Camel

- [CVE-2026-33453](https://insights.sbomify.com/CVE-2026-33453/): Apache camel-coap allows header injection that can lead to remote code execution (critical 10.0)
- [CVE-2026-40453](https://insights.sbomify.com/CVE-2026-40453/): Apache Camel has an incomplete fix for CVE-2025-27636 (critical 9.9)
- [CVE-2026-80351](https://insights.sbomify.com/CVE-2026-80351/): Apache Camel K: Camel K Tenant repositories reach Maven execution inside operator pod (critical 9.8)
- [CVE-2026-80352](https://insights.sbomify.com/CVE-2026-80352/): Apache Camel K: Camel K Master trait serviceAccountName YAML injection lets CR author apply arbitrary objects (critical 9.8)
- [CVE-2026-71300](https://insights.sbomify.com/CVE-2026-71300/): Apache Camel: Camel-Atmosphere-Websocket: WebSocket dispatch header injection (critical 9.8)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-46591 and fix it if it is affected.

What it is: CVE-2026-46591 is a high-severity code injection vulnerability in Apache Camel, published on 6 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-46591 in the wild and no public exploit code.

Affected packages and fixed versions:
- org.apache.camel:camel-neo4j (Maven): affected from 4.10.0; fixed in 4.14.8
- org.apache.camel:camel-neo4j (Maven): affected from 4.10.0; fixed in 4.14.8
- org.apache.camel:camel-neo4j (Maven): affected from 4.15.0; fixed in 4.18.3
- org.apache.camel:camel-neo4j (Maven): affected from 4.15.0; fixed in 4.18.3
- org.apache.camel:camel-neo4j (Maven): affected from 4.19.0; fixed in 4.21.0
- org.apache.camel:camel-neo4j (Maven): affected from 4.19.0; fixed in 4.21.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-46591/ (Markdown: https://insights.sbomify.com/CVE-2026-46591/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-46591
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-46591
- OSV: https://osv.dev/vulnerability/CVE-2026-46591

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-46591/
Summaries are generated and may contain mistakes; the official description above is the record.