OSコマンドインジェクションとは?仕組み・脆弱性事例・企業の対策を解説

セキュリティ用語

投稿日時: 更新日時:

OSコマンドインジェクションとは?仕組み・脆弱性事例・企業の対策を解説

OSコマンドインジェクションとは、アプリケーションが外部から受け取った値をOSコマンドの生成に使用する際、入力値を適切に処理しないことで、意図しないOSコマンドが実行される脆弱性です。MITREではCWE-78「Improper Neutralization of Special Elements used in an OS Command」として分類されています。

悪用条件は製品によって異なります。インターネットから認証なしで悪用できる脆弱性もあれば、管理画面へのログイン、特定機能の利用、ローカルでのユーザー操作を必要とするものもあります。そのため、「OSコマンドインジェクション=必ず未認証で遠隔コード実行」とは限りません。

一方、攻撃が成立した場合は、アプリケーションが動作しているOS上でコマンドを実行され、情報の読み取り・改ざん、マルウェア実行、サービス停止、内部ネットワークへの侵害拡大につながる可能性があります。特にVPN、ファイアウォール、ルーターなどのネットワーク境界機器で発生すると、外部から組織内部への侵入経路になる場合があります。

米国CISAとFBIは2024年、OSコマンドインジェクションを「予防可能な脆弱性クラス」と位置付け、Secure by Designの観点からソフトウェアメーカーへ根本的な対策を求めました。本記事では攻撃を再現する具体的なコマンドや手順は掲載せず、CWE-78の仕組み、実際の脆弱性事例、開発・運用側の対策を整理します。

OSコマンドインジェクションとは

MITREのCWE-78は、OSコマンドに含まれる特殊な要素を適切に無害化できていない状態をOSコマンドインジェクションとして分類しています。

典型的には、アプリケーションが次のような処理を行う場面で発生します。

  • ファイルやディレクトリを操作する
  • ネットワーク診断コマンドを呼び出す
  • バックアップや圧縮処理を実行する
  • 外部プログラムを起動する
  • 管理画面からOSやネットワーク設定を変更する
  • シェルスクリプトやユーティリティへ引数を渡す

こうした機能自体が問題なのではありません。

問題は、利用者や外部システムから受け取った値を、OSが「単なるデータ」ではなく「コマンドや引数の一部」として解釈できる形で渡してしまうことです。

OWASPは、OSコマンドインジェクション対策として、可能な限りOSコマンドを直接呼び出さず、同等機能を提供する言語標準のAPIやライブラリを使用することを第一の選択肢に挙げています。

OSコマンドインジェクションが発生する仕組み

アプリケーションでは、利用者の入力を受け取り、その値を別の処理へ渡すことがあります。

たとえば管理画面で指定されたホスト、ファイル名、ディレクトリ名、IPアドレスなどを、OS上の別プログラムへ渡す設計です。

安全な実装では、「実行する処理」と「利用者が指定する値」が明確に分離されています。

一方、OSコマンドインジェクションが生じる実装では、外部入力がシェルで解釈される文字列へ組み込まれます。攻撃者が入力内容を操作できる場合、アプリケーションが予定していなかった追加処理として解釈される可能性があります。

成立までの流れを抽象化すると、次のようになります。

段階 状態
1 アプリケーションが外部入力を受け取る
2 入力値を使ってOSコマンドや引数を組み立てる
3 入力値の制約や分離が不十分なままシェル等へ渡す
4 OSが入力の一部を命令として解釈する
5 アプリケーションの実行権限で意図しない処理が行われる

攻撃時の影響範囲は、脆弱なプロセスの権限に左右されます。

管理者やrootに近い権限でアプリケーションが動作していれば、同じ脆弱性でも影響が大きくなる可能性があります。このため、入力処理だけでなく最小権限も被害を限定するための対策になります。

OSコマンドインジェクションとRCEの違い

OSコマンドインジェクションとRCE(Remote Code Execution)は同じ意味ではありません。

OSコマンドインジェクションは「脆弱性が生じる原因・種類」を示す言葉です。CWE-78がこれに該当します。

