脆弱性情報（JVN）検索・一覧

pnpmはパッケージマネージャーです。バージョン10.34.2および11.5.3以前では、一般的なpeer-suffixノーマライザーがgit、URL、tarball、file、およびその他の不透明なロケーターから括弧付きのテキストも除去していました。これにより、あるソース文字列の承認がノーマライズ後に同じ値となる、攻撃者が制御する異なるソースを許可してしまう可能性がありました。この脆弱性はバージョン10.34.2および11.5.3で修正されています。

pnpmはパッケージマネージャーです。バージョン11.3.0から11.5.3までの間、`pnpm stage download`はレジストリで管理されているパッケージ名とバージョンフィールドからローカルのファイル名を派生させていました。細工されたマニフェストにより、選択されたダウンロードディレクトリから脱出し、到達可能な別のファイルを上書きすることが可能でした。今回の修正では両フィールドを検証し、安全なファイル名を一つ導出し、書き込み前に最終的な保存先を確認するようにしました。この脆弱性はバージョン11.5.3で修正されています。

Ollamaのモデル量子化エンジンには認証されていないリモート情報漏洩の脆弱性が存在し、この脆弱性により攻撃者はサーバーのヒープメモリを読み取って持ち出すことが可能になります。これによって機密データが露出し、さらなる侵害やステルス性のある持続的な攻撃が引き起こされる可能性があります。

wolfSSLのAVX2最適化されたML-KEM実装（mlkem_cmp_avx2）は、ML-KEM-1024のデカプセル化における藤崎-岡本再暗号化チェックで、1568バイトの暗号文のうち1536バイトのみを比較します。期待される再暗号化と異なる暗号文が1536から1567バイトの範囲でのみ異なる場合、暗黙の拒否を回避して有効とみなされ、IND-CCA2セキュリティが破られます。静的なML-KEM-1024鍵を使用するデカプセル化オラクルに選択した暗号文を送信し、本物の共有秘密または暗黙の拒否秘密が生成されたかを観察できる攻撃者は、これを平文検査オラクルとして利用し秘密鍵を復元できます。概念実証により、約350の選択暗号文を用いて約98％の成功率で完全なML-KEM-1024秘密鍵を回収できました。この欠陥は決定論的な論理エラーであり、タイミング測定に依存しません。

X25519のx86_64アセンブリ実装は、最終的なモジュラー還元時に最上位ビットをクリアしないため、計算結果が2^255 - 19のフィールド素数で完全に還元されない可能性があります。これにより、フィールド要素が非正準形のままとなり、スカラ乗算から誤った結果を生じさせ、共有秘密が誤って生成される可能性があります。x64およびAVX2削減ルーチンの最終的なキャリープロパゲーション連鎖は最上位ビットにオーバーフローする可能性があり、その後に高位リムがマスクされなかったため、255ビットのフィールド要素が非正準形となりました。

X.509 トラストチェーンバイパスの脆弱性が OpenSSL 互換証明書検証器（wolfSSL_X509_verify_cert()）に存在します。この脆弱性は、--enable-opensslextra (OPENSSL_EXTRA) オプションでビルドされており、かつアプリケーションが呼び出し元が提供する信頼されていない中間証明書を使って X509_verify_cert() を呼び出して証明書を検証する場合にのみ影響します。そのため、それ以外のユーザーには影響がありません。特に、ネイティブの wolfSSL TLS/DTLS 利用には影響がありません。wolfSSL の X509_verify_cert() は呼び出し元が提供する信頼されていない中間証明書を一時的に証明書マネージャーに読み込みますが、信頼ストアのチェック前にそれらを削除しなかったため、信頼されていない中間証明書が自身で検証パスの根拠となりました。攻撃者は信頼されたアンカーに到達しないチェーンを提示しても受け入れさせることができ、攻撃者が制御する証明書を受け入れさせる結果となります。これは TLS とは無関係な証明書検証（例：S/MIME/CMS、コード／ファームウェア署名、JWT/JWS x5c）で発生し、特定の鍵タイプやアルゴリズムに限定されず、単一の信頼されていない中間証明書で十分です。デフォルトの wolfSSL TLS ハンドシェイク (WOLFSSL_VERIFY_PEER) は影響を受けません。影響を受けるのはこの API を使って手動または延期されたピア検証を行う TLS アプリケーションのみで、さらに --enable-sessioncerts が必要です。

