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

tmpはNode.js用の一時ファイルおよびディレクトリ作成ライブラリです。バージョン0.2.6以前のtmp npmパッケージには、パス・トラバーサルの脆弱性が存在しました。信頼できないデータがprefix、postfix、またはdirオプションに流れ込むと、意図された一時ディレクトリから脱出することが可能です。これらのパラメータにトラバーサルシーケンス（例：../）やパス区切り文字を埋め込むことで、攻撃者は実行中のプロセスの権限で構成された一時ベースディレクトリ外の攻撃者制御下の場所にファイルを作成させることができます。この脆弱性は、ユーザー制御のデータを適切に入力検証せずにtmpのファイル/ディレクトリ作成関数に渡すアプリケーションに影響を与えます。この脆弱性はバージョン0.2.6で修正されました。

tmpはnode.js用の一時ファイルおよびディレクトリ作成ツールです。バージョン0.2.6では、tmpに追加された_assertPathガードは文字列値に含まれる部分文字列「..」のみを拒否します。しかし、prefix、postfix、またはtemplateが非文字列値（配列、バッファ、またはincludes('..')が偽を返す任意のオブジェクト）として供給された場合、このガードを回避できます。その文字列化は依然として"../"を含みます。この値は_generateTmpName内のArray.prototype.joinやString強制変換、およびpath.join(tmpDir, opts.dir, name)を通過し、最終的にtmpdirを逸脱するパスを生成します。これにより、ホストプロセスの権限で攻撃者制御下の場所にファイルまたはディレクトリを作成される可能性があります。この脆弱性は、信頼できないリクエストデータ（一般的なパターンはJSONボディフィールドやqs解析されたブラケット配列クエリ文字列例：?prefix[]=...）を明示的な型強制なしにtmp.file、tmp.fileSync、tmp.dir、tmp.dirSync、tmp.tmpName、またはtmp.tmpNameSyncに渡す任意のアプリケーションに影響します。バージョン0.2.7でこの脆弱性は修正されました。

Vimはオープンソースのコマンドラインテキストエディタです。バージョン9.2.0561以前では、+python3インタプリタが有効なVimのpython3complete.vimにあるPythonオムニ補完スクリプト（および+pythonインタプリタを使用したビルドの旧来のpythoncomplete.vim）が、現在のバッファ内で見つかったimportおよびfromステートメントをPythonのimport機構を通じて実行します。バッファの作業ディレクトリがsys.pathに存在するため、攻撃者が用意した隣接するPythonパッケージを含む悪意のある.pyファイルを開き、オムニ補完を呼び出すと、そのパッケージのトップレベルコードが編集ユーザーの権限で実行されます。この問題はバージョン9.2.0561で修正されました。

Vimはオープンソースのコマンドラインテキストエディタです。バージョン9.2.0565以前では、src/terminal.c内のupdate_snapshot()関数がスナップショットを取得するときに表示されている端末画面をスクロールバックバッファにコピーしていました。各画面セルごとに、そのchars[]配列を上限なしで走査し、NUL終端子に遭遇した時点で停止します。セルが正当にVTERM_MAX_CHARS_PER_CELL（6）スロットすべてを埋めている場合（基本文字1つと複合マーク5つ）、バンドルされたlibvtermは終端NULなしで配列を返すため、ループは固定の6要素配列の範囲外も読み取り、6文字分しか確保されていないバッファに範囲外の値を追加してしまいます。terminalウィンドウ内で出力がレンダリングされるプログラムは短いバイトシーケンスでこれを引き起こすことができ、Vimスクリプトなしでクラッシュを誘発します。この問題はバージョン9.2.0565で修正されました。

Vimはオープンソースのコマンドラインテキストエディタです。バージョン9.2.0597より前のVimでは、Pythonのオムニ補完が現在のバッファから再構築された関数およびクラス定義をexec()で実行し、補完辞書を構築する過程で動作していました。Pythonは関数のデフォルト値、パラメータアノテーション、クラスの基底式を定義時に評価するため、悪意のあるバッファはオムニ補完中に攻撃者が制御するPython式を実行させる可能性がありました。既存のg:pythoncomplete_allow_import緩和策(GHSA-52mc-rq6p-rc7c)はこの経路をカバーしていません。なぜなら、攻撃者が制御するコードはimport/from文の収集によるものではないからです。この問題はバージョン9.2.0597で修正されています。

OpenClawの2026年5月18日以前のバージョンには、同一ホストのローカル呼び出し元が信頼されたプロキシのIDヘッダーを偽造できるIDヘッダー検証の脆弱性が存在します。プロキシに面したゲートウェイポートへのアクセス権を持つ攻撃者は、偽造されたIDヘッダーを提供することで、オペレーターのIDを引き継ぎ、権限を昇格させる可能性があります。

