Enterprise Edition

Neo4j's Bolt modern handshake decoder treats an overlong capability bit mask the same way it treats a truncated bit mask. When an unauthenticated client sends a selected protocol version followed by 32 continuation bytes in the capability mask, the decoder resets the reader index and waits for more bytes instead of rejecting the protocol message and closing the channel. Because the same unread bytes remain at the front of the decoder buffer, appending a terminating byte later does not recover the connection. The decoder re-reads the same first 32 continuation bytes, returns without producing a handshake-finalization message, and leaves the channel open. This can be triggered before authentication by any client that can reach the Bolt connector.

Published: 2026-08-05T16:10:47.327Z
Updated: 2026-08-05T18:41:20.229Z

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.

Published: 2026-02-04T09:14:46.320Z
Updated: 2026-02-04T15:12:37.400Z

An edgecase in SSO implementation in Neo4j Enterprise edition versions prior to version 2026.02 can lead to unauthorised access under the following conditions: If a neo4j admin configures two or more OIDC providers AND configures one or more of them to be an authorization provider AND configures one or more of them to be authentication-only, then those that are authentication-only will also provide authorization. This edgecase becomes a security problem only if the authentication-only provider contains groups which have higher privileges than provided by the intended (configured) authorization provider. When using multiple plugins for authentication and authorisation, prior to the fix the issue could lead to a plugin configured to provide only authentication or authorisation capabilities erroneously providing both capabilities.  We recommend upgrading to versions 2026.02 (or 5.26.22) where the issue is fixed.

Published: 2026-03-11T16:16:35.346Z
Updated: 2026-03-12T16:19:58.434Z

Incorrect resolving of namespaces in composite databases in Neo4j Enterprise edition prior to versions 2026.02 and 5.26.22 can lead to the following scenario:  an admin that intends to give a user an access to a remote database constituent "namespace.name" will inadvertently grant access to any local database or remote alias called "name". If such database or alias doesn't exist when the command is run, the privileges will apply if it's created in the future.

Published: 2026-03-11T15:50:57.651Z
Updated: 2026-03-12T16:13:58.620Z

Excessive caching of authentication context in Neo4j Enterprise edition versions prior to 2026.01.4 leads to authenticated users inheriting the context of the first user who authenticated after restart. The issue is limited to certain non-default configurations of SSO (UserInfo endpoint).  We recommend upgrading to versions 2026.01.4 (or 5.26.22) where the issue is fixed.

Published: 2026-03-11T16:30:24.053Z
Updated: 2026-03-11T20:09:18.652Z