Gitea act_runner 脆弱性として2026年7月に詳細が公開されたのが、GiteaのセルフホストCI/CDランナー「act_runner」（gitea.com上の正式名称は gitea/runner。旧称 act_runner）に、コンテナ脱出につながる脆弱性 CVE-2026-58053 の詳細がVulnCheckのアドバイザリとして公開された。深刻度はCVSS v3.1で9.9、v4.0でも9.4という極めて高い値が付いている。この脆弱性が厄介なのは、「privileged: falseに設定していれば安全」という、多くの運用者が抱きがちな思い込みを正面から崩す点にある。act_runnerのDocker backendは、ワークフロー側が指定するコンテナオプションを検証せずにマージしてしまい、ランナー管理者が設定した安全側のデフォルトをすり抜けられる。日本語では、Gitea本体の脆弱性報道はあっても、CI実行基盤であるact_runner固有のこの穴を解説した記事はまだ見当たらない。この記事は、Gitea コンテナ脱出につながるDocker privileged 回避の仕組みと、自分のGitea/act_runner環境がこの穴を塞げているかをconfig.yamlとdocker inspectで確認する手順に絞って整理する。CI/CD ランナー セキュリティを運用面から底上げしたい読者を想定している。

act_runnerのコンテナ脱出フロー図。privileged:falseの設定→ワークフローがcontainer.optionsで--pid=hostや--cap-addを指定→act_runnerがオプションを検証せずマージ→ジョブコンテナがホストの名前空間・権限に到達し脱出が成立する4段階
CVE-2026-58053の脱出フロー概念図。config.yamlの安全側設定を、ワークフロー側のcontainer.optionsが上書きしてしまう構造

30秒でわかるポイント

  • ・正体：Gitea act_runner（Docker backend）のコンテナ堅牢化バイパス。CVE-2026-58053、CVSS v3.1で9.9、v4.0で9.4
  • ・誤解しやすい点：config.yamlでprivileged: falseにしていても、ワークフロー側のcontainer.optionsが--pid=hostや--cap-addを追加でき、それがそのままマージされて安全側の設定が意味を失う
  • ・対象：act_runner 0.262.0以前・Docker backend使用時。Kubernetes backend／ローカルbackendは対象外
  • ・パッチ状況：本記事執筆時点で、複数の一次ソース（VulnCheck・OffSeq）が公式修正版を明記していない。緩和策での対応が要点
  • ・併せて見るべきもの：同時期に発覚したGitea本体の認証バイパスCVE-2026-20896（Docker公式イメージ）。セルフホスト運用者は2つの穴を同時に点検すべき

なお、CI/CDパイプラインを含むソフトウェアサプライチェーン全体の攻撃手法・防御ツールを体系的に押さえておきたい運用者は、サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストも合わせて読んでほしい。本記事はそのうち「CI実行基盤（コンテナランタイム）の権限設計不備を、自分の環境で判定・緩和する」実務編にあたる。

Gitea act_runner 脆弱性が突く「privileged: false」の思い込み

まず、この脆弱性が突く思い込みを正確に言葉にしておく。多くのact_runner運用者は、config.yamlのDocker backend設定でprivileged: falseとし、危険なDockerオプションを許可しない構成にすることで、「ジョブコンテナはホストから隔離されている」と考える。VulnCheckのアドバイザリの表題は、その前提が崩れることを端的に示している。「Container Hardening Bypass via Workflow Container Options」——ワークフロー側のコンテナオプションを経由した、堅牢化バイパスだ。

container.optionsという抜け道

act_runnerのDocker backendは、Giteaの.gitea/workflows配下に置かれるワークフローYAMLの中で、jobのcontainerブロックにoptions:としてDocker実行時オプションを追加指定できるようにしている。これは本来、特定のジョブだけで追加のマウントやネットワークモードを使いたい、といった正当な用途のための拡張ポイントだ。

