The "obfuscate_literals" option in the query logs does not redact error information, exposing unredacted data in the query log when a customer writes a query that fails. It can allow a user with legitimate access to the local log files to obtain information they are not authorised to see. If this user is also in a position to run queries and trigger errors, this vulnerability can potentially help them to infer information they are not authorised to see through their intended database access.
We recommend upgrading to versions 2026.01.3 (or 5.26.21) where the issue is fixed, and reviewing query log files permissions to ensure restricted access. If your configuration had db.logs.query.obfuscate_literals enabled, and you wish the obfuscation to cover the error messages as well, you need to enable the new configuration setting db.logs.query.obfuscate_errors once you have upgraded Neo4j.
Metrics
Affected Vendors & Products
No advisories yet.
Solution
We recommend upgrading to versions 2026.01.3 (or 5.26.21) where the issue is fixed, and reviewing query log files permissions to ensure restricted access. If your configuration had db.logs.query.obfuscate_literals enabled, and you wish the obfuscation to cover the error messages as well, you need to enable the new configuration setting db.logs.query.obfuscate_errors once you have upgraded Neo4j.
Workaround
No workaround given by the vendor.
| Link | Providers |
|---|---|
| https://neo4j.com/security/CVE-2026-1622 |
|
Wed, 04 Feb 2026 10:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Neo4j Enterprise and Community editions versions prior to 2026.01.3 and 5.26.21 are vulnerable to a potential information disclosure by a user who has ability to access the local log files. The "obfuscate_literals" option in the query logs does not redact error information, exposing unredacted data in the query log when a customer writes a query that fails. It can allow a user with legitimate access to the local log files to obtain information they are not authorised to see. If this user is also in a position to run queries and trigger errors, this vulnerability can potentially help them to infer information they are not authorised to see through their intended database access. We recommend upgrading to versions 2026.01.3 (or 5.26.21) where the issue is fixed, and reviewing query log files permissions to ensure restricted access. If your configuration had db.logs.query.obfuscate_literal enabled, and you wish the obfuscation to cover the error messages as well, you need to enable the new configuration setting db.logs.query.obfuscate_errors once you have upgraded Neo4j. | Neo4j Enterprise and Community editions versions prior to 2026.01.3 and 5.26.21 are vulnerable to a potential information disclosure by a user who has ability to access the local log files. The "obfuscate_literals" option in the query logs does not redact error information, exposing unredacted data in the query log when a customer writes a query that fails. It can allow a user with legitimate access to the local log files to obtain information they are not authorised to see. If this user is also in a position to run queries and trigger errors, this vulnerability can potentially help them to infer information they are not authorised to see through their intended database access. We recommend upgrading to versions 2026.01.3 (or 5.26.21) where the issue is fixed, and reviewing query log files permissions to ensure restricted access. If your configuration had db.logs.query.obfuscate_literals enabled, and you wish the obfuscation to cover the error messages as well, you need to enable the new configuration setting db.logs.query.obfuscate_errors once you have upgraded Neo4j. |
Wed, 04 Feb 2026 09:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Neo4j Enterprise and Community editions versions prior to 2026.01.3 and 5.26.21 are vulnerable to a potential information disclosure by a user who has ability to access the local log files. The "obfuscate_literals" option in the query logs does not redact error information, exposing unredacted data in the query log when a customer writes a query that fails. It can allow a user with legitimate access to the local log files to obtain information they are not authorised to see. If this user is also in a position to run queries and trigger errors, this vulnerability can potentially help them to infer information they are not authorised to see through their intended database access. We recommend upgrading to versions 2026.01.3 (or 5.26.21) where the issue is fixed, and reviewing query log files permissions to ensure restricted access. If your configuration had db.logs.query.obfuscate_literal enabled, and you wish the obfuscation to cover the error messages as well, you need to enable the new configuration setting db.logs.query.obfuscate_errors once you have upgraded Neo4j. | |
| Title | Unredacted data exposure in query.log | |
| First Time appeared |
Neo4j
Neo4j community Edition Neo4j enterprise Edition |
|
| Weaknesses | CWE-532 | |
| CPEs | cpe:2.3:a:neo4j:community_edition:*:*:*:*:*:*:*:* cpe:2.3:a:neo4j:enterprise_edition:*:*:*:*:*:*:*:* |
|
| Vendors & Products |
Neo4j
Neo4j community Edition Neo4j enterprise Edition |
|
| References |
| |
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: Neo4j
Published:
Updated: 2026-02-04T10:02:57.648Z
Reserved: 2026-01-29T14:23:26.871Z
Link: CVE-2026-1622
No data.
Status : Received
Published: 2026-02-04T10:16:04.780
Modified: 2026-02-04T11:16:02.943
Link: CVE-2026-1622
No data.
OpenCVE Enrichment
No data.