CVE-2026-1622: Neo4j Information Disclosure Vulnerability

CVE-2026-1622 Overview

CVE-2026-1622 is an information disclosure vulnerability affecting Neo4j Enterprise and Community editions. The vulnerability exists in the query logging functionality where the obfuscate_literals option fails to redact error information. When a query fails, unredacted sensitive data may be exposed in the query log files, allowing users with local log file access to potentially view information they are not authorized to see.

This vulnerability is classified under CWE-532 (Insertion of Sensitive Information into Log File), a common weakness where applications inadvertently log sensitive data that can be accessed by unauthorized parties.

Critical Impact

Users with legitimate access to Neo4j query log files can obtain sensitive information from failed queries that should have been obfuscated, potentially leading to unauthorized data exposure.

Affected Products

• Neo4j Enterprise editions prior to version 2026.01.3
• Neo4j Community editions prior to version 2026.01.3
• Neo4j versions prior to 5.26.21

Discovery Timeline

• 2026-02-04 - CVE-2026-1622 published to NVD
• 2026-02-04 - Last updated in NVD database

Technical Details for CVE-2026-1622

Vulnerability Analysis

The vulnerability stems from an incomplete implementation of Neo4j's query literal obfuscation feature. The db.logs.query.obfuscate_literals configuration option is designed to mask sensitive data in query logs by replacing literal values with placeholders. However, when a query fails and generates an error message, the error information is written to the log without applying the same obfuscation treatment.

This creates a scenario where organizations that have enabled query literal obfuscation—believing their sensitive data is protected in logs—may still have that data exposed through error messages. The attack requires local access to the log files, meaning an insider threat or compromised account with file system access could exploit this weakness.

The vulnerability becomes particularly concerning when combined with a user who can both access log files and execute database queries. Such a user could potentially craft queries designed to fail in ways that expose sensitive information through error messages, effectively using the logging mechanism as an oracle for data they shouldn't be able to access directly.

Root Cause

The root cause is an architectural oversight in Neo4j's logging subsystem. While the obfuscation logic was implemented for normal query logging, the error handling pathway was not updated to apply the same redaction rules. Error messages often contain context about why a query failed, which may include literal values, constraint violations, or other data that reveals information about the database contents.

This is a classic case of incomplete security controls where a protection mechanism was not uniformly applied across all relevant code paths.

Attack Vector

Exploitation requires local access to the system where Neo4j is running, specifically read access to the query log files. The attacker must have legitimate credentials or access that permits viewing these logs.

The attack scenario involves:

1. An attacker gains access to query log files (either through legitimate system access or privilege escalation)
2. The attacker reviews logs for error messages from failed queries
3. Sensitive information that should have been obfuscated is visible in error context
4. Optionally, an attacker with query execution privileges can deliberately craft failing queries to extract specific data through error messages

The vulnerability mechanism centers on the separation between query logging and error logging pathways. When Neo4j processes a query, the obfuscate_literals setting intercepts literal values and replaces them with generic placeholders before writing to logs. However, when an error occurs, the exception handling code generates error messages that may include the original query context, parameters, or constraint information without passing through the obfuscation layer. For detailed technical information, see the Neo4j CVE-2026-1622 Advisory.

Detection Methods for CVE-2026-1622

Indicators of Compromise

• Unusual access patterns to Neo4j query log files by non-administrative users
• Increased frequency of failed queries from specific users or applications
• Query patterns that appear designed to trigger specific error conditions
• Log file access from unexpected processes or user accounts

Detection Strategies

• Monitor file access events for Neo4j query log files (query.log and related files)
• Implement audit logging for all query log file reads by non-root users
• Alert on repeated query failures from the same session or user account
• Review log permissions to identify overly permissive access configurations

Monitoring Recommendations

• Enable file integrity monitoring (FIM) on Neo4j log directories
• Configure SIEM rules to correlate query failures with subsequent log file access
• Implement user behavior analytics to detect anomalous database interaction patterns
• Regularly audit which accounts have access to Neo4j server file systems

How to Mitigate CVE-2026-1622

Immediate Actions Required

• Upgrade Neo4j to version 2026.01.3 or 5.26.21 or later immediately
• Review and restrict file permissions on query log directories to essential administrators only
• Audit recent log file access to identify potential exploitation attempts
• Enable the new db.logs.query.obfuscate_errors setting after upgrading

Patch Information

Neo4j has released patched versions that address this vulnerability. The fix introduces a new configuration setting db.logs.query.obfuscate_errors which extends obfuscation to error messages in the query logs.

Organizations should upgrade to:

• Version 2026.01.3 for the 2026.x branch
• Version 5.26.21 for the 5.x branch

After upgrading, administrators who previously had db.logs.query.obfuscate_literals enabled and wish to obfuscate error messages must also enable the new db.logs.query.obfuscate_errors configuration setting. For complete upgrade instructions and additional guidance, refer to the Neo4j CVE-2026-1622 Advisory.

Workarounds

• Restrict query log file access to only essential system administrators using strict file permissions
• Consider disabling query logging temporarily if sensitive data exposure is a critical concern
• Implement network segmentation to limit which systems can access Neo4j server file systems
• Deploy a log aggregation solution with access controls that prevent direct log file access

# Configuration example - Restrict log file permissions
chmod 600 /var/lib/neo4j/logs/query.log
chown neo4j:neo4j /var/lib/neo4j/logs/query.log

# After upgrade, enable error obfuscation in neo4j.conf
# db.logs.query.obfuscate_literals=true
# db.logs.query.obfuscate_errors=true