Graph Graffiti: Injecting Chaos into Apache Camel's Neo4j Component

Apache Camel is the 'glue code' of the enterprise world. It routes messages from A to B, transforms them, and pipes them into databases. It’s magic, until the magician gets drunk and starts sawing the assistant in half for real.

The camel-neo4j component is designed to take a message—say, a JSON object representing a user—and persist it into a Neo4j graph database. Ideally, this happens safely. In reality, prior to version 4.10.8, the component was treating database queries like a game of Mad Libs, pasting user input directly into the command string without a second thought.

This isn't just a bug; it's a structural failure in how the component handles trust. It assumed that anything coming down the Camel route was friendly. In a world of microservices and public-facing API gateways, that assumption is the digital equivalent of leaving your front door unlocked because you live in a 'nice neighborhood.'

The root cause here is so classic it belongs in a museum. The vulnerability resides in Neo4jProducer.java. When the component prepares to create or delete a node, it needs to build a Cypher query (Neo4j's query language).

Instead of using parameterized queries—which have been the industry standard since the late 90s—the developers opted for String.format(). If the incoming message body was a String, it was shoved directly into the query template.

Here is the logic flaw in high definition:

1. Camel receives a message.
2. Camel checks if the body is a String.
3. Camel interpolates that String directly into a CREATE or MATCH statement.

This means the database engine cannot distinguish between the developer's code and the attacker's data. To the Neo4j engine, your malicious payload looks just like valid instructions.

Let's look at the vulnerable code. It’s breathtaking in its simplicity and danger. In the createNode method, we see this gem:

// The Vulnerable Code
if (body instanceof String) {
    // directly injecting 'body' into the query string
    query = String.format("CREATE (%s:%s %s)", alias, label, body);
}

If alias is n, label is User, and body is {name: 'Alice'}, you get CREATE (n:User {name: 'Alice'}). Harmless, right?

But now, look at the patch. The fix involved ripping out the string formatting and introducing the ObjectMapper to parse the string into a Map, which is then passed as a proper parameter.

// The Fix (simplified)
Map<String, Object> bodyMap = OBJECT_MAPPER.readValue((String) body, MAP_TYPE_REF);
properties = Map.of("props", bodyMap);
// using $props parameter
var query = String.format("CREATE (%s:%s $props)", alias, label);

By moving to $props, the Neo4j driver treats the input as a literal value, not executable code. The exploit window is slammed shut—mostly.

Exploiting this requires understanding Cypher syntax. We are inside a CREATE statement: CREATE (n:User <INSERT_HERE>).

To exploit this, we need to:

1. Close the node properties bracket }.
2. Close the node parenthesis ).
3. Start a new Cypher command.
4. Comment out the trailing junk that the original code might append.

The Payload: }) WITH n MATCH (a) DETACH DELETE a //

The Resulting Query:

CREATE (n:User { }) WITH n MATCH (a) DETACH DELETE a //)

Breakdown:

• CREATE (n:User { }): Creates an empty user node. Valid Cypher.
• WITH n: Passes the context forward (Cypher requires WITH to chain creating and matching).
• MATCH (a) DETACH DELETE a: Matches every node in the database (a) and deletes them, removing all relationships (DETACH).
• //): Comments out the closing parenthesis that the Java code blindly appended.

Boom. The database is empty. You could also use CALL apoc.load.json if the APOC plugin is enabled to exfiltrate data to an external server.

The National Vulnerability Database (NVD) rates this a 5.3 (Medium), citing Confidentiality: None and Availability: None. I respectfully disagree with the robot overlords.

While this is technically an Integrity issue (modifying the graph), Cypher injection often allows for blind exfiltration. By manipulating the RETURN clause or using conditional logic (e.g., WHERE n.password STARTS WITH 'A'), an attacker can infer data one bit at a time based on whether the query succeeds or fails (Time-Based or Error-Based injection).

Furthermore, in a graph database, relationships are data. If I can DETACH DELETE your relationships, I haven't just deleted data; I've destroyed the context that makes your data valuable. That is a catastrophic availability and integrity loss.

The remediation is straightforward: Update to Apache Camel 4.10.8, 4.14.3, or 4.17.0. These versions introduce parameterization for the message body.

> [!WARNING] > Researcher Note: The patch fixes the value injection, but a close reading of the diff shows that for the MATCH_PROPERTIES header, the code still iterates over keys and appends them to the query builder: whereClause.append(entry.getKey()).

If you have a route where an attacker can control the keys of a JSON object passed into the headers (less common, but possible in dynamic environments), injection might still be possible. Ensure your input validation whitelists allowed property names before they reach the Camel route.