RCEは「遠隔からコードやコマンドを実行できる影響・状態」を表す言葉です。

用語 主に表すもの
OSコマンドインジェクション OSコマンドへ外部入力が不適切に混入する脆弱性
RCE 遠隔から任意コード・コマンドを実行できる状態
SQLインジェクション SQL文へ外部入力が不適切に混入する脆弱性
コードインジェクション プログラムとして解釈されるコードを注入できる脆弱性

OSコマンドインジェクションがネットワーク経由・認証なしで成立する場合、結果としてRCEにつながることがあります。

一方、サクラエディタのCVE-2026-59561のように、利用者が細工された名称のディレクトリに置かれたファイルを開き、特定機能を使用することが攻撃成立条件となる事例もあります。

したがって、CVEを評価するときは「CWE-78である」という分類だけではなく、攻撃元区分、認証要否、必要権限、ユーザー操作、対象プロセスの権限を確認します。

SQLインジェクションとの違い

OSコマンドインジェクションとSQLインジェクションは、どちらも「外部入力と命令を安全に分離できていない」という点では共通しています。

ただし、命令を解釈する対象が異なります。

項目 OSコマンドインジェクション SQLインジェクション
命令を解釈する対象 OS・シェル・外部プログラム データベース
代表的なCWE CWE-78 CWE-89
主な影響 OS上のコマンド実行 DBの情報取得・改ざん・削除等
影響する権限 アプリケーションプロセスのOS権限 DB接続アカウントの権限
根本対策 OSコマンド直接呼び出しを避ける、引数分離、入力制約 プレースホルダー・パラメータ化等

どちらも入力値を単純に「危険な文字だけ削除する」設計へ依存すると、想定外の入力方法や処理系の違いによって制御を回避される可能性があります。

CISAとFBIはOSコマンドインジェクションを「予防可能」と指摘

CISAとFBIは2024年7月、「Eliminating OS Command Injection Vulnerabilities」を公開しました。

この文書では、OSコマンドインジェクションについて、20年以上にわたって脆弱性と対策が広く知られ、実効的な緩和策も存在するにもかかわらず、ソフトウェア製品で繰り返し発生していると指摘しています。

公表の背景として、CISAとFBIは次の脆弱性を挙げています。

CVE 製品・分野 CISA/FBIが示した状況
CVE-2024-20399 Ciscoのネットワーク境界製品 攻撃キャンペーンで悪用されたOSコマンドインジェクション
CVE-2024-3400 Palo Alto Networks PAN-OS ネットワーク境界製品で実悪用
CVE-2024-21887 Ivanti Connect Secure / Policy Secure 攻撃で悪用されたコマンドインジェクション

CISAとFBIは、ソフトウェアメーカーへ次の対応を求めています。

  • コマンドと引数を安全に分離する機能を使う
  • 脅威モデルを見直す
  • モダンなコンポーネントライブラリを利用する
  • コードレビューを行う
  • 開発ライフサイクル全体で攻撃を想定したテストを行う

2025年のCISA/FBI「Product Security Bad Practices」でも、CWE-78を体系的に防止することが推奨され、OSコマンドを実行する代わりに組み込みライブラリを利用することや、厳格な許可リスト型入力制御が例示されています。

OSコマンドインジェクションを「脆弱性診断で後から見つければよい問題」ではなく、設計段階で作り込まないことが求められています。

英国NCSCが注意喚起したIvantiの実悪用事例

英国NCSCは2024年、Ivanti Connect SecureとIvanti Policy Secureの脆弱性について、組織へ早急な対応を呼びかけました。

対象の一つであるCVE-2024-21887はWebコンポーネントのコマンドインジェクション脆弱性です。

単独では管理者権限を持つ認証済みユーザーが攻撃条件でしたが、認証バイパスのCVE-2023-46805と組み合わせた場合、認証なしで任意コマンドを実行できる状態になるとNCSCは説明しています。

この事例が示すのは、1件のCVEだけでリスクを判断できない場合があることです。

複数の脆弱性を組み合わせることで、

  • 認証を突破する
  • 管理機能へ到達する
  • OSコマンドを実行する

