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

Linuxカーネルにおけるscsi: pm8001ドライバのpm8001_queue_command()関数にUse-After-Freeの脆弱性が存在していました。コミットe29c47fe8946によるリファクタリングで、phyのダウンやデバイス消失時に-ENODEVを返す処理が追加されましたが、この処理によりSASタスクの状態を正しく管理できず、二重解放が発生する恐れがありました。具体的には、pm8001_queue_command()がタスクを処理済みと示すために0を返すべきところを-ENODEVを返したため、libsasの上位層がタスクを重複して解放してしまう問題でした。この問題は、pm8001_queue_command()が状況に応じて正しく0を返すように修正され、解決しました。

Windows Admin Centerの認可欠如により、認可された攻撃者がネットワーク経由で権限を昇格させることが可能となります。

com_mediaファイルAPIエンドポイントの検索パラメータの不適切な検証により、パストラバーサルの脆弱性が発生します。

free5GCは5Gコアネットワークのオープンソース実装です。バージョン4.2.2以前では、PCFのNpcf_SMPolicyControlに認証ミドルウェアが存在しないため、認証されていない状態でSMポリシーハンドラにアクセスでき、加入者のSUPIが漏洩する可能性がありました。NewServer()内でsmPolicyGroupルートグループが作成され、ルートはルーター認証ミドルウェアを付与せずに適用されます。一方で、Npcf_PolicyAuthorizationなど他のPCFサービスグループは、ルート登録前にRouterAuthorizationCheckを付与していました。このミドルウェアの欠如により、有効なOAuthトークンが提供されていなくても、/npcf-smpolicycontrol/v1/sm-policies、/npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}、/npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}/update、および/npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}/deleteエンドポイントへのリクエストがビジネスロジックに到達してしまっていました。この脆弱性はバージョン4.2.2で修正されました。

free5GCは5Gコアネットワークのオープンソース実装です。バージョン4.2.2より前のfree5GCのUDMコンポーネントは、nudm-sdm（加入者データ管理）サービスの6つのGETハンドラにおいてsupiパスパラメータの検証に失敗します。認証されていない攻撃者はSUPIパラメータに制御文字を注入でき、その結果UDMが不正なリクエストをUDRに転送し、内部インフラの詳細を露呈する500 Internal Server Errorレスポンスを返してしまいます。この脆弱性はバージョン4.2.2で修正されました。

free5GCは5Gコアネットワークのオープンソース実装です。バージョン4.2.2以前では、free5GCのPCFのPOST /npcf-smpolicycontrol/v1/sm-policiesハンドラー（HandleCreateSmPolicyRequest）が、ダウンストリームのOpenAPIコンシューマ呼び出し（UDRルックアップ）が404 Not Foundを返し、かつコンシューマラッパーがerr != nilかつレスポンス構造体がnilを返す場合にnilポインタ参照でパニックを起こします。ハンドラーはOpenAPIエラーをログに記録し、リターンせずに実行を続行します。その後の行でnilのレスポンス構造体をデリファレンスしてパニックになります。Ginのリカバリ機能はこのパニックをHTTP 500エラーに変換するため、ダウンストリームルックアップが失敗すると単一の攻撃者によるPOSTはクリーンな4xxではなく500エラーを返します。PCFプロセスは実行を継続します。この問題を引き起こすトリガーは、ダウンストリームのUDRルックアップを失敗させる入力を含む単一のPOST（例：未知のDNN）です。バージョン4.2.1では、PCFのNpcf_SMPolicyControlルートグループがインバウンド認証ミドルウェアなしでマウントされているため、このエンドポイントにAuthorizationヘッダーなしでアクセス可能でした。この脆弱性はバージョン4.2.2で修正されています。

