CVE-2021-34371

Neo4j with the shell server enabled exposes an RMI service that will deserialize arbitrary Java objects it's handed, for instance through setSessionVariable. That's the classic unsafe-deserialization trap: because exploitable gadget chains exist in the dependencies, an attacker who can reach the RMI port sends a crafted serialized payload and gets remote code execution on the database host. Unauthenticated, remote, no interaction — the deserialization is the whole exploit.

Java deserialization bugs are a mature, well-tooled attack class; ready-made gadget-chain payloads exist and get reused, so weaponization is fast once a reachable listener is found. The critical precondition, and it's a real one, is that the shell server has to be enabled and its RMI port reachable. That narrows exposure considerably — many deployments don't run it — but any instance that does, with the port on an accessible network, is a straightforward RCE target for anyone scanning for exposed RMI services.

For us this is a reachability-and-configuration hunt more than a version sweep. We'd identify Neo4j instances at or below 3.4.18, then check the two things that actually gate it: is the shell server enabled, and is that RMI port exposed beyond localhost or a trusted segment? An exposed listener is an emergency; a disabled shell server or a firewalled port drops the same version far down the list. Blocking the RMI port is an immediate virtual-patch where upgrading lags.