OpenSSL互換証明書検証器（wolfSSL_X509_verify_cert()）におけるX.509信頼チェーン回避（パス深度枯渇）の脆弱性です。これは--enable-opensslextraオプションを有効にしてビルドされ、かつアプリケーションがX509_verify_cert()を呼び出し、呼び出し元が信頼されていない中間証明書を供給する場合にのみ影響します。この問題はそのユーザーにとって重大ですが、それ以外のライブラリ利用者には影響しません。ネイティブなwolfSSLのTLS/DTLSの使用には影響がありません。X509_verify_cert()は信頼アンカーに到達するのではなく、最後に検証されたリンクのみに基づいて成功を返していました。つまり、供給された証明書チェーンが検証器の最大パス深度（デフォルト100）を超えると、深度が尽きるまで信頼されていない中間証明書を処理し続け、構成された信頼アンカーに到達しないままチェーンを受け入れてしまい、攻撃者が制御する証明書を受理させることを許してしまいます。デフォルトのTLSハンドシェイク（WOLFSSL_VERIFY_PEER）には影響がなく、このAPIを通じて手動または遅延検証を行うアプリケーションのみが影響を受けます。

SM2/SM3証明書の署名検証中にヒープの境界外読み取りが発生します。SM3を用いたSM2署名を持つ証明書を解析する際に、Subject Key Identifierの計算で公開鍵が少なくとも65バイトであることを確認せずに、公開鍵の後続65バイトを読み取ります。公開鍵が65バイト未満の場合、ヒープの境界外読み取りが発生し、潜在的にクラッシュ（サービス拒否）を引き起こす可能性があります。境界外書き込みは発生しません。この問題はSM2サポートを有効（--enable-sm2または--enable-all）にしてビルドしたものにのみ影響します。

KTLSの受信パスは、受信データを保持するmbufが匿名であり、変更しても安全であると仮定して各レコードをその場で復号します。この仮定は、sendfile(2)によってソケットに配置されたデータには当てはまりません。sendfile(2)は、非匿名のM_EXTPGページやEXT_SFBUF mbufを介してファイルバックのメモリを直接参照することがあるためです。送信側でKTLSを有効にせず、ループバック接続上でそのようなデータが送信されると、ファイルバックのmbufは変更されずに受信者の復号パスに到達します。レコードをその場で復号すると、データのプライベートコピーではなく元となるファイルのページキャッシュが上書きされます。権限のないローカルユーザーは、読み取り可能なファイルを任意のデータで上書きでき、KTLS受信を有効にしたループバック接続でそのファイルを送信することでこれを実現します。この書き込みはページキャッシュを直接変更するため、schgなどのファイルフラグをバイパスしてディスクに書き戻されます。セットUIDバイナリやその他の信頼されたファイルを上書きすることで、ローカルユーザーは権限を昇格させ、影響を受けたシステムの完全な制御権を得る可能性があります。

Renesas TSIP TLS 1.3のトランスクリプトバッファにおける境界外書き込みの脆弱性です。tsip_StoreMessage()関数内で固定メッセージバッグ（MSGBAG_SIZE）の容量チェックがエラーコードを設定しますが、関数をリターンしません。そのため、TLS 1.3ハンドシェイクの蓄積トランスクリプトがMSGBAG_SIZE（8KB）を超えた場合に、XMEMCPYによってバッファの末尾を越えて書き込みが生じます。この書き込みは隣接するヒープ領域を破損し、リモートからのサービス拒否クラッシュを引き起こす可能性があります。バッグは通常のハンドシェイクを保持するサイズに設定されているため、この問題は異常に大きな有効な証明書チェーンや、チェーンを厳密に検証しないクライアントに対し、悪意のあるまたは中間者攻撃者が送信する過大なハンドシェイクメッセージによってのみ発生し得ます。この問題はRenesas MCUs上でTSIPハードウェアが有効化されたRenesas TSIP TLSポート（WOLFSSL_RENESAS_TSIP_TLS）をTLS 1.3クライアントとして使用しているビルドにのみ影響し、これらのビルドでは重大（High）と評価されています。その他の設定には影響がありません。