free5GCは5Gコアネットワークのオープンソース実装です。バージョン4.2.2以前のfree5GCのNEFは、保存されたPFDサブスクリプションのnotifyUriに到達できない場合にプロセス全体を終了します。PfdChangeNotifier.FlushNotifications()内で、ノーティファイアはNnefPFDmanagementNotify(...)を呼び出し、配信エラーが発生するとlogger.PFDManageLog.Fatal(err)を呼び出します。これはGo言語におけるos.Exit(1)と同等の動作です。攻撃者が選択したnotifyUriでPFDサブスクリプションを作成し、PFD変更をトリガーすると、非同期配信の試みでNEFを決定的に停止させることが可能です。プロセスはステータス1で終了し、再起動するまでNEFのSBIインターフェース全体が停止します。この脆弱性はバージョン4.2.2で修正されました。

free5GCは5Gコアネットワークのオープンソース実装です。バージョン4.2.2以前のfree5GCのNEFは、nnef-callbackルートグループを着信OAuth2/ベアラートークン認証なしでマウントしていました。偽造または任意のベアラートークン（例：Authorization: Bearer not-a-real-token）があれば、SMF-callbackハンドラーに到達可能であり、コールバックの内容は認証境界で拒否されることなく解析されNEFの業務ロジックに送られます。他のNEF SBIに関する問題と同じ根本原因は、ルートグループが着信認証ミドルウェアなしでマウントされていることです。NEFはコールバック処理前にプロデューサNFの識別を認証しないため、攻撃者が有効なNotifIdを推測または取得できれば、この認証境界の欠如により偽造コールバックが実際の加入者状態に影響を与えます。ルートグループは実行時のServiceListに宣言されていなくても（nnef-pfdmanagementとnnef-oamのみがリストされている場合でも）、アクセスが可能です。この脆弱性はバージョン4.2.2で修正されています。

free5GCはオープンソースの5Gコアネットワーク実装です。バージョン4.2.2以前のfree5GCのSMFは、UPI管理ルートグループをインバウンドOAuth2ミドルウェアなしでマウントしていました。POST /upi/v1/upNodesLinksのcreate-or-updateハンドラーは攻撃者が制御可能なJSONを受け取り、直接UpNodesFromConfiguration()に渡します。この関数は複数の検証失敗時にlogger.InitLog.Fatalf(...)を呼び出します。確認された経路の1つはUE-IPプールの重複チェックであり、認証されていない単一のPOSTリクエストで既存のUPFとプールが重複する新しいUPFが追加されると、SMF全体のプロセスが終了（docker psでExited (1)と表示されます）し、ゴルーチンのみが終了するわけではありません。この脆弱性はバージョン4.2.2で修正されました。

free5GCは5Gコアネットワークのオープンソース実装です。バージョン4.2.2以前では、free5GCのNEF PATCH /3gpp-pfd-management/v1/{afId}/transactions/{transId}/applications/{appId}ハンドラにおいて、上流のUDR呼び出しが失敗し、かつコンシューマラッパーがerr != nilかつnilの*ProblemDetailsを返すと、nilポインタ参照によってパニックが発生します。このハンドラのerrPfdData != nilの分岐は独自のproblemDetailsErrを正しく構築しますが、その直後にproblemDetails.Cause（この分岐ではnilのOTHER値）を読み取るため、パニックが発生します。GinのリカバリはこのパニックをHTTP 500に変換するため、UDRアクセスが失敗している場合、このエンドポイントに対する単一のPATCHは意図した制御されたエラー応答ではなく500を返します。この脆弱性はバージョン4.2.2で修正されました。

free5GCは5Gコアネットワークのオープンソース実装です。バージョン4.2.2以前のfree5GCのNRFルートSBIエンドポイントPOST /oauth2/tokenに、パーサーレベルでの型混同の脆弱性が存在します。NFs/nrf/internal/sbi/api_accesstoken.go内のハンドラはmodels.NrfAccessTokenAccessTokenReqに対してリフレクション処理を行い、プレーンな文字列とNrfNfManagementNfTypeフィールドのみを特別に処理し、その他のすべてのフィールドを単一のmodels.PlmnIdとして扱います。解析された*models.PlmnIdはreflect.Value.Set()を使用してフォームボディ内の攻撃者が指定した任意のフィールド名に割り当てられますが、宛先フィールドの実際の型と互換性がない場合（スライスや異なる構造体、プリミティブなど）、パニックが発生します。Ginのリカバリ機能により、それぞれのパニックはHTTP 500に変換されますが、このエンドポイントは単一の未認証フォームエンコードリクエストでリモートからパニックを引き起こすことができ、繰り返しトリガー可能です。この脆弱性はバージョン4.2.2で修正されました。

