Nitriteに任意コード実行の脆弱性、修正版4.4.1あり
Summary
Javaアプリに組み込むNoSQLデータベースNitriteに、細工したデータベースファイルを開くと任意のコードを実行される恐れのある脆弱性が見つかりました。外部からファイルを受け取るアプリを持つ組織は、4.4.1以降への更新を急いでください。
AI summary
Produced by SecPulse using an external AI model; it may contain mistakes. Check the original description and references below before acting on it.
Javaアプリに組み込むNoSQLデータベースNitriteに、細工したデータベースファイルを開くと任意のコードを実行される恐れのある脆弱性が見つかりました。外部からファイルを受け取るアプリを持つ組織は、4.4.1以降への更新を急いでください。
Original description The description as published by the source.
NOsql 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.
Source: CVE.org (CVE Program・cvelistV5) NVD