Graph-Wrecking Ball: Inside CVE-2025-66169 (Apache Camel Cypher Injection)

Apache Camel is the self-proclaimed "glue" of the internet. It connects Point A to Point B, translates XML to JSON, speaks MQTT, HTTP, and about 300 other dialects. Ideally, it acts as a secure conduit. But in the case of CVE-2025-66169, the glue turned out to be toxic.

The vulnerability lies in the camel-neo4j component, which allows Camel routes to interact with Neo4j graph databases. Graph databases are powerful tools for mapping relationships, but they rely on a query language called Cypher. Much like SQL, Cypher is powerful. And much like SQL, if you construct Cypher queries by blindly pasting user input into a string, you are begging for disaster.

This vulnerability is a classic case of "we trusted the input because it looked like JSON." It wasn't just JSON. It was a weaponized string designed to break out of the query logic and execute arbitrary commands against the database backend.

The root cause here is so old-school it hurts. It’s the exact same logic error that gave us SQL Injection in the late 90s, just ported to a modern graph database context. The developers used String.format() to construct database queries dynamically.

In Neo4jProducer.java, the code took the message body (assumed to be a JSON string representing node properties) and injected it directly into a CREATE statement template. The logic assumed that the input would always be a harmless set of key-value pairs like {"name": "Alice"}.

But assumptions are the mother of all vulnerabilities. The code failed to realize that a String is just a sequence of characters, and some of those characters (like parentheses ) or keywords like MATCH) have special meaning to the Cypher query engine. By not treating the input as a parameter, the component allowed data to become code.

Let's look at the diff. The vulnerable code was deceptively simple, creating a false sense of security through brevity.

The Vulnerable Code:

if (body instanceof String) {
    // Case we get the object in a Json format
    // DANGER: Direct concatenation of 'body' into the query string
    query = String.format("CREATE (%s:%s %s)", alias, label, body);
}

If body is legitimate JSON, you get CREATE (n:User {"a":1}). But if body contains malicious syntax, it becomes part of the command structure.

The Fix (Commit 66715d3): The patch introduces parameterization. Instead of pasting the string into the query, the developers now parse the JSON into a Map and pass it to the driver as a bounded parameter ($props).

// The Fixed Code
var query = String.format("CREATE (%s:%s $props)", alias, label);
// Parse string to Map first
Map<String, Object> bodyMap = OBJECT_MAPPER.readValue((String) body, MAP_TYPE_REF);
// Pass as parameter
properties = Map.of("props", bodyMap);

By using $props, the Neo4j driver treats the entire input map as a single literal value. Even if the input contains DELETE n, the database just creates a node with a property that literally says "DELETE n", rather than executing the instruction.

Exploiting this requires understanding Cypher syntax. The goal is to close the CREATE statement's property block, chain a new command, and comment out the trailing characters that the code appends.

Target Query Structure: CREATE (n:User <INJECTION_POINT>)

The Payload: To break out, we need to close the curly brace and parenthesis. A devastating payload would look like this: }) WITH 1 AS dummy MATCH (n) DETACH DELETE n //

The Executed Query:

CREATE (n:User {})
WITH 1 AS dummy
MATCH (n)
DETACH DELETE n
//)

Breakdown:

1. CREATE (n:User {}): Completes the original statement (safely creating an empty node).
2. WITH 1 AS dummy: Cypher often requires a WITH clause to transition between writing (CREATE) and reading/matching, or to separate query parts.
3. MATCH (n) DETACH DELETE n: This is the nuclear option. It matches all nodes (n) and deletes them, along with their relationships (DETACH).
4. //: Comments out the closing parenthesis ) that the Java code blindly appended at the end.

From a hacker's perspective, this is as clean as it gets. No blind boolean inference needed—just straight execution.

This isn't just a "read-only" vulnerability. Because the injection happens in a CREATE context (and similar logic existed in DELETE and MATCH operations via headers), an attacker effectively gains the privileges of the database user configured in Camel.

If that user has write access (which it almost certainly does, given it's a Neo4jProducer), the attacker can:

1. Wipe the Database: As demonstrated, DETACH DELETE is trivial.
2. Exfiltrate Data: By injecting RETURN statements or creating side-channel nodes containing sensitive data found via MATCH.
3. Corrupt Data: Modify existing relationships in the graph, potentially altering application logic or access controls downstream.

In a microservices architecture where Camel is the gatekeeper, this vulnerability essentially removes the gate.

The only reliable fix is to upgrade the component to a version that enforces parameterization. Regrettably, manual input sanitization (like trying to block ) or MATCH) is error-prone and easily bypassed.

Upgrade Paths:

• Camel 4.10.x → Upgrade to 4.10.8
• Camel 4.14.x → Upgrade to 4.14.3
• Camel 4.15/4.16 → Upgrade to 4.17.0

If you cannot upgrade immediately, ensure that the input reaching the neo4j endpoint is strictly validated against a schema that forbids Cypher syntax characters, or place a WAF in front of the route to detect common injection patterns.