free5GCは5Gコアネットワークのオープンソース実装です。バージョン4.2.2以前では、free5GCのSMFがインバウンドOAuth2ミドルウェアを使用せずにUPI管理ルートグループをマウントしていました。その上で、DELETE /upi/v1/upNodesLinks/{upNodeRef}ハンドラーは、型ガードされた非同期リリース後にもかかわらず、UPFオブジェクトがない状態で構築されたAN型ノードに対しても無条件にupNode.UPFを逆参照していました。その結果、認証されていないDELETE /upi/v1/upNodesLinks/gNB1リクエストがnilポインタパニックを引き起こしてハンドラーをクラッシュさせると同時に、パニック発生前にインメモリのユーザープレーントポロジーを変更します（UpNodeDelete(upNodeRef)行が最初に実行されます）。これは認証されていない状態変化を伴うパニックDoS脆弱性であり、オフパスのネットワーク攻撃者が任意のANエントリを名前指定することでトリガーできます。この脆弱性はバージョン4.2.2で修正されました。

Nautobotはネットワークの真実の情報源であり、ネットワーク自動化プラットフォームです。バージョン2.4.33および3.1.2より前のバージョンでは、GitRepositoryレコードの追加・変更アクセス権を持つユーザーがREST APIを使用して、ユーザーが編集可能でないはずのcurrent_headフィールドを直接設定できました。この操作により、Nautobotの該当リポジトリのローカルクローンが指定されたブランチの最新コミット以外のコミットをチェックアウトしてしまい（誤解を招く状態となり）、またはcurrent_headが存在しないコミットハッシュや不正な値を指してしまうため、手動で修正されるまでリポジトリを使用できなくなる可能性がありました。この脆弱性はバージョン2.4.33および3.1.2で修正されています。

バイトから整数への誤ったキャストが原因で、巧妙に作成された入力に対してAES-GCMパケットデコーダがサーバー側でパニックを引き起こす可能性がありました。

benoitc hackneyにおけるCRLFシーケンスの不適切な無害化（「CRLFインジェクション」）の脆弱性により、HTTPリクエスト/レスポンス分割が可能になります。src/hackney_ws.erlのWebSocketアップグレードコードは、callerが渡すoptsマップからhost、path、headers（ExtraHeaders）、protocolsオプションをinit/1内で内部の#ws_data{}レコードにコピーし、その後do_handshake/1でバイナリ連結によりそれらを生のHTTP/1.1アップグレードリクエストにそのまま挿入します。これら4か所のインジェクション箇所のいずれでもCRLFやNULの除去は行われません。攻撃者は、例えば信頼できない入力からのURLの一部やヘッダー値をhackney_ws:start_link/1にフォワードすることで、これらのオプションのいずれかを制御可能であれば、任意のHTTPヘッダーを送信先WebSocketアップグレードリクエストに注入できます。これにより、ヘッダーインジェクションや上流サーバーに対する資格情報のなりすまし、ログやキャッシュの汚染、中間プロキシを介したリクエストスマグリングを引き起こす可能性があります。この問題はhackneyのバージョン2.0.0から4.0.1未満に影響があります。