問題は、このoptions:の中身が、ランナー側のハードニング設定より優先してマージされてしまうことにある。つまり、config.yamlのcontainer設定でprivileged: falseにしていても、ワークフロー側が

・--pid=host（ホストのPID名前空間を共有）
・--cap-add=SYS_ADMINのような追加ケーパビリティ
・--security-opt seccomp=unconfined（seccompフィルタの無効化）

といったオプションを指定すれば、それらがフィルタされずにコンテナ起動コマンドへ反映される。ランナー管理者が「危険な設定を禁止した」つもりでも、ワークフローを書ける人物（あるいはワークフローを注入できる攻撃者）が、その禁止を後から上書きできるというのが、この脆弱性の急所だ。

「privileged: false」は既定値であってポリシーの強制ではない：この脆弱性の本質は、config.yamlの安全側設定が「ワークフローの記述内容より弱い優先度」で扱われている点にある。運用者目線では「デフォルトを安全にした」つもりでも、ワークフロー側から個別に上書きできる余地が残っていれば、それは強制ではなく単なる初期値にすぎない。この考え方は、CI/CDランナー全般のセキュリティ設計を評価するときにも使える視点だ。

act_runnerの脆弱性が示すのは「隔離の強さ」ではなく「隔離設定を誰が最終的に決めているか」という設計上の問題である。

なぜコンテナ脱出につながるのか

--pid=hostが通ると、ジョブコンテナはホストと同じPID名前空間を見る。ホスト上の全プロセスが見え、/proc/<pid>/root経由でホストのファイルシステムへアクセスできる余地が生まれる。--cap-add=SYS_ADMINが通ると、マウント操作やケーパビリティに依存する各種の権限昇格手法が使えるようになる。これらは単体でも危険だが、Dockerの標準的なコンテナ分離モデルが前提にしている「コンテナはホストの名前空間・ケーパビリティから隔離されている」という大前提そのものを外してしまう点で、通常の脆弱性とは性質が異なる。CVSS v3.1が9.9という数値は、この「隔離前提を丸ごと外せる」影響の大きさを反映していると読むのが妥当だ。

CVSSスコアと影響範囲

v3.1とv4.0でスコアが違う理由

CVE-2026-58053のCVSSスコアは、算出モデルによって数値が異なる。NVDの実測では次の通りだ。

CVSSバージョン スコア 備考
v3.1 9.9 旧来の算出モデル。多くの脆弱性データベースがこちらを主表記に使う
v4.0 9.4 新しい算出モデル（攻撃条件・環境要因の反映方法が変更されている）

両者はどちらも「Critical」帯に入る非常に高いスコアであり、矛盾ではなくCVSSの採点基準（バージョン）の違いによるものだ。本文や社内報告でスコアを引用する際は、必ずどちらのバージョンかを明記してほしい。バージョンを書かずに「CVSS 9.9」とだけ書くと、v4.0ベースの資料と突き合わせたときに数値が合わず混乱を招く。

影響を受けるバージョンとbackend

観点 内容
対象コンポーネント Gitea act_runner（gitea.com/gitea/runner）のDocker backend
影響を受けるバージョン act_runner 0.262.0以前（複数の一次ソースの記載に基づく）
対象backend Docker backend
対象外backend Kubernetes backend、ローカル（host直接実行）backend
CVSS v3.1 9.9
CVSS v4.0 9.4
修正パッチ 本記事執筆時点で、VulnCheck・OffSeq Threat Radarとも公式修正版を明記していない

backendによって対象・対象外が分かれる理由を、表で整理しておく。

backend 本脆弱性の対象か 理由
Docker backend 対象 ワークフローのcontainer.optionsがDocker runオプションとしてそのままマージされる経路を持つ
Kubernetes backend 対象外（一次ソースの記載に基づく） Podのセキュリティコンテキストという別の仕組みで実行環境を制御しており、本脆弱性が突くマージ経路とは異なる
ローカル（host直接実行）backend 対象外 そもそもコンテナによる隔離を介さない運用のため、コンテナ脱出という脅威モデル自体が成立しない