という攻撃経路が成立することがあります。

VPNやリモートアクセス製品はインターネットへ公開され、内部ネットワークへの入口として動作します。そのため、境界機器のOSコマンドインジェクションは、一般的な社内アプリケーション以上に対応優先度が高くなる場合があります。

イスラエル国家サイバー局もCWE-78によるRCEを注意喚起

イスラエル国家サイバー局(INCD)は2024年3月、Unitronics UniStream向けソフトウェアの複数脆弱性について注意喚起しました。

公表された8件の脆弱性には、CVE-2024-27772が含まれています。

同局はCVE-2024-27772をCWE-78「OS Command Injection」、CVSS 8.8、影響をRemote Code Executionとして整理し、対象ユーザーへ修正版への更新を推奨しました。

INCDはWebアプリケーションセキュリティの教育プログラム「WebSec」も提供しており、Webアプリケーションで使われる攻撃、脆弱性、影響、防御方法を扱っています。

米国CISA/FBI、英国NCSC、イスラエルINCDの資料を見ると、OSコマンドインジェクションはWebサービスだけの問題ではなく、VPN、ネットワーク機器、OT関連製品、管理ソフトウェアなど幅広い製品で管理対象となっています。

セキュリティ対策Labの事例1:サクラエディタではユーザー操作が攻撃条件

セキュリティ対策Labでは2026年8月、サクラエディタのCVE-2026-59561を取り上げています。

JVNによると、この脆弱性はOSコマンドインジェクション(CWE-78)に分類されます。

影響を受けるのはv2.4.3より前のバージョンで、細工された名称のディレクトリに置かれたファイルを利用者が編集し、「ターミナルを起動」機能を使用した場合に意図しないOSコマンドが実行される可能性があります。

このケースでは、ネットワーク越しに攻撃者が直接コマンドを送信するわけではありません。攻撃成立には利用者の操作が必要です。

OSコマンドインジェクションは「Webフォームに不正な文字列を入力する攻撃」だけではなく、ファイル名、ディレクトリ名、設定値など、アプリケーションがOSコマンドへ渡すあらゆる外部入力で発生し得ることが分かります。

セキュリティ対策Labの事例2:TP-Link Omadaでは認証要否でリスクが異なる

2025年10月に取り上げたTP-Link OmadaゲートウェイのCVE-2025-6541/CVE-2025-6542も、OSコマンドインジェクションの事例です。

2件は同じCWE-78ですが、攻撃条件が異なります。

  • CVE-2025-6542:遠隔・認証不要で悪用可能
  • CVE-2025-6541:管理Webへログイン可能な攻撃者が悪用可能

同じ「OSコマンドインジェクション」という分類でも、インターネット公開の有無や認証要否によって優先度は変わります。

脆弱性管理ではCWE名だけで一覧を作るのではなく、次の条件を付けて判断します。

  • インターネットから到達できるか
  • 認証が必要か
  • 必要な権限は何か
  • 利用者操作が必要か
  • 任意コマンド実行まで到達するか
  • CISA KEVに掲載されているか
  • ベンダーや公的機関が実悪用を確認しているか

セキュリティ対策Labの事例3:SolarView Compactでは認証済みユーザーからOS侵害へ進む

2026年9月に取り上げたコンテック SolarView CompactのCVE-2026-82794もCWE-78に分類されています。

同脆弱性はスケジュール設定画面に存在し、製品へログイン可能な攻撃者がOSで実行できるコマンドを送信できる可能性があります。

CVSS v3.1は8.8で、攻撃には低い権限が必要ですが、ユーザー操作は不要と評価されています。

この事例では、「認証が必要だから危険度が低い」と単純には判断できません。

攻撃者がフィッシング、パスワード使い回し、InfoStealer、別の脆弱性などによって正規認証情報を取得していれば、ログイン後のOSコマンドインジェクションが次の侵害段階として利用される可能性があります。

認証後の管理画面も脆弱性診断やコードレビューの対象に含める必要があります。

セキュリティ対策Labの事例4:FileZenでは実際の被害報告を確認