交渉されていない生の公開鍵（RFC 7250）がX.509証明書の代わりに受け入れられ、チェーン検証をバイパスしてしまう問題があります。生の公開鍵にはチェーンが存在しないため、ParseCertRelative()は信頼検証を行わずにそれを受け入れます。そのため、その公開鍵は実際に当該ピアとRPKが交渉された場合にのみ受け入れる必要があります。このチェックでは、交渉されていない場合に期待されるタイプをデフォルトでX.509（RFC 7250/8446に従う）に設定し、クライアント側で受け取ったサーバ証明書のタイプとサーバ側で選択したクライアント証明書のタイプを比較します。交渉されていない生の公開鍵を含む不一致の場合はUNSUPPORTED_CERTIFICATEで拒否します。この対応はRaw Public Keyサポート（HAVE_RPK）が有効なビルドにのみ影響を与え、スタンドアロンビルドではデフォルトで無効ですが、--enable-allで含まれます。

wolfSSL_PKCS7_verify() は、署名者を含まない退化した（証明書のみの）PKCS#7オブジェクトに対して成功を返していました。そのようなオブジェクトは signerInfos が空であるため、基盤となる署名付きデータの検証がコンテンツを認証せずに成功してしまいます。互換レイヤの verify パスは、実際に署名者の署名が検証されていない場合にオブジェクトを拒否するようになりました。これにより、有効な署名を含まない PKCS#7 がもはや検証済みと報告されなくなりました。この動作は、署名者の証明書チェーン検証のみを抑制し、署名の存在要件を放棄することを意図していなかった PKCS7_NOVERIFY フラグに関係なく適用されます。影響を受けるのは、退化した可能性のある PKCS#7 バンドルに対して PKCS7_verify() 互換 API を呼び出す OpenSSL 互換ビルドのみです。

非常に大きな累積単一メッセージサイズ（64 GiB）のAES-GCM暗号化/復号がストリーミングAPIによって適切に拒否されず、カウンタのラップアラウンドやキーストリームの再利用を引き起こし、それによって平文の復元が可能になっていました。

NSDがゾーンのセカンダリとして設定されている場合、そのゾーンのプライマリが、rdataサイズが65512の特別に細工されたSVCBリソースレコードを含むDNSメッセージを使用したAXFRによってNSDをクラッシュさせる可能性があります。このSVCBリソースレコードにより、リソースレコードのために必要なスペースを割り当てる際に使用される(uint16_t)変数がオーバーフローし（合計サイズが65535を超えるため）、ヒープオーバーフローを引き起こします。攻撃者は最大65509バイトの制御可能な（RCEクラスの）ヒープ上書きを実行できます。

バージョン4.13.0以降のNSDには、TLS接続のエラーをログに記録する際にヒープのuse-after-freeバグがあり、サーバープロセスがクラッシュします。この問題は、DoT接続でDNSクエリを送信し、応答を読み取らずに接続を閉じることで簡単に引き起こせます。

NSDバージョン4.14.0には、特別に細工されたAPL RRで、アドレスファミリーに許可された長さを超えるadflengthが存在し、ゾーンがディスクに書き込まれる際に最大111バイトの攻撃者が制御するデータでスタックを上書きできるバグがあります。

provide-xfr が tls-auth-name と共に指定されている場合、転送を要求する第2のクライアントはその名前のクライアント証明書を提供しなければなりません。ただし、リクエストが通常の tls-port（tls-auth-port ではない）上の TLS 経由、または通常のポート上の TCP 経由で届く場合、provide-xfr ルールの他の条件が一致していればクライアント証明書は不要です。

Doclingは、多様なフォーマットを解析し、生成AIエコシステムとの統合を提供することで、ドキュメント処理を簡素化します。FInのバージョン2.82.0以上、2.91.0未満において、HTMLバックエンドが明示的にレンダリング用に設定されていた場合（レンダリングオプションはデフォルトで無効です）、Playwrightを使用したレンダリング機能により、信頼されていないHTMLドキュメントの処理時にJavaScriptの実行や無制限のネットワークアクセスが許可される可能性がありました。攻撃者は悪意のあるHTMLを作成し、レンダリングコンテキスト内で任意のJavaScriptを実行したり、内部サービスへの不正なネットワークリクエストを行ったりすることで、SSRF攻撃やデータ流出、さらにレンダリング環境でのリモートコード実行を引き起こす可能性があります。この脆弱性はバージョン2.91.0で修正されています。

