Argo CDの脆弱性一覧と対処：2026年10月のCritical4件と修正版3.5.4・3.4.10・3.3.15への更新手順

Argo CDでは2026年10月7日、CVSS 9.9のCriticalを4件含む8件の脆弱性がGitHub Security Advisoryで公表されました。修正版は3.5.4・3.4.10・3.3.15で、2.x系と3.0〜3.2系にはパッチが出ません。この記事では、8件の影響版と修正版の対応表、稼働中のArgo CDが該当するかを確かめるコマンド、すぐに上げられないときの暫定回避策、パッチ更新の手順をコード付きでまとめました。トークンやAPIキーが漏れるとして報じられたCVE-2025-55190とCVE-2026-42880の発生条件も、アドバイザリの記述に沿って整理しています。

まとめ：Argo CDの脆弱性対応で先に決める版番号と回避策の要点

更新先の結論は次のとおりです。3.3系・3.4系・3.5系を使っているなら、同じマイナー版の最新パッチ（2026年10月19日時点で3.3.16・3.4.11・3.5.5）へ上げれば、10月7日公表の8件はすべて塞がります。パッチ版の更新は公式に「破壊的変更を含まない」とされており、マニフェストの再適用だけで済みます。

急ぐべきは、2.x系か3.0〜3.2系で止まっている環境です。サポート外のためパッチが出ず、3.3以降へのマイナー版アップグレードが必要になります。段階的に上げる時間を取れない場合は、--enable-helm の削除とJsonnetの無効化で2件を先に塞ぎ、残りは権限の絞り込みで攻撃者になりうる人を減らします。

今回の8件は、ほぼすべてが「Argo CDにログインできる人」か「Gitへ書き込める人」を攻撃者として想定しています。社外に公開していないから安全、とは言えません。開発者や協力会社にGitの書き込み権限を広く配っている構成ほど、影響が大きくなります。

2026年10月7日公表のArgo CD脆弱性8件と影響を受ける版の範囲

まず、今回の8件の中身です。番号の基礎はCVE（共通脆弱性識別子）とは、スコアの読み方はCVSSv3とは？v3.1の計算式・スコアの目安で扱っています。修正を含むリリースはv3.5.4のリリースノートに一覧があります。

8件の深刻度・影響の始まり・修正版を並べた対応表と照合時の注意点

8件とも修正版は共通で、3.6.0-rc2・3.5.4・3.4.10・3.3.15です。違うのは、どの版から影響を受けるかと、攻撃に必要な条件のほうです。

CVE番号がまだ付いていない3件のCriticalは、GHSA番号で追います。脆弱性スキャナーがCVE番号だけで照合している場合、この3件は検出に出てこない可能性があります。

KustomizeとJsonnetでrepo-serverを突くCritical3件

3件はいずれも、マニフェストを生成する argocd-repo-server の中で、攻撃者の用意したものが動くか読まれる問題です。repo-serverはGit・Helm・OCIの認証情報を扱うため、そこで読まれた情報がそのまま他のリポジトリへの侵入口になります。

攻撃者の入口は2つあるとGHSA-9v9p-x54c-58gcは説明しています。1つはApplicationが参照するGitリポジトリへの書き込みです。もう1つは POST /api/v1/applications/manifestsWithFiles へのアップロードで、こちらは既存Applicationの get 権限だけで足ります。同期の権限もGitの書き込み権限も要りません。

Helm経由のGHSA-fw5c-w8rc-j7fxは、argocd-cmで --enable-helm を渡している環境だけが対象です。JsonnetのGHSA-m3vr-7329-44wwは、絶対パスや ../ で /proc/self/environ やサービスアカウントのトークンまで読めるとされています。

AppProject制限を削除フックで越えるCVE-2026-77459の影響範囲

マルチテナント運用で効いてくるのがこの1件です。Argo CDは同期のたびに、作るリソースがAppProjectの許可範囲に収まっているかを確認します。ところがGHSA-fmxq-cgp8-87wpによると、PreDeleteとPostDeleteのフックはこの確認を通らず、application-controllerの権限でそのまま作られます。

Gitへ書き込める利用者がフックを仕込むと、Applicationが削除された時点で、本来は禁止されている ClusterRoleBinding などが作られかねません。PostDeleteフックはv2.10.0、PreDeleteフックはv3.3.0で入った機能です。PreSyncやPostSyncなど他のフックは従来どおり確認を通ります。

SSHリポジトリのproxy指定とログイン試行制限回避のHigh2件

CVE-2026-55797は、SSHで接続するリポジトリにproxyを設定すると、その値がシェルのコマンドに埋め込まれる問題です。HTTPSのリポジトリはこの経路を通りません。リポジトリやクレデンシャルテンプレートを作成・更新できる人なら、プロジェクト単位の権限でも攻撃できます。

