CVE-2026-1622: 
Java vulnerability analysis and mitigation

CVE-2026-1622 is an information disclosure vulnerability in Neo4j Enterprise and Community editions affecting versions prior to 2026.01.3 and 5.26.21 (Maven package org.neo4j:neo4j). The flaw causes the db.logs.query.obfuscate_literals query log setting to fail to redact error messages, exposing unredacted sensitive data in query logs when a query fails. It was published on February 4, 2026, with patches released the same day. The vulnerability carries a CVSS v4.0 base score of 4.8 (Medium) (GitHub Advisory, Neo4j Advisory).

The root cause is classified as CWE-532 (Insertion of Sensitive Information into Log File). When db.logs.query.obfuscate_literals is enabled, Neo4j is expected to redact literal values from query logs; however, error messages generated by failed queries bypass this obfuscation and are written to the query log in plaintext. Exploitation requires local access to the Neo4j host, low-level privileges (e.g., a legitimate user account), and the ability to read query log files — no network access or user interaction is needed. An attacker who can also execute queries and deliberately trigger errors may further leverage error messages to infer data they are not authorized to access through their normal database permissions (GitHub Advisory, Neo4j Advisory).

Successful exploitation results in a low-severity confidentiality impact: authenticated users with local log file read access can view unredacted sensitive data (e.g., literal values from failed queries) that should have been obfuscated. There is no impact to integrity or availability. The vulnerability is limited to the local system and does not directly enable lateral movement, remote code execution, or privilege escalation, but could expose database content details that assist further attacks against the database (GitHub Advisory).

1. Identify a vulnerable Neo4j instance: Confirm the target is running Neo4j Enterprise or Community edition prior to version 5.26.21 or 2026.01.3, and that db.logs.query.obfuscate_literals=true is set in the configuration.
2. Obtain local log file access: As an authenticated user with filesystem read permissions on the Neo4j host, locate the query log file (typically at <neo4j-home>/logs/query.log).
3. Trigger query errors: Using a Neo4j database account, execute Cypher queries that are expected to fail — for example, queries referencing non-existent properties or using invalid literal values — so that error messages containing unredacted data are written to the query log.
4. Read the query log: Access the query log file and inspect error entries, which will contain unredacted literal values from failed queries that should have been obfuscated, potentially revealing sensitive database content (GitHub Advisory, Neo4j Advisory).

• Logs: Query log entries (query.log) containing error messages with unredacted literal values when db.logs.query.obfuscate_literals is enabled; repeated failed query attempts from a single user account that appear designed to trigger specific error conditions.
• File System: Unusual access timestamps on Neo4j query log files (<neo4j-home>/logs/query.log) by non-administrative user accounts; unexpected copying or archiving of log files by low-privileged users.
• Process/Audit: OS-level audit logs (e.g., Linux auditd) showing read access to Neo4j log directories by accounts that do not normally access them.

Upgrade Neo4j to version 2026.01.3 (for the 2025.x/2026.x release line) or 5.26.21 (for the 5.x release line) where the issue is fixed. After upgrading, enable the new configuration setting db.logs.query.obfuscate_errors=true to ensure error messages are also covered by log obfuscation. Additionally, review and restrict filesystem permissions on query log files to limit access to only authorized administrators. If db.logs.query.obfuscate_literals was previously enabled, review existing query log files for any exposed sensitive information (GitHub Advisory, Neo4j Advisory).

The vulnerability was assigned and disclosed by Neo4j on February 4, 2026, with a patch available on the same day. Coverage has been limited to standard vulnerability tracking platforms (NVD, GitHub Advisory Database, Vulners, INCIBE) with no notable researcher commentary or significant social media discussion, consistent with the moderate severity and limited exploitability of the flaw (GitHub Advisory).