まずは自分のact_runnerがどのbackendで動いているかをconfig.yamlで確認するのが、対象・対象外を判断する最初の一歩になる。

同時に発覚したCVE-2026-20896とGiteaエコシステムの影響範囲マトリクス

CVE-2026-58053と同時期、Giteaのエコシステムではもう1件、深刻な脆弱性が動いていた。CVE-2026-20896——Gitea本体のDocker公式イメージにおける認証バイパスだ。原因はコンポーネントも攻撃条件も異なるが、「Giteaをセルフホストで運用している」という共通点を持つ読者にとっては、どちらも見逃せない。

CVE-2026-20896は、Gitea Docker公式イメージのREVERSE_PROXY_TRUSTED_PROXIESのデフォルト設定（*＝全信頼）が原因で、X-WEBAUTH-USERヘッダを任意の送信元から信用してしまう認証バイパスだ。The Hacker Newsの報道によれば、この脆弱性は公開から13日で実際の攻撃が観測されている。影響を受けるバージョンは1.26.2以前で、1.26.3/1.26.4で修正済みというのが、CVE-2026-58053（本記事の主題）との大きな違いだ——こちらは既にパッチが存在する。

CI/CDパイプライン自体が攻撃対象になる事例は、Giteaに限った話ではない。同種の攻撃面として、GitHub Actionsのワークフローファイルが悪用され短時間で数千リポジトリへ被害が広がったMegalodon GitHub攻撃：5,561リポジトリに悪意あるCI/CDワークフローを6時間で注入した2026年最大のサプライチェーン攻撃も参考になる。あちらは「悪意あるワークフローを注入する」攻撃、本記事のCVE-2026-58053は「正規のワークフロー定義がランナーの隔離を合法的に上書きできてしまう」設計不備という、同じCI/CDレイヤーの別の切り口だ。