OpenClawの2026年5月12日以前のバージョンには、PowerShellのencoded-command処理においてアロウリストのバイパス脆弱性が存在します。この脆弱性により、攻撃者はアロウリストパーサーが認識しない省略されたフラグエイリアスを使用してエンコードされたコマンドを実行できます。リモート認証済みのオペレーターは認識されないencoded-commandのエイリアス形式を使用し、任意のPowerShellコンテンツを実行して実行アロウリストのチェックを回避できます。

LiteSpeed cPanelプラグイン2.4.8以前（LiteSpeed WHMプラグイン5.3.2.0以前に配布されているもの）は、CloudLinux/CageFSを実行している共有ホスティングサーバー上で、FTPまたはウェブシェルアクセスを持つユーザーが提供するシンボリックリンクを不適切に扱う脆弱性があります。この脆弱性は2026年5月に野生環境で悪用されました。

vLLMバージョン0.8.0以降では、`VideoMediaIO.load_base64()`メソッドにフレーム数の制限がない処理が存在するため、メモリ不足（OOM）によるサービス拒否（DoS）攻撃の脆弱性があります。`video/jpeg`データURLを処理する際に、このメソッドはカンマでbase64データ文字列を分割して個々のJPEGフレームを抽出しますが、フレーム数の制限を強制しません。攻撃者は、1つのAPIリクエストに数千のカンマ区切りのbase64エンコードされたJPEGフレームを含むデータURLを作成し、この脆弱性を悪用できます。その結果、サーバーは全てのフレームをメモリにデコードし、過剰なメモリ消費によってクラッシュします。この脆弱性はOpenAI互換のチャット補完API経由で利用可能であり、認証を必要としません。

ThingsBoardには次の脆弱性が存在します。 ・プロトタイプ汚染（CWE-1321）- CVE-2026-53676 この脆弱性情報は、情報セキュリティ早期警戒パートナーシップに基づき下記の方がIPAに報告し、JPCERT/CCが開発者との調整を行いました。 報告者：株式会社ラック 今井啓貴 氏

GitLabはGitLab EEにおける問題を修正しました。この問題はバージョン17.1から18.10.8未満、18.11から18.11.5未満、および19.0から19.0.2未満のすべてのバージョンに影響し、特定の条件下で開発者ロールの認証済みユーザーが解析ダッシュボードの入力サニタイズの不備によりターゲットユーザーを代表して任意のクライアントサイドコードを実行できる可能性がありました。

Nettyはプロトコルサーバーおよびクライアントの開発に使用されるネットワークアプリケーションフレームワークです。netty-handlerのバージョン4.1.135.Finalおよび4.2.15.Finalより前のバージョンにおいて、IpSubnetFilterRule.compareTo()のマスキング操作の誤りにより、攻撃者がIPv6のサブネットルールを回避できる可能性があります。有効なグローバルIPアドレスが制限を回避できる可能性があります。本問題はバージョン4.1.135.Finalおよび4.2.15.Finalで修正されています。

Nettyはプロトコルサーバーおよびクライアントの開発のためのネットワークアプリケーションフレームワークです。netty-codec-redisのバージョン4.1.135.Finalおよび4.2.15.Finalより前のバージョンにおいて、攻撃者は深くネストされた配列を含む細工されたRedisペイロードを送信することでDoS（サービス拒否）を引き起こす可能性があります。これにより、サーバーは大量の状態オブジェクトとコレクションを割り当てることを強制され、その結果、メモリが枯渇しOutOfMemoryErrorが発生します。バージョン4.1.135.Finalおよび4.2.15.Finalでこの問題は修正されています。

Nettyはプロトコルサーバーおよびクライアントの開発のためのネットワークアプリケーションフレームワークです。netty-codec-redisのバージョン4.1.135.Finalおよび4.2.15.Finalより前のバージョンでは、攻撃者が複数の接続にまたがって「\r\n」なしの細工されたRedisペイロードを送信することによりDoSを引き起こす可能性があります。これによりサーバーの直接メモリプールが枯渇し（OutOfDirectMemoryError）、正当な接続の処理が妨げられました。バージョン4.1.135.Finalおよび4.2.15.Finalでこの問題は修正されています。