CVE-2025-61560は、ログイン失敗回数の制限が同時に送った要求では数えきれず、パスワードの総当たりが通りやすくなる問題です。対象はローカルアカウントのパスワードログインで、SSOだけでログインさせている環境は影響を受けません。

トークンやAPIキーが漏れる過去の脆弱性CVE-2025-55190と42880

「Argo CDにトークンやAPIキー漏洩の可能性がある深刻な脆弱性」と報じられたのは、2026年5月のCVE-2026-42880です。前年9月のCVE-2025-55190も、認証情報の漏洩としてよく検索されます。どちらも修正済みですが、版が古いまま残っている環境は今も該当します。

プロジェクト用APIトークンで認証情報が返るCVE-2025-55190の中身

GHSA-786q-9hcg-v9ff（2025年9月4日公開・CVSS 9.9）は、プロジェクトの get 権限を持つAPIトークンで /api/v1/projects/{project}/detailed を呼ぶと、リポジトリのユーザー名とパスワードが応答に含まれる問題でした。Secretを読む権限を与えていない、同期用の自動化トークンでも取れてしまいます。

修正版は3.1.2・3.0.14・2.14.16・2.13.9です。CIから同期を叩くためにプロジェクトトークンを配っていた環境では、更新に加えて、そのトークンで取れたリポジトリの認証情報を作り直すところまでが対応になります。

ServerSideDiffでSecretが漏れるCVE-2026-42880の条件

GHSA-3v3m-wc6v-x4x3（CVSS 9.6）は、差分表示に使うServerSideDiffの応答だけSecretのマスクが抜けていた問題です。読み取り権限だけの利用者が、サービスアカウントのトークン、TLS証明書、DBの認証情報、APIキーを平文で取り出せました。

条件は2つです。Applicationに argocd.argoproj.io/compare-options: IncludeMutationWebhook=true の注釈が付いていること。もう1つは、そのSecretのdataをArgo CD以外のフィールドマネージャーも所有していることです。影響は3.2.0〜3.3.8で、3.3.9と3.2.11で修正されました。

この修正は不完全で、続報のCVE-2026-45737（CVSS 6.3）が5月13日に出ています。last-applied-configuration 注釈に残ったSecretの値が差分に出る問題で、修正版は3.2.12・3.3.10・3.4.2です。5月の時点で3.3.9止まりの環境は、まだ塞ぎ切れていません。

自分のArgo CDが影響を受けるかを確かめるバージョンと設定の確認手順

ここからは手を動かす部分です。kubectl でargocd名前空間を読める端末があれば、どれも数分で確認できます。

argocd versionとイメージタグで稼働中の版番号を特定する手順

CLIの版とサーバーの版は別物なので、両方の確認が必要です。argocd version はログイン済みならサーバー側の版も表示します。CLIが手元に無い場合は、Deploymentのイメージタグを直接読みます。

# CLIとAPIサーバーの版を表示する
argocd version

# CLIが無い場合：各コンポーネントのイメージタグを読む
kubectl -n argocd get deploy,statefulset \
  -o custom-columns=NAME:.metadata.name,IMAGE:.spec.template.spec.containers[0].image

出てきた版を先ほどの表と照らします。3.3.15・3.4.10・3.5.4より前なら10月7日公表分に該当します。2.x系や3.2以下が表示された場合は、修正版が存在しないので後述のマイナー版アップグレードが必要です。

argocd-cmとリポジトリSecretから攻撃条件の有無を洗い出すコマンド

版が古いと分かったら、次は攻撃の条件が揃っているかを見ます。回避策をどこまで効かせられるかが、ここで決まります。

# --enable-helm や Jsonnet 無効化の有無を見る
kubectl -n argocd get configmap argocd-cm -o yaml \
  | grep -E "kustomize.buildOptions|jsonnet.enable|admin.enabled"

# proxy を設定したリポジトリ・クレデンシャルテンプレートを探す
kubectl -n argocd get secret \
  -l "argocd.argoproj.io/secret-type in (repository,repo-creds)" \
  -o jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.data.proxy}{'\n'}{end}"

# IncludeMutationWebhook を付けた Application を探す
kubectl get applications -A -o yaml | grep -n "IncludeMutationWebhook=true"

2つ目のコマンドで値が出たリポジトリのうち、URLがSSHのものがCVE-2026-55797の対象です。値はbase64なので base64 -d で戻して中身を確かめます。身に覚えのないproxyの値があれば、すでに悪用されている可能性を疑ってください。

