snappy-javaの脆弱性CVE-2026-93451、型付き配列への展開でヒープ破壊のおそれ。Kafka・Sparkの下で古い版が残る場合の確かめ方

提供元のアドバイザリによると、Snappy.uncompressCharArray・uncompressShortArray・uncompressIntArray・uncompressLongArray・uncompressFloatArray・uncompressDoubleArrayは、圧縮データに書かれた展開後の大きさ（バイト数）を要素の大きさで割って配列を用意していました。一方、ネイティブのコードはバイト数をそのまま書き込みます。展開後の大きさが要素の大きさの倍数でないと、配列の末尾を最大7バイト越えて書き込み、Javaのヒープを壊します。[1]

深刻度は、提供元の評価でCVSS 3.1の7.5（可用性への影響が高）です。CVEを採番したVulnCheckは、CVSS 4.0で6.9、CVSS 3.1で6.5と評価し、書き込む内容を攻撃者が制御できるとしています。NVDは11月1日時点で独自の評価をしていません。[1][3]

報告のissue（#729）は日本時間の9月14日に公開され、VulnCheckのCVEの記録は9月18日に公開されました。提供元のアドバイザリの公表は10月4日、GitHub Advisory Databaseへの収録は10月28日です。[1][2][3][4]

この件の対象は、外部から受け取ったデータ、または外部の影響を受けるデータを、上の6つのメソッドで展開している場合です。Snappy.uncompress(byte[])やSnappyInputStreamなど、他の展開の方法はこの件の対象として書かれていません。[1]

ただし、同じ1.1.10.9では、Snappy.uncompress(ByteBuffer, ByteBuffer)の範囲外の書き込み（CVE-2026-90559）や、圧縮データで宣言された大きさのまま最大2GBのメモリを確保してしまう問題（GHSA-q233-g92q-qxp6、SnappyInputStreamなども対象）も直っています。型付き配列のメソッドを使っていなくても、上げる理由は残ります。[5][6]

2026年11月1日時点で、米国のCISAが公開している「悪用が確認された脆弱性の一覧（KEV）」には載っていません。

今後30日以内に悪用される確率の推定値（EPSS）は0.3%です（2026-11-01時点）。見込みは高くない部類ですが、推定値で、悪用されないことを保証するものではありません。

報告のissue（#729）には、展開後の大きさをずらした圧縮データで書き込みを再現するコード（PoC）が公開されています。当社はPoCを検証していません。CISAのコーディネーターがCVEの記録に付けた評価（SSVC）は、9月21日時点で悪用「なし」です。[3][4]

版ごとの状態は次のとおりです（11月1日時点、Maven Centralの最新は1.1.10.12）。[1][7][8][9][13][14]

1.1.10.9に残る2件は、SnappyFramedInputStreamが確保に失敗したときにバッファを二重に返し、別のストリームと同じ配列を共有してしまうおそれ（GHSA-c73m-r934-8qvg）と、SnappyInputStreamの再帰による異常終了と大きなメモリの確保（GHSA-6gp7-6wmv-gxqw）で、いずれも1.1.10.10で直りました。1.1.10.9は日本時間の10月3日、1.1.10.10は10月4日にMaven Centralへ公開されています。Hadoop互換の圧縮の不具合は、よくある質問で説明します。[7][8][9]

1. Mavenでは、snappy-javaの版と、どのライブラリを通じて入っているかを確かめます。

   ターミナル

   mvn dependency:tree -Dincludes=org.xerial.snappy:snappy-java

2. Gradleでは、実行時に使われる版と、そう決まった理由を確かめます。

   ターミナル

   ./gradlew dependencyInsight --dependency org.xerial.snappy:snappy-java --configuration runtimeClasspath

3. 自分のコードで、型付き配列のメソッドを使っている箇所を探します。

   ターミナル

   grep -rn -E 'uncompress(Char|Short|Int|Long|Float|Double)Array' --include='*.java' --include='*.kt' --include='*.scala' .

4. Mavenでは、dependencyManagementで版を指定すると、間接的に入るsnappy-javaもその版になります。

   pom.xml

   <dependencyManagement>
     <dependencies>
       <dependency>
         <groupId>org.xerial.snappy</groupId>
         <artifactId>snappy-java</artifactId>
         <version>1.1.10.12</version>
       </dependency>
     </dependencies>
   </dependencyManagement>

5. Gradleでは、依存の制約（constraints）で版を指定します。Gradleは、制約と他のライブラリの指定のうち高い版を選びます。

   build.gradle.kts

   dependencies {
       constraints {
           implementation("org.xerial.snappy:snappy-java:1.1.10.12")
       }
   }

6. もう一度版を確かめ、アプリやコンテナのイメージを作り直します。Kafka・Spark・Hadoopを使う場合は、圧縮と展開の動作もテストで確かめます。

   ターミナル

   mvn dependency:tree -Dincludes=org.xerial.snappy:snappy-java

提供元のアドバイザリは回避策として、これらのメソッドを呼ぶ前に、Snappy.uncompressedLength(input)が要素の大きさの倍数かを確かめることを示しています。要素の大きさは、char・shortが2、int・floatが4、long・doubleが8バイトです。[1]

この回避策で防げるのは今回の件だけで、同じ版で直った他の件は防げません（当社の整理）。上のライブラリの都合で上げられない場合も、次の節の方法でsnappy-javaの版だけを指定できることがあります。

snappy-javaは、圧縮を扱うJavaのライブラリの依存として入ります。Maven Centralに登録された主なライブラリの指定は、11月1日時点で次のとおりで、いずれも対象の版です。[10][11][12]

Kafkaは開発中のリポジトリで1.1.10.11に上げていますが、公開済みの4.4.0には入っていません。Mavenは、依存の木で近い指定を優先して版を決めます。自分のpom.xmlでsnappy-javaの版を指定しない限り、これらのライブラリの指定が使われます。[10][15][16]

脆弱性の公表・更新一覧で、Java / JVMの関連情報を調べることもできます。