FileZenのCVE-2026-25108では、ログオン後画面にコマンドインジェクション脆弱性が存在し、ソリトンシステムズは悪用による被害報告を1件以上受けていると公表しました。

PoCが存在すること、CVSSが高いこと、OSコマンドを実行できることと、「実際の攻撃で悪用されたこと」は別の情報です。

企業が対応優先度を判断する際は、

  • 脆弱性が理論上悪用可能
  • PoCが公開
  • 攻撃試行を観測
  • ベンダーが被害を確認
  • CISA KEVへ掲載

を区別して管理します。

OSコマンドインジェクションで想定される影響

OSコマンドインジェクションの影響は、製品、実行権限、ネットワーク構成によって異なります。

代表的には次の影響があります。

影響 内容
情報窃取 設定ファイル、認証情報、ログ、機密データ等へアクセスされる
改ざん ファイルやシステム設定を書き換えられる
マルウェア実行 外部から取得したプログラム等を実行される
永続化 再起動後もアクセスを維持する仕組みを追加される
サービス停止 ファイル削除や設定変更などでサービスを利用できなくされる
横展開 侵害した機器を足掛かりに内部ネットワークへ移動される
認証情報窃取 OSやアプリケーションが保持する資格情報へアクセスされる

ただし、CWE-78の脆弱性が存在するだけで、これら全てが必ず実行可能とは限りません。

公表されたCVEのCVSS、ベンダーアドバイザリ、実行権限、製品構成を確認し、想定される影響を個別に判断します。

開発側の対策は「危険な文字を削除する」だけではない

OWASPは、OSコマンドインジェクションの第一の対策として「OSコマンドを直接呼び出さないこと」を挙げています。

たとえばファイル操作、ディレクトリ作成、圧縮、HTTP通信などで、プログラミング言語やフレームワークが安全なAPIを提供している場合は、シェル経由のコマンド実行を避けます。

どうしても外部プログラムを実行する必要がある場合は、複数の対策を組み合わせます。

対策 確認内容
OSコマンド呼び出しを避ける 標準API・ライブラリで代替できないか
コマンドと引数を分離する 文字列連結ではなく構造化された実行方式を利用する
許可リスト型入力検証 想定する形式・文字・長さだけを許可する
実行可能なコマンドを固定する 利用者が実行プログラム自体を指定できないようにする
最小権限 Webアプリやサービスを管理者・root権限で動かさない
サンドボックス・分離 必要に応じて実行環境を分離する
コードレビュー OSコマンド実行APIへ外部入力が到達していないか確認する
SAST 外部入力から危険な実行関数までのデータフローを確認する
DAST・脆弱性診断 実行環境で入力処理に問題がないか確認する
セキュリティテスト 認証後機能、異常系、設定変更機能も対象にする

入力検証だけに依存すると、OSやシェル、呼び出す外部プログラムによって解釈が異なる問題が残ります。

設計段階で「利用者が指定するデータをシェルへ渡さない」構造にすることが根本対策です。

WAFだけでは根本対策にならない

Web Application Firewall(WAF)は、既知の攻撃パターンや不審な入力を検出・遮断する補助策として利用できます。

しかし、OSコマンドインジェクションの修正をWAFだけで代替するべきではありません。

理由は次の通りです。

  • 入力形式やエンコードによって検出が難しくなる場合がある
  • 認証後の管理機能がWAF監視の対象外になっている場合がある
  • Web以外のプロトコルやローカル入力から成立するCWE-78もある
  • 正規値と悪意ある値をWAFだけで完全に判定できるとは限らない
  • 脆弱なコード自体は残る

サクラエディタの事例のように、WebアプリケーションではないソフトウェアでもOSコマンドインジェクションは発生します。

WAFは暫定緩和策や多層防御の一部として扱い、可能な場合はベンダー修正版の適用やコード修正を優先します。

SAST・DAST・脆弱性診断では何を確認するか

OSコマンドインジェクションは、開発工程と実行環境の両方から確認します。

SASTやコードレビューでは、外部入力がOSコマンド実行処理へ到達するデータフローを確認します。