Nettyはプロトコルサーバーおよびクライアントの開発のためのネットワークアプリケーションフレームワークです。バージョン4.2.15.Final以前では、NettyのHTTP/3コーデックである`Http3ConnectionHandler`のデフォルト設定に最大ヘッダーサイズ制限が強制されていませんでした。ピアが明示的に`HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE`を指定しない場合、実装は無制限の制限をデフォルトとしていました。この安全でないデフォルト設定により、悪意のあるクライアントまたはサーバーが膨大な数のヘッダーを送信でき、`OutOfMemoryError`が発生してメモリが枯渇し、サービス拒否を引き起こす可能性があります。バージョン4.2.15.Finalではこの問題を修正するパッチが含まれています。

Nettyはプロトコルサーバーおよびクライアントの開発に使用されるネットワークアプリケーションフレームワークです。netty-codec-haproxyの4.1.135.Finalおよび4.2.15.Finalより前のバージョンでは、PP2_TYPE_SSL TLVをデコードする際に、HAProxyMessage.readNextTLV()が最初に`header.retainedSlice(header.readerIndex(), length)`を呼び出し、その後1バイトのclientフィールドと4バイトのverifyフィールドを読み取ります。攻撃者がTLVの長さを5未満に設定すると、その後のreadByte/readIntでIndexOutOfBoundsExceptionがスローされます。HAProxyMessageDecoderはこの呼び出しに対してHAProxyProtocolExceptionのみをキャッチするため、IOOBEが伝播し、プールされた累積バッファ上のretained sliceが解放されません。この問題はバージョン4.1.135.Finalおよび4.2.15.Finalで修正されています。

Nettyは、プロトコルサーバーおよびクライアントの開発のためのネットワークアプリケーションフレームワークです。NoQuicTokenHandlerは、アプリケーションがトークンハンドラーを設定しない場合に使用されるtokenHandlerです。バージョン4.2.15.Final以前では、そのwriteToken()はfalseを返し（サーバーはRetryを送信しない—許容される）、validateToken()は無条件に`return 0`を返していました。QuicheQuicServerCodec.handlePacket()では、validateToken()からの0以上の返り値が「トークンは有効で、ODCIDがオフセット0から始まる」と解釈され、サーバーはクライアントのアドレスがRetryラウンドトリップによって検証されたかのようにquiche_acceptを呼び出します。RFC 9000 §8.1によると、検証されたアドレスは3倍のアンチアンプリフィケーション送信制限を解除します。したがって、攻撃者が初期パケットに任意の非空トークンバイトを含めて被害者の送信元IPを偽装し送信すると、Nettyサーバーは被害者を検証済みとみなして3倍の制限なしにフルサイズのハンドシェイクフライト（証明書など）を反射します。正しい「トークンなしハンドラー」の意味は、-1（無効）を返して通常の未検証パスとアンプリフィケーション制限を適用することです。この問題はバージョン4.2.15.Finalで修正されました。

Nettyはプロトコルサーバーおよびクライアントの開発のためのネットワークアプリケーションフレームワークです。バージョン4.1.135.Finalおよび4.2.15.Final以前では、SslClientHelloHandler.decode()が24ビットのTLSハンドシェイク長を読み取り、ClientHelloが最初のレコードに収まらない場合に、進んで`ctx.alloc().buffer(handshakeLength)`を割り当てます（161行目）。140行目のガードは`handshakeLength maxClientHelloLength && maxClientHelloLength != 0`であり、一般的に使用されるSniHandler/AbstractSniHandlerのコンストラクタ（SniHandler(Mapping)、SniHandler(AsyncMapping)、AbstractSniHandler()）はmaxClientHelloLength=0およびhandshakeTimeoutMillis=0を渡すため、長さのガードが無効化され、タイムアウトもスケジュールされません。16MiBのリクエストはデフォルトのプールチャンクサイズを超え、直ちに巨大かつ非プール割り当てになります。このバッファはチャネルが閉じるまでハンドラー内に保持され続けます。バージョン4.1.135.Finalおよび4.2.15.Finalでこの問題は修正されています。

Nettyはプロトコルサーバーおよびクライアントの開発のためのネットワークアプリケーションフレームワークです。netty-transport-sctpの4.1.135.Finalおよび4.2.15.Finalより前のバージョンでは、完全でない各SctpMessageフラグメントに対し、ハンドラーは`fragments.put(streamId, Unpooled.wrappedBuffer(frag, byteBuf))`を実行し、以前の蓄積バッファと新しいスライスを毎回新しいCompositeByteBufにラップしていました。N個のフラグメントの後、蓄積バッファはN層のコンポジットチェーンとなり、それぞれが参照とコンポーネント配列を保持します。最終バッファに対するreadableBytes()/getBytes()はNレベルまで再帰します。Nの値、合計バイト数、または攻撃者が開設可能なstreamIdentifierの数に制限はなく（それぞれがマップエントリを獲得します）、`complete`フラグを設定しないピアは小さな1バイトのDATAチャンクからこの構造を無制限に拡大可能です。バージョン4.1.135.Finalおよび4.2.15.Finalでこの問題は修正されています。