benoitc hackneyにおけるCRLFシーケンスの不適切な無害化の脆弱性により、HTTPリクエスト分割が可能となります。hackneyは、HTTP/1.1リクエストターゲットを構築する前にURLクエリコンポーネント内のキャリッジリターン（\r）やラインフィード（\n）文字をパーセントエンコードしません。RFC 3986第3.4節で定義された文法外の文字はパーセントエンコードが必要ですが、hackney_url:make_url/3はクエリのバイナリを検証やエスケープなしに直接渡します。攻撃者がhackneyに渡されるURLの全部または一部を制御できる場合、クエリ文字列に生のCRLFシーケンスを注入でき、それがリクエストターゲットのHTTP改行として送信されます。このため、任意のHTTPヘッダーの注入やHTTPリクエストの分割が可能になります。この問題はhackneyの0以上4.0.1未満のバージョンに影響を及ぼします。

状態チェックが不十分なため、2FAチェックを回避できる脆弱性が存在します。

不十分な状態チェックにより、2要素認証（2FA）チェックを回避できる脆弱性が発生します。

InputFilter::getInstance() メソッドは、インスタンスキャッシュキーからセキュリティに敏感なパラメータを省略していました。これは問題です。

Jenkins Email Extension Plugin 1933.v45cec755423fおよびそれ以前のバージョンでは、メールコンテンツに`data-inline`属性を設定することで画像を`base64`としてインライン化できます。しかし、インライン化可能な画像のURLに制限がなく、攻撃者がメールコンテンツを制御できる場合には、`file:` URLを画像に指定してJenkinsコントローラーのファイルシステムから任意のファイルを読み取ることが可能です。

Jenkins Credentials Binding Plugin 720.v3f6decef43ea_の以前のバージョンには、ファイルおよびzipファイルの資格情報のファイル名を適切にサニタイズしない脆弱性があります。この脆弱性により、ジョブに資格情報を提供できる攻撃者がノードのファイルシステム上の任意の場所にファイルを書き込むことが可能になります。さらに、Jenkinsが組み込みノードで実行されるジョブに使用されるファイルまたはzipファイルの資格情報を低権限ユーザーが構成できるように設定されている場合、リモートコード実行が発生する可能性があります。

Google Chrome 146.0.7680.178 より前のバージョンの GPU におけるヒープバッファオーバーフローの脆弱性により、リモートの攻撃者が細工された HTML ページを介して任意のコードを実行する可能性があります。

MphRxのMinerva V3.6.0における認可の脆弱性で、特に'/minerva/moUser/update'エンドポイントにおいて、ユーザー修正権限を持つ認証済みユーザーが'identifier'フィールドを改ざんしたHTTPリクエストを送信することで権限を昇格できる可能性があります。この脆弱性を悪用すると、認証済みユーザーが管理者権限を取得できます。グラフィカルユーザーインターフェースを通じた権限昇格はできません。

IBM Db2 11.5.0から11.5.9、および12.1.0から12.1.4において、小さなステートメントヒープを使用した特別に細工されたクエリを実行すると、サービス拒否の脆弱性が発生します。

IBM Db2 11.5.0から11.5.9および12.1.0から12.1.4のバージョンには、MDCテーブルを使用する特定のクエリを実行した際にメモリ不足が発生する脆弱性があります。

IBM Db2 12.1.0 から 12.1.4 までのバージョンには、特殊なクエリを使用してリモートオブジェクトストレージのパスにアップロードする際に認可をバイパスできる脆弱性があります。

Tenda F456 1.0.0.5に脆弱性が発見されました。この脆弱性は、コンポーネントhttpdのファイル/goform/WrlclientSet内のfromWrlclientSet関数に影響を与えます。この脆弱性により、操作者の操作がバッファオーバーフローを引き起こす可能性があります。リモートからの攻撃が可能です。この脆弱性のエクスプロイトは公開されており、悪用される恐れがあります。

TaniumはConnectにおける不正なコード実行の脆弱性を修正しました。

Linuxカーネルにおいて、net:threaded busypollで発生するrcu_tasksのスタールの脆弱性が報告されました。この問題は、threaded busypollを有効にした場合にbpftrace起動時にハングアップが発生し、dmesgにrcu_tasks_wait_gpが長時間経過したことを示すメッセージが表示される現象です。この問題の原因は、threaded busypollのメインループがnapi_threaded_pollであり、通常のnapi_threaded_poll_loopとは異なり、rcu_softirq_qs_periodicが適切に状態を報告できないことにあります。この問題に対し、パッチではthreaded busypoll時にlast_qsを外側のnapi_threaded_poll内で保持し、napi_threaded_poll_loopが呼ばれるたびにlast_qsがリセットされるのを防ぐことで解決しています。