修正版へ上げられないときの暫定回避策をargocd-cmで設定する方法

アドバイザリには、項目ごとに回避策（Workarounds）が書かれています。ただし8件すべてを設定だけで塞ぐことはできません。設定で塞げる2件と、権限で被害を減らすしかない残りに分けて考えます。

–enable-helm削除とjsonnet.enable無効化で塞げる範囲と副作用

Helm経由の件は、kustomize.buildOptions から --enable-helm を外せば完全に塞がると明記されています。Jsonnetの件は、Tool Detectionのドキュメントにある jsonnet.enable を "false" にすると、.jsonnet ファイルが処理されなくなります。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  # kustomize.buildOptions から --enable-helm を外す（行ごと削除してもよい）
  kustomize.buildOptions: ""
  # Jsonnet を使っていなければ無効化する
  jsonnet.enable: "false"

設定変更に伴う副作用も確認が必要です。Kustomizeの helmCharts でHelmチャートを描画しているApplicationは、--enable-helm を外すと生成に失敗します。Jsonnetを無効にした場合は、.jsonnet のファイルが黙って無視され、エラーにならずに同期が通ってしまいます。適用前に、対象になるApplicationを洗い出してください。kustomize.buildOptions の変更後は、KustomizeのドキュメントのとおりArgo CDの再起動が必要になる場合があります。Helm自体の仕組みはHelmとは？チャート・リポジトリ・リリースの基本を参照してください。

回避策が無い3件に対する権限の絞り込みとadmin無効化の設定

Kustomizeのref指定（GHSA-9v9p）は「アップグレード以外に完全な回避策は無い」とアドバイザリに書かれています。削除フックの件とSSH proxyの件も、設定で塞ぐ方法がありません。この3件は、攻撃者になりうる人の数を減らす方向で手を打ちます。

• 信頼できない利用者に、Applicationの参照先Gitへの書き込み権限を渡さない
• Applicationの削除権限を持つ人を絞る（削除フックは削除操作で動く）
• リポジトリの作成・更新権限を、プロジェクト単位のものも含めて棚卸しする
• application-controllerのクラスター権限を、使う名前空間とAPIに狭める

RBACの考え方はRBACとは？ロールベースアクセス制御の仕組みで整理しています。ログイン制限回避のCVE-2025-61560には、User Managementのドキュメントにある admin.enabled: "false" でadminアカウントを止め、SSOに寄せる方法が案内されています。

パッチ版とマイナー版で分けるArgo CDアップグレード手順と順番

回避策はあくまで時間稼ぎです。本命は修正版への更新で、同じマイナー版の中か、マイナー版をまたぐかで手間がまったく違います。

同じマイナー内のパッチ更新をserver-side applyで行う手順

Upgradingの概要ページは、パッチ版の更新に破壊的変更は無いとしています。イメージだけを差し替えず、マニフェスト一式を適用し直す方法が推奨です。CRDのサイズ制限があるため --server-side --force-conflicts が必須になります。

# 例：3.5系を 3.5.5 へ（HA構成は manifests/ha/install.yaml）
ARGOCD_VERSION="v3.5.5"
kubectl apply -n argocd --server-side --force-conflicts \
  -f "https://raw.githubusercontent.com/argoproj/argo-cd/${ARGOCD_VERSION}/manifests/install.yaml"

# ロールアウト完了を待ってから版を確かめる
kubectl -n argocd rollout status deploy/argocd-server
argocd version

Helmチャートで入れた環境は、チャートの版を上げて helm upgrade で同じことをします。マニフェストを手で改変している場合は、Kustomizeのパッチとして切り出してから当てると、次回以降の更新が楽になります。

サポート外の2.xと3.0〜3.2から3.3以降へ段階的に上げる判断

SECURITY.mdは、直近3つのマイナー版をサポート対象としています。2026年10月時点では3.3・3.4・3.5で、3.6はリリース候補（10月15日にrc3）の段階です。3.6が正式版になれば、方針どおりなら3.3がサポートから外れます。

2.x系や3.0〜3.2系からは、マイナー版を1段ずつ上げ、各段のアップグレードガイドを読むのが公式の手順です。2.14から3.0の段には大きな変更が入っているので、検証環境で一度通してから本番に当ててください。上げる先は3.3ではなく3.4か3.5にしておくと、3.6の正式版が出た直後にサポート外へ落ちる事態を避けられます。

Argo CDの脆弱性を運用で追い続ける体制と外部に任せる判断基準

最後に、今回のような一斉公表を次に受けたとき、慌てずに済む体制を言い切ります。

Security Advisoriesを監視して公表から3営業日で判定する運用

