CVE-2026-64678 · Package
NO FIX YET · SEE WHAT TO DO
Nitrite, a Java embedded NoSQL document store, automatically deserializes stored values with Java's ObjectInputStream when it opens an old-format database file, with no class allowlist. An attacker who can supply a crafted database file, and who has a suitable gadget class on the classpath, can run code in the host application.
first public Jul 2, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications that embed Nitrite versions before 4.4.1 and open database files that may have been created or modified by an untrusted party are exposed, since the migration path runs on any file with a legacy format. Applications that only open database files they created themselves, or that use a current format, are less exposed. Exploitation also needs a gadget class on the classpath, which is common in Java applications but not guaranteed.
Not affected if only-trusted-database-files, version-4.4.1-or-later
Who cares embedded-database, java, nitrite
pom.xml or build.gradle) or the dependency tree; a version below 4.4.1 is affected4.4.1 or laterNOsql Object (NO2 a.k.a Nitrite) database is an open source nosql embedded document store. Prior to version 4.4.1, when Nitrite opens a database file, MVStoreUtils.openOrCreate() automatically checks for a legacy v1-format store and, on detecting one (or hitting a compatibility error while opening), triggers an automatic migration path. This path deserializes stored values using NitriteDataType.deserialize(byte[]), which passes the raw bytes directly to java.io.ObjectInputStream.readObject() via a custom NitriteObjectInputStream subclass. That subclass overrides only readClassDescriptor() — solely to remap a handful of known legacy class names to their current equivalents — and implements no class allowlist, blocklist, or ObjectInputFilter (JEP 290). Any Serializable class reachable on the embedding application's classpath can therefore be instantiated via readObject(), with readObject()/readExternal()/readResolve() callbacks invoked unconditionally. If a suitable gadget class (e.g. from commons-collections or similar) happens to be present on the classpath, this is a precondition for remote code execution. This issue has been patched in version 4.4.1.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.