Nettyはプロトコルサーバーおよびクライアントの開発のためのネットワークアプリケーションフレームワークです。バージョン4.1.135.Finalおよび4.2.15.Final以前では、RedisArrayAggregatorハンドラーがRESP配列の集約が完了する前にRedisパイプライン接続が閉じられると、プールされた直接メモリバッファを恒久的にリークさせます。このハンドラーは各ハンドラーの状態（`depths`フィールド）に子メッセージを保持しますが、パイプラインが終了するときにそれらを解放するための`channelInactive`、`handlerRemoved`、または`exceptionCaught`メソッドを定義していません。リークしたバッファは`PooledByteBufAllocator`チャンクのスライスであるため、これらのチャンクがJVM全体の直接メモリプールに返却されるのを妨げます。任意のネットワークピアによる繰り返しの接続変動はこの共有プールを単調に消耗し、最終的にプロセス内のすべてのNettyチャネルにおいて割り当てに失敗する原因となります。バージョン4.1.135.Finalおよび4.2.15.Finalでこの問題は修正されています。

Nettyはプロトコルサーバーおよびクライアントの開発に用いられるネットワークアプリケーションフレームワークです。netty-codec-http2のバージョン4.1.135.Finalおよび4.2.15.Final以前では、`DelegatingDecompressorFrameListener`クラスがHTTP/2の圧縮解除を管理していて、各ストリームに対して適切な圧縮解除コーデック（gzip、deflate、zstd）を実行する`EmbeddedChannel`を埋め込み、圧縮解除されたチャンクをラップされたリスナーに転送していました。各圧縮解除チャンクはプールされた`ByteBuf`であり、匿名の`ChannelInboundHandlerAdapter`テールハンドラーに渡されて、これがそれを解放する唯一の所有者となっています。リモートピアがフレームを送信すると、フローコントローラーが例外を投げ、最終的にOOMEによってJVM全体のダウンを引き起こすリソースリークが誘発される可能性があります。この問題はバージョン4.1.135.Finalおよび4.2.15.Finalで修正されています。

Nettyはプロトコルサーバおよびクライアントの開発のためのネットワークアプリケーションフレームワークです。バージョン4.1.135.Finalおよび4.2.15.Final以前では、NettyのHAProxy PROXYプロトコルv2コーデックが、クライアントが深さ2以上のネストされた`PP2_TYPE_SSL` TLV（タイプ・長さ・値レコード）を含む構文的に有効なヘッダーを送信した場合、接続ごとにネイティブメモリまたはヒープメモリをリークします。このリークは正常な解析経路で発生し、例外はスローされず、メッセージは下流に送られ、デコーダーは自動的に削除され、アプリケーションは`HAProxyMessage`を通常どおり解放します。しかし、基盤となる累積バッファ（チャネルによって割り当てられるプールされた可能性のある直接`ByteBuf`）が永久に固定されたままになります。この問題はバージョン4.1.135.Finalおよび4.2.15.Finalで修正されています。

Nettyは、プロトコルサーバーおよびクライアントの開発のためのネットワークアプリケーションフレームワークです。バージョン4.2.15.Final以前のNettyのHTTP/3コーデックにはメモリ枯渇の脆弱性が存在し、無限数のブロックされたストリームを作成することが可能でした。これによりOOM（メモリ不足）エラーが引き起こされる可能性があります。バージョン4.2.15.Finalでこの問題は修正されています。

Nettyはプロトコルサーバーおよびクライアントの開発のためのネットワークアプリケーションフレームワークです。バージョン4.1.135.Finalおよび4.2.15.Final以前では、SimpleTrustManagerFactory.engineGetTrustManagers()および関連の経路で、ユーザー提供の単純なX509TrustManagerをX509ExtendedTrustManagerを継承するX509TrustManagerWrapperでラップしますが、このラッパーは3引数のcheckServerTrusted(chain, authType, SSLEngine)をSSLEngineを破棄して2引数のデリゲートを呼び出す形で実装しています。このオブジェクトがX509ExtendedTrustManagerであるため、SunJSSEの内部AbstractTrustManagerWrapperもNetty自身のOpenSslX509TrustManagerWrapperも再度ラップしてエンドポイント識別を追加しません。その結果、Netty 4.2ではデフォルトでendpointIdentificationAlgorithm="HTTPS"が設定されているにもかかわらず、`SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)`で構築されたクライアントはホスト名検証を全く行いません。この問題はバージョン4.1.135.Finalおよび4.2.15.Finalで修正されました。