Linuxカーネルにおいて、stagingのrtl8723bsドライバのrtw_restruct_wmm_ie関数に潜在的な境界外読み取りの脆弱性が修正されました。この脆弱性は、配列アクセス時のインデックスチェックの順序が不適切であったことに起因しています。条件文の順序を修正し、インデックスが配列長内であることを先に確認することで、この問題を解決しました。

Linuxカーネルにおいて、mm/damon/coreのdamos_walk()関数で非アクティブなコンテキストのwalk_controlをクリアしない問題が修正されました。この関数はコンテキストが実行中かどうかを確認する前に呼び出し元が提供したwalk_controlを設定しますが、もしコンテキストが非アクティブの場合、walk_controlをクリアせずにエラーを返します。このため、呼び出し元にスタック上の構造体へのダングリングポインタが残り、将来的にUse-after-freeや恒久的なエラーの原因となる可能性があります。しかし、実際の影響は限定的であり、DAMONが動作していない場合にのみ症状が発生します。本問題は、エラーを返す前にwalk_controlをクリアすることで修正されました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。nsfsのハンドルのオープンに対する権限チェックが強化されました。特権サービスであっても、他の特権サービスの名前空間を見ることは必ずしも許されるべきではなく、互いに情報を漏らさないようにすべきです。nstreeが適用されるまで、このポリシーは集中管理され、may_see_all_namespaces()ヘルパー関数を使用して実装されます。

Linuxカーネルにおいて、以下の脆弱性が修正されました。rust_binderに関して、offsets配列に書き込まれた値の読み取りを回避します。トランザクションを送信する際、そのoffsets配列はまず対象プロセスのvmaにコピーされ、そこから値が読み取られます。通常、vmaは読み取り専用マッピングであるため、対象プロセスが値を変更することはできません。しかし、もし対象プロセスが自身のvmaを書き込み可能にしてしまった場合、読み戻される前にoffsetを変更でき、カーネルが送信者の意図を誤解する可能性があります。特定の形状のペイロードを送信した場合、最悪の場合、受信者が送信者に対して権限昇格を行える可能性があります。本来、自身のプロセスの読み取り専用vmaを変更する能力を得ることは悪用できないはずですが、別のBinderのバグがなければ悪用は不可能です。そのため、このTOCTOUの読み取りを削除しました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。rust_binderは、vmaを使用する前に所有権を確認します。Rust Binderは、不足しているページをインストール（または削除）する際に、アドレスでmm内のvmaを検索し、vm_insert_page（またはzap_page_range_single）を呼び出します。しかし、vmaが閉じられて同じアドレスに別のvmaが置き換わった場合、Rust Binderは誤ったvmaにページをインストールしてしまう可能性があります。書き込み可能なvmaにページをインストールすることで、本来は読み取り専用のバインダーページに書き込みが可能になります。これらのページに書き込むことは本来できませんが、Rust Binderの設計意図では、この権限を得ても悪影響は生じないと考えられていました。ところが別のバグにより、そうではありませんでした。この問題を修正するために、vm_private_dataにポインタを格納し、vma_lookup()で返されるvmaが正しいvm_opsとvm_private_dataを持つことを使用前に確認するようにしました。これにより、Rust Binderが他のVMAと不正に関わることを防ぎます。今後は、vm_opsやvm_private_dataへの安全でないアクセスを避けるため、より多くのvma抽象化を導入する計画ですが、まずは最も簡単な修正から始めます。C Binderはやや異なる方法で同様のチェックを行っており、vm_ops-closeでbooleanをtrueに設定し、vma_lookup()後にそのbooleanを確認しますが、本パッチの解決策のほうが堅牢です（両方行うことが望ましいですが、vm_ops-closeコールバックは後続のvma API変更の一部として追加予定です）。vmaのリマップにより、ページが正しいvmaに表示されても誤ったオフセットになる問題は依然として存在しますが、これは別問題であり、Rust Binderにvm_ops-closeコールバックが追加される際に修正されます。