Argo CDの脆弱性は、まずGitHubのSecurity Advisoriesに出ます。CVE番号の付与やNVDへの反映は後から追いかけるため、CVE番号だけを見ていると数日から数週間遅れます。今回もCriticalの3件は、公表時点でCVE番号がありませんでした。

運用の型は単純で十分です。リポジトリのReleasesをWatchしておき、公表から3営業日以内に「自社の版が該当するか」「攻撃条件が揃っているか」の2点だけを判定します。この記事で挙げた確認コマンドを手順書に入れておけば、判定は担当者1人で終わります。

多テナント運用でGit書き込み権限を広く配る構成は見送るべき理由

見送るべき構成もはっきりしています。1つのArgo CDに複数の事業部や協力会社を相乗りさせ、各チームにGitの書き込み権限とApplicationの削除権限を渡す構成です。今回の削除フックの件のように、AppProjectの境界は不具合1つで越えられます。テナント間を本当に分けたいなら、Argo CDのインスタンスかクラスターを分けるほうが確実です。

パッチの適用が年に数回しか回らない体制なら、Argo CDを持つこと自体を見直す時期です。GitOpsの運用モデルはGitOpsとは：4原則とPush型との違いで、CI/CD経路が狙われた事例はtj-actions/changed-files侵害の経緯と再発防止で扱っています。Argo CDの更新手順の整備や権限設計の見直しを外部に任せる場合は、DevOps・CI/CD導入支援で現状の構成確認から相談を受けています。

よくある質問

Argo CDの脆弱性対応でよく出る疑問に、各アドバイザリと公式ドキュメントの記述をもとに答えます。

Argo CDの最新の修正版はどれですか？

2026年10月19日時点では、3.5系が3.5.5、3.4系が3.4.11、3.3系が3.3.16で、いずれも10月12日に出ています。10月7日公表の8件は、その1つ前の3.5.4・3.4.10・3.3.15で修正済みです。12日の版はバグ修正の位置づけなので、これから上げるなら各系列の最新を選べば足ります。3.6系はまだリリース候補で、本番での利用は正式版を待つのが無難です。

Argo CDを社外に公開していなければ対応は不要ですか？

不要とは言えません。今回の8件の多くは、Argo CDにログインできる利用者や、Gitへ書き込める開発者が、想定されている攻撃者です。社内ネットワークに閉じていても、権限を持つ人のアカウントが乗っ取られれば同じことが起きます。ログイン制限回避のCVE-2025-61560だけは認証が要らない攻撃で、ネットワークでの到達制限が被害を減らす手段になります。

トークンや認証情報が漏れたかどうかはどう確かめますか？

Argo CDのAPIサーバーのアクセスログで、問題のエンドポイントへの呼び出しを確認します。CVE-2025-55190なら /api/v1/projects/{project}/detailed、10月の件なら manifestsWithFiles への要求が手がかりになります。痕跡の有無が判断できない場合は、漏れたと仮定して、Gitやレジストリの認証情報とAPIトークンを作り直すのが確実です。

2.x系のArgo CDにセキュリティ修正は出ますか？

出ません。10月7日公表分のアドバイザリには、2.x系と3.0〜3.2系はサポート外でパッチを出さないと明記されています。SECURITY.mdでも、サポート対象は直近3つのマイナー版です。2.x系を使い続ける場合は、回避策と権限の絞り込みで当面をしのぎつつ、3.4以降へのアップグレード計画を立てる必要があります。

脆弱性スキャナーの結果とArgo CDのアドバイザリはどう使い分けますか？

Argo CD本体の脆弱性は、GitHubのアドバイザリを正とするのが確実です。SECURITY.mdでは、コンテナイメージのスキャン結果には誤検知が多いと注意されています。逆に、今回のCVE番号の無いCritical3件のように、スキャナーでは拾えない項目も確認対象です。スキャナーはOSパッケージや依存ライブラリの確認に使い、本体の判定はアドバイザリで行うと役割が分かれます。

関連記事

• ArgoCDとは？GitOpsの仕組みとインストール・Sync設定をコード付きで解説：Argo CDの構成要素とインストール手順の基本
• GitOpsとは：4原則とPush型との違い、Argo CD・Fluxの最小構成YAML：Gitへの書き込み権限が配信権限になる運用モデル
• CVSSv3とは？v3.1の計算式・スコアの目安と3つの評価基準を解説：9.9や9.6というスコアの読み方
• RBACとは？ロールベースアクセス制御の仕組みと導入判断を実装視点で解説：回避策の中心になる権限設計の考え方
• tj-actions/changed-files侵害（CVE-2025-30066）の経緯・影響確認・再発防止：CI/CD経路が狙われたサプライチェーン攻撃の事例