Doclingは多様なフォーマットを解析し、生成AIエコシステムとの統合を提供することで文書処理を簡素化します。2.91.0以前のバージョンでは、EasyOCRのモデルダウンロード機能がZIPアーカイブのメンバーパスを検証せずに展開しており、Zip Slip攻撃を可能にしていました。攻撃者がモデルダウンロード元をサプライチェーン攻撃、DNSスプーフィング、または中間者攻撃で乗っ取った場合、プロセスが書き込み可能な任意の場所に任意のファイルを書き込み、Pythonファイルやシステムバイナリを上書きしてリモートコード実行を達成したり、起動スクリプトやSSHキーを改ざんして永続的なバックドアを設置し、さらにはデータを破損させたりシステムを侵害したりする可能性があります。この脆弱性は2.91.0で修正されました。

Doclingは多様なフォーマットを解析し、生成AIエコシステムとの統合を提供することでドキュメント処理を簡素化します。バージョン2.13.0から2.74.0までの間、USPTO特許XMLパーサーはXML外部エンティティ（XXE）攻撃に対する保護がないまま標準のxml.sax.parseString()を使用していました。攻撃者は任意のサーバーのファイルシステムのファイルを読み取ったり、サーバーサイドリクエスト偽造（SSRF）攻撃を実行したり、エンティティ展開によるサービス拒否（Billion Laughs攻撃）を引き起こす悪意のあるUSPTO特許XMLファイルを作成する可能性があります。この脆弱性は3つのUSPTO特許フォーマットパーサー（ICE（v4.x）、Grant v2.5、およびApplication v1.x）に影響を与えていました。なお、この脆弱性はバージョン2.74.0で修正されました。

DokkuはDockerを利用したPaaSです。バージョン0.38.2より前のgit:from-archiveおよびcerts:addコマンドでは、ユーザーが提供したtar/zipアーカイブを一時ディレクトリに展開する際に、メンバーパスのサニタイズやシンボリックリンクのトラバーサル防止が行われていませんでした。GNU tarは展開時にシンボリックリンクを作成し、その後のエントリでそれを辿るため、攻撃者はdokkuユーザーが書き込み可能な任意の場所にファイルを書き込むことができました。これにより、~/.ssh/authorized_keysを上書きして無制限のシェルアクセスを得ることが可能でした。この脆弱性は0.38.2で修正されています。

Dokku は Docker を利用した PaaS です。バージョン 0.38.2 より前の openresty-vhosts プラグインは、アプリの openresty/http-includes/ Git リポジトリディレクトリからファイルをホストにコピーし、その後ファイル名をエスケープせずに単一引用符で囲まれたシェル文字列に挿入します。その文字列は後で eval によって解析されます。ファイル名に単一引用符が含まれていると引用符が壊れ、コマンド置換が可能となり、次回のアプリのデプロイ時に dokku ユーザーとしてホスト上で任意のコマンドが実行されてしまいます。この脆弱性はバージョン 0.38.2 で修正されています。

concurrent-rubyはRubyのための最新の並行処理ツールです。バージョン1.3.7より前では、Concurrent::AtomicReference#updateは現在の値がFloat::NANの場合に永久にビジーリトライループに入る可能性がありました。この問題は、compare_and_set(old_value, new_value)が成功するまでリトライするAtomicReference#update、元の値と比較してから基礎となるアトミックスワップを試みるNumericのcompare_and_set、およびFloat::NAN == Float::NANが常にfalseとなるRubyのNaNのセマンティクスの相互作用によって引き起こされます。その結果、一度AtomicReferenceがFloat::NANを含むと、#updateを呼び出すたびに呼び出し元のブロックが繰り返し評価されて永遠に戻りません。外部から取得した数値をAtomicReferenceに保存するサービスでは、これによりCPUの枯渇やリクエストやジョブが永久にハングする可能性があります。この脆弱性はバージョン1.3.7で修正されました。