Nettyはプロトコルサーバーおよびクライアントの開発のためのネットワークアプリケーションフレームワークです。バージョン4.1.135.Finalおよび4.2.15.Finalより前では、RedisArrayAggregatorはRESP配列の要素数を配列ヘッダーで宣言された値として取得し、その値を初期容量とするArrayListを事前に割り当てていました。この要素数は対応する子メッセージが存在する前にワイヤーから取得されます。悪意のある小さなヘッダーが巨大な初期容量を要求することが可能です。バージョン4.1.135.Finalおよび4.2.15.Finalでこの問題が修正されました。

NuxtはVue.jsのためのオープンソースのウェブ開発フレームワークです。バージョン3.11.0から3.21.7未満および4.0.0から4.4.7未満において、vue-routerとrouteRulesマッチャー間の大文字・小文字の不一致によってルートルールミドルウェアをバイパスできる脆弱性があります。この問題はバージョン3.21.7および4.4.7で修正されています。

株式会社リコーおよびコニカミノルタジャパン株式会社が提供する複数のプリンタドライバーには、権限昇格の脆弱性が存在します。 ・権限昇格（CWE-427）- CVE-2026-50100 この脆弱性情報は、製品利用者への周知を目的に、開発者がIPAに報告し、JPCERT/CCが開発者との調整を行いました。

Google ChromeのV8（バージョン144.0.7559.99未満）において競合状態が存在し、リモート攻撃者が細工されたHTMLページを介して型の混乱を悪用できる可能性がありました。

Microsoft PowerToys の不適切な認可により、認証済みの攻撃者がローカルで権限を昇格させることが可能です。

OpenVMは、高性能でモジュール式のzkVMフレームワークであり、カスタマイズ性と拡張性を重視して構築されています。バージョン1.6.0以前では、openvm-pairingゲストライブラリのtry_honest_pairing_check関数がhttps://eprint.iacr.org/2024/640.pdfの定理3を呼び出していましたが、スケーリング係数sがFp12の適切な部分体に属しているかどうかを確認していませんでした。そのため、ペアリングチェックにおいて誤った結果が許容されてしまっていました。この問題はバージョン1.6.0で修正されました。

Windows Narrator Braille の信頼されていない検索パスにより、権限を持つ攻撃者がローカルで特権を昇格させることが可能となります。

この問題は、不正な操作を防ぐためのチェックを改善することで対処されました。この問題はmacOS Sequoia 15.4で修正されています。アプリがサンドボックスから脱出できる可能性があります。

この問題は改良されたチェックによって対処されました。この問題はmacOS Sequoia 15.4で修正されています。アプリが起動制約の保護を回避し、特権を昇格させて悪意のあるコードを実行できる可能性があります。

追加の制限により権限の問題が対処されました。この問題はmacOS Tahoe 26.1で修正されました。アプリが保護されたユーザーデータにアクセスできる可能性があります。

GPAC MP4Box v2.4のfilein_process関数（in_file.c）におけるスタックバッファオーバーフローにより、攻撃者が細工されたMP4ファイルを提供すると、サービス拒否（DoS）を引き起こす可能性があります。

GPAC MP4Box v2.4のmedia_tools/av_parsers.c内のgf_hevc_read_sps_bs_internal関数で発生するセグメンテーション違反により、攻撃者が細工されたHEVC SPSデータを供給することでサービス拒否（DoS）を引き起こす可能性があります。

GPAC MP4Box v2.4 の gf_odf_vvc_cfg_write_bs 関数 (odf/descriptors.c) における NULL ポインタ逆参照の脆弱性により、攻撃者が細工された MP4 ファイルを供給するとサービス拒否 (DoS) を引き起こす可能性があります。

389 Directory Serverに脆弱性が発見されました。dereference controlプラグインは、BER構造体を使用する前にメモリ割り当ての失敗を確認しないため、認証されていないリモート攻撃者がシステムのメモリが不足している状態のときにLDAPサーバーをクラッシュさせる可能性があります。

Windows版Google Chrome149.0.7827.115以前のCoreにおいてUse after freeの脆弱性が存在し、リモートの攻撃者が細工されたHTMLページを介して任意のコードを実行できる重大な問題があります。

Mac版Google Chromeのバージョン149.0.7827.115以前において、アクセシビリティ機能で信頼されていない入力の検証が不十分でした。そのため、リモートの攻撃者が細工されたHTMLページを利用してレンダラプロセスを侵害し、サンドボックスからの脱出を行う可能性がありました。