Apache CXFにおいて、信頼されていないJMS設定がリモートコード実行（RCE）につながる可能性がある問題の修正が不完全であり、別の経路で信頼されていないユーザーがJMS設定を操作できるため、コードが実行されるリスクがあります。ユーザーは、この問題を修正したバージョン4.2.1、4.1.6、または3.6.11にアップグレードすることを推奨します。

Snipe-ITはIT資産およびライセンス管理を行うシステムです。バージョン8.4.1以前では、users.edit権限のみを持つ認証済みユーザーが、PATCHリクエストを/api/v1/users/{id}に対してpermissions[admin]=1を送信することで、自身の権限を管理者に昇格させることが可能でした。APIコントローラーはpermissions配列からsuperuserキーのみを除外しており、adminやその他の権限キーはユーザー更新権限を持つ任意のユーザーによって設定可能でした。この脆弱性は8.4.1で修正されました。

Snipe-ITはIT資産およびライセンス管理システムです。バージョン8.4.1以前のSnipe-ITには、未検証のHTTP Refererヘッダーがセッション変数に保存されることで、攻撃者がユーザーを悪意のあるサイトにリダイレクトできるオープンリダイレクトの脆弱性が存在します。この脆弱性はバージョン8.4.1で修正されました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。net: skbuffに関する連結処理時に共有フラグマーカーを保持する問題です。skb_try_coalesce()は@fromから@toへページ化されたフラグメントを添付できます。もし@fromにSKBFL_SHARED_FRAGが設定されている場合、結果としてできる@to skbは同じ外部所有もしくはページキャッシュ対応のフラグメントを含みますが、共有フラグマーカーが現在失われています。それにより、後続のインプレースライターが依存する不変条件が破られます。特にESPは、クローンされていない非線形skbがskb_cow_data()をスキップできるかを決定する前にskb_has_shared_frag()をチェックします。TCPの受信連結が共有フラグメントを未マーキングのskbに移動した場合、ESPはskb_has_shared_frag()をfalseと判断し、ページキャッシュ対応フラグメント上にインプレースで復号を行ってしまう可能性があります。skb_try_coalesce()がページ化フラグメントを転送する際にSKBFL_SHARED_FRAGを伝搬させる修正が加えられました。テールルームコピー経路では、バイトを@toの線形データにコピーするためフラグマーカーは不要です。

Ruby 4のバージョン4.0.5より前に問題が発見されました。pthreadベースのgetaddrinfoタイムアウトハンドラ（ext/socket/raddrinfo.c内のrb_getaddrinfo）における競合状態により、use-after-freeが発生します。これにより、リモート攻撃者がユーザー指定のタイムアウト付近でDNS応答を遅延させることができ、Addrinfo.getaddrinfo(..., timeout:)またはSocket.tcp(..., resolv_timeout:)を呼び出すRubyプロセスをクラッシュさせる可能性があります。理論的には、この脆弱性を利用してメモリ破損を引き起こす攻撃も可能です。この攻撃は、例えば巧妙に作られた権威DNSサーバーや再帰的リゾルバを通じて実行される可能性があります。

LiteLLMのバージョン1.83.14以前では、認証されたinternal_userが自分の役割で許可されていないルートへのアクセス権を持つAPIキーを作成することが可能です。キーを生成する際、allowed_routesフィールドに指定されたルートがユーザー自身の権限内にあるかどうかを検証せずに保存されます。管理者専用ルートにアクセスできるキーを作成すると、そのルートに正常に到達でき、通常は役割ベースのアクセス制御によってブロックされるリクエストを回避できるため、internal_userがproxy_adminへ完全な特権昇格を行うことが可能になります。