対象となる入力はWebフォームだけではありません。

  • URLパラメータ
  • HTTPヘッダー
  • APIリクエスト
  • ファイル名
  • ディレクトリ名
  • アップロードファイルのメタデータ
  • 設定ファイル
  • 環境変数
  • 外部サービスの応答
  • DBに保存された値

なども、後からOSコマンド生成へ使用される場合があります。

DASTやWebアプリケーション脆弱性診断では、実際のアプリケーションへ入力を与え、意図しないコマンド実行につながる動作がないかを確認します。

ただし、自動診断だけでは複雑な認証後機能や業務ロジックを十分にたどれない場合があります。

重要な管理画面やOS機能を呼び出す機能は、手動診断やペネトレーションテストも組み合わせます。

脆弱性診断ツールの種類と自動・手動診断の違いを整理している場合は、診断範囲の設計時に併せて確認できます。

製品利用企業はCWE名より「悪用条件」を確認する

自社開発をしていない企業でも、OSコマンドインジェクションは脆弱性管理の対象になります。

ベンダー製品にCWE-78が公表された場合は、次の順で確認します。

  1. 自社で対象製品を利用しているか
  2. 影響バージョンに該当するか
  3. インターネットへ公開されているか
  4. 認証なしで悪用できるか
  5. 攻撃に必要な権限は何か
  6. 利用者操作が必要か
  7. 任意コマンド・コード実行につながるか
  8. 修正版・回避策があるか
  9. PoCが公開されているか
  10. ベンダー・CERT・公的機関が実悪用を確認しているか
  11. CISA KEVに掲載されているか
  12. 攻撃痕跡を確認する方法が公表されているか

CISAのKEVには、CWE-78に分類されるOSコマンドインジェクション脆弱性が複数掲載されています。

たとえばCVE-2023-28771はZyxelの複数ファイアウォールに影響し、認証なしの攻撃者が細工したパケットによってOSコマンドを遠隔実行できる脆弱性としてKEVへ掲載されています。

KEV掲載の有無は対応優先度を決める材料になりますが、未掲載であることは安全性を意味しません。

ベンダーが実悪用を確認している場合や、インターネット公開の境界機器で未認証RCEにつながる場合は、KEV掲載を待たずに対応を判断します。

従業員600人以上の企業が確認したいポイント

従業員600人以上の企業では、自社開発、SaaS、ネットワーク機器、OT、グループ会社、委託開発など、CWE-78が発生し得る対象が複数部門に分かれます。

情報システム部門、セキュリティ部門、開発部門では次を確認します。

  • インターネット公開しているVPN、FW、ルーター、管理製品を一覧化しているか
  • 公開製品のCVEを継続的に監視しているか
  • CISA KEVやベンダーの実悪用情報を脆弱性管理へ取り込んでいるか
  • 認証後の管理画面も脆弱性診断の対象にしているか
  • 自社開発でOSコマンドを直接呼び出す箇所を把握しているか
  • シェル実行を標準APIやライブラリへ置き換えられないか確認しているか
  • 外部入力を許可リスト方式で制約しているか
  • アプリケーションを必要以上の権限で実行していないか
  • SASTで外部入力からOSコマンド実行処理までのデータフローを確認しているか
  • WebアプリのDAST・手動診断を変更時に実施しているか
  • 委託開発の受入条件にCWE-78を含む入力処理の検証を定めているか
  • 脆弱性公表時に対象資産をすぐ特定できるか
  • 修正後に再診断・バージョン確認を行っているか
  • WAFの適用だけで恒久対応を完了扱いにしていないか
  • EDR、サーバーログ、ネットワークログから不審なコマンド実行を調査できるか

OSコマンドインジェクションは新しい攻撃手法ではありません。

CISAとFBIが「予防可能」と表現しているにもかかわらず、VPN、ネットワーク機器、管理ソフトウェア、デスクトップアプリケーションなどで現在も繰り返し公表されています。

企業側では、CWE-78という分類名だけを見るのではなく、「どこから入力できるか」「認証が必要か」「どの権限で実行されるか」「実悪用されているか」を確認し、開発側ではOSコマンドへ外部入力を渡さない設計を優先します。

出典