flowchart TD A["Giteaセルフホスト運用者"] --> B{"act_runnerを使っているか"} B -- "はい" --> C{"Docker backendか"} C -- "はい" --> D["CVE-2026-58053 対象
container.options点検が必要"] C -- "いいえ(K8s/ローカル)" --> E["CVE-2026-58053 対象外"] B -- "いいえ" --> E A --> F{"Gitea本体をDocker公式
イメージで運用しているか"} F -- "はい" --> G["CVE-2026-20896 点検
REVERSE_PROXY_TRUSTED_PROXIES確認"] F -- "いいえ" --> H["CVE-2026-20896 対象外の可能性
ただし個別設定は要確認"]

両者を1つのマトリクスにまとめると、次のようになる。

観点 CVE-2026-58053（本記事の主題） CVE-2026-20896
影響コンポーネント act_runner（CI/CDジョブ実行基盤） Gitea本体（Docker公式イメージ）
脆弱性の種類 コンテナ堅牢化バイパス（隔離不備） 認証バイパス（ヘッダ偽装）
影響を受けるバージョン act_runner 0.262.0以前 Gitea 1.26.2以前（Docker公式イメージ）
CVSS v3.1: 9.9 / v4.0: 9.4 9.8
修正パッチ 本記事執筆時点で未公開（複数一次ソースの記載） 1.26.3 / 1.26.4で修正済み
実攻撃の観測 一次ソースでは明記なし 公開から13日後に観測（The Hacker News）
主対策 container.optionsの制限・緩和策（後述） Gitea 1.26.3/1.26.4への更新、REVERSE_PROXY_TRUSTED_PROXIESの見直し

読者の3つの問いへの答え
① このOSSは結局何ができる：act_runnerはGiteaのワークフローをDocker/Kubernetes/ローカル/SSHの複数backendで実行するCI/CDランナー本体。② 何を解決する：Gitea上でGitHub Actions互換のワークフローをセルフホスト実行する需要を満たす。③ 今回の脆弱性は何を壊すのか：Docker backendの隔離前提そのもの。ランナー管理者の安全側設定を、ワークフロー側のcontainer.optionsが上書きできてしまう。

Gitea act_runner 脆弱性への該当を自分の環境で確認する手順

ここからは、読み取り専用の確認手順だ。自分が管理するGitea/act_runner環境に対してのみ実行してほしい。

手順1：自分のbackendを確認する

cat /etc/act_runner/config.yaml | grep -A5 "container:"

出力のcontainer:セクションにdocker（またはDocker backendを示す設定）があるか、それともk8s／ローカル実行を示す設定になっているかをまず確認する。前章の表の通り、Docker backend以外であれば本脆弱性の実証経路の対象外になる。

手順2：config.yamlのcontainer.optionsに危険なフラグが無いかを確認する

cat /etc/act_runner/config.yaml | grep -A10 "options"

--pid=host / --cap-add / --security-opt seccomp=unconfined / --privilegedのようなフラグが、ランナー全体のデフォルトとして設定されていないかを確認する。これらが設定済みであれば、ワークフロー側から追加指定するまでもなく、すでに危険な状態にある。

手順3：実際に動いているジョブコンテナのHostConfigを確認する

docker inspect <act_runner_job_container_name> --format '' | python3 -m json.tool

ここが最も重要な確認だ。出力のうち、次の3項目を必ず見る。

・Privileged：falseであること（trueなら即座に危険）
・PidMode：空文字列であること。"host"になっていれば--pid=hostが効いている状態
・CapAdd：空またはnullであること。SYS_ADMIN等のケーパビリティが列挙されていれば要注意
・SecurityOpt：seccomp=unconfinedのような値が含まれていないこと

Privilegedがfalseだけでは判定を終わらせない：この脆弱性の核心は、まさに「Privileged: falseなのに、PidModeやCapAddが緩い値になっている」ケースを作れてしまう点にある。docker inspectの出力を見るときは、必ずHostConfig全体を確認し、Privilegedの1項目だけで「安全」と判断しないこと。

想定される落とし穴

act_runnerがDocker backend以外（Kubernetes backend等）で動いている場合、この脆弱性の実証経路の対象外になる。読者はまず手順1で自分のbackend種別を確認してから、以降の手順に進んでほしい。また、docker inspectはrootまたはdockerグループに属するユーザーで実行する必要がある点にも注意する。

対策・緩和策

前述の通り、本記事執筆時点で公式の修正パッチは複数の一次ソース（VulnCheck・OffSeq Threat Radar）で明記されていない。「アップグレードすれば直る」という前提を取らず、緩和策を主対策として運用する必要がある。

優先度 やること 位置づけ
最優先 信頼できないワークフロー（外部からのPR等）をact_runnerで自動実行しない運用にする ワークフロー側のcontainer.optionsを攻撃者に書かせないための根本対策
高 config.yamlのcontainer.optionsで、--pid / --cap-add / --security-opt等の危険なオプションをワークフロー側から追加できないよう、runner設定・レビュー体制で制限する 現時点でのメイン緩和策
中 ワークフローYAMLの変更を、CODEOWNERS等でレビュー必須にする 悪意あるcontainer.options指定の混入を人手で止める
中 Docker backend自体をやめ、Kubernetes backend（Podセキュリティコンテキストで制御）へ移行を検討する 本脆弱性の実証経路そのものを避ける運用変更
継続 VulnCheck・OffSeq・gitea.com公式のアドバイザリを継続的に確認し、パッチが出次第すみやかに適用する 修正版公開後の対応

CI/CDに使うOSS自体の来歴・依存関係を把握しておくことも、こうした個別CVEへの対応力を底上げする。ソフトウェア部品表（SBOM）の作り方・活用法はSBOM入門｜ソフトウェア部品表でサプライチェーン攻撃を防ぐSPDX・CycloneDX・Syft活用法にまとめている。

「外部PRからのワークフロー自動実行」がある環境は特に優先度が高い：GitHub Actionsのセルフホストランナーと同様、Giteaでも外部から提出されたPRのワークフローを自動実行する運用は、攻撃者が直接container.optionsを書き込める経路になりうる。こうした運用をしている場合は、緩和策の中でも「信頼できないワークフローを自動実行しない」を最優先で見直してほしい。

他のCI/CDランナーとの位置づけ

CI/CDランナーのコンテナ隔離設計は、act_runnerに限った課題ではない。同じ「ワークフロー定義側からコンテナの実行条件を指定できる」設計を持つランナーは、程度の差はあれ同種のリスクを抱える。

ランナー Giteaとの関係 実行モデル
Gitea act_runner（runner） Gitea公式のCI/CDランナー Docker / Kubernetes / ローカル / SSH等の複数backend
GitHub Actions self-hosted runner 無関係（GitHub専用） プロセス実行が基本。コンテナ化するかは利用者の構成次第
Woodpecker CI agent Gitea/Forgejoとの連携を主眼に設計（ライセンス等は本記事では未検証） コンテナベースの実行モデル
Drone CI runner Woodpeckerの派生元にあたるプロジェクト（ライセンス等は本記事では未検証） コンテナベースの実行モデル

Woodpecker・Drone側のライセンスやスター数はこの記事では裏取りしておらず、比較のための数値としては使っていない。ここで伝えたいのは、「ワークフロー定義がコンテナの実行条件を左右できる」設計は業界共通の課題であるということだ。act_runnerのDocker backendを使い続ける場合は、前章の緩和策を継続的に運用してほしい。

まとめ

CVE-2026-58053は、Gitea act_runnerのDocker backendが、ワークフロー側のcontainer.optionsを検証せずにマージしてしまうコンテナ堅牢化バイパスだ。CVSSはv3.1で9.9、v4.0で9.4という非常に高い値が付いており、privileged: falseという運用者の安全側設定が、ワークフロー側からの--pid=hostや--cap-add指定によって実質的に無効化されうる。

実務上の要点を3つに絞る。

  1. 「privileged: false」を過信しない。 config.yamlのデフォルト設定は、ワークフロー側のcontainer.optionsに上書きされうる。Privilegedの1項目だけでなく、docker inspectでPidMode・CapAdd・SecurityOptまで確認する
  2. backendで対象・対象外が分かれる。 Docker backendが対象、Kubernetes backend・ローカルbackendは対象外（一次ソースの記載に基づく）。まず自分のbackend種別を確認する
  3. パッチ待ちにしない。 本記事執筆時点で公式修正版は明記されていない。信頼できないワークフローの自動実行を止める・container.optionsを制限する・レビュー体制を敷くといった緩和策を、今すぐ運用に組み込む

同時期に発覚したCVE-2026-20896（Gitea Docker公式イメージの認証バイパス、CVSS 9.8、1.26.3/1.26.4で修正済み）と合わせて、Giteaをセルフホストで運用しているなら、この2つの穴を同時に点検してほしい。個別のCVE番号を追うだけでなく、「ワークフロー定義側にどこまでの権限を与えているか」という設計そのものを見直す機会として捉えるのが、この種の脆弱性への向き合い方として実効性が高い。

参照ソース

・VulnCheck — Gitea act_runner Container Hardening Bypass via Workflow Container Options — CVE-2026-58053の技術詳細・CVSSスコア・悪用条件
・NVD — CVE-2026-58053 — CVSS v3.1/v4.0スコア・CWE分類・公開日の一次情報
・OffSeq Threat Radar — CVE-2026-58053 — 影響バージョン・パッチ未公開の明記
・The Hacker News — Threat Actors Probe Gitea Docker Flaw CVE-2026-20896 — 併記するCVE-2026-20896の実攻撃観測タイムライン
・SecurityWeek — Critical Gitea Flaw Under Active Exploitation — CVE-2026-20896の詳細・修正バージョン(1.26.3/1.26.4)