ZammadのCVE-2026-102489と102490がKEV入り。DIVDを侵害したゼロデイ連鎖と、ベンダーとの見解の食い違い

2026年10月2日、CISAはオープンソースのヘルプデスクシステムZammadの脆弱性2件、CVE-2026-102489とCVE-2026-102490をKnown Exploited Vulnerabilities Catalog(KEVカタログ)に追加しました。前者はセッション固定(セッションの乗っ取り)からzammadユーザーの権限でのコード実行に至る欠陥、後者はそのzammadユーザーがrootへ権限を引き上げられる欠陥です。2件はオランダの脆弱性開示組織DIVD(Dutch Institute for Vulnerability Disclosure)が、自組織への侵害を調べる過程で特定しました。DIVDは、攻撃がAIエージェントによって自動で進められ、zammadユーザーからrootへの昇格が数秒で行われたと報告しています。

一方でZammadは、CVE-2026-102489が悪用できるのはサポートの終わった6.5以前だけで7.0以降は影響を受けないと強調し(7.0以降で悪用できない点はDIVDも認めています)、CVE-2026-102490については公表の時点で技術的な詳細を受け取っていなかったと表明しました。102490の影響範囲や修正版の情報は、両者の間でも報道の間でも食い違っています。この記事は、CISA、DIVD、Zammad、NVDの一次情報で確認できた内容に限って整理し、両者の主張が異なる点は並べて示します。記述は執筆時点(2026年10月8日)の情報に基づき、攻撃の再現手順は扱いません。

KEVカタログに記録された内容#

CISAが配布するKEVカタログのJSONフィード(執筆時点で確認したカタログバージョン2026.10.04)に記録された値です。

CVE-2026-102489のshortDescriptionは「contains a session fixation vulnerability that can lead to remote code execution as the zammad user. This vulnerability can be chained with CVE-2026-102490.」、CVE-2026-102490は「can allow the local zammad user to escalate privileges to root. This vulnerability can be chained with CVE-2026-102489.」です。notesには、Zammadのリリース一覧とコミュニティのスレッドが参照先として載っています。

期限の10月5日は追加から3日後です。requiredActionは、ベンダーの指示に沿った対処に加えて、BOD 26-04の指針とCISAの「Forensics Triage Requirements」に従うよう求めています。forensicTriageがYesであることは、パッチを当てるだけでなく、適用前に侵害されていなかったかを確かめる対象として扱われていることを示します。CISAはアラートで、BOD 26-04がパッチ適用前の侵害の有無をいつ確かめるべきかの基本的な期待値を定めていると説明しています。ただし、この期限と確認の義務を負うのは米国連邦政府の行政機関で、日本の民間組織に義務はありません。CISAはすべての組織に、KEVの脆弱性を優先して直すよう勧めています。

NVDには、CISAが付けたSSVCの評価も載っています。2件とも悪用状況(Exploitation)はactive、技術的な影響(Technical Impact)はtotalです。自動化のしやすさ(Automatable)は、外から狙える102489がyes、サーバー上の足場を前提とする102490がnoです。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

侵害の発覚からKEV追加までの時系列#

DIVDのケースページ2件、Zammadの声明とアドバイザリ、CISA、NVDで確認できた日付を並べます。

開示の進め方についても両者の見方は異なります。Zammadは声明で、9月24日の報告から2日後の9月26日にスキャンと公開が行われ、技術的な詳細を受け取る前に102490のCVE番号が公開されたとして、責任ある進め方ではないと述べています。DIVDは、悪用が確認された2件について標的と被害者への通知を行うためにDIVD-2026-00015を立ち上げたと説明しています。Zammadの批判に対するDIVDの反論は、執筆時点で確認できていません。

影響を受けるバージョンをめぐる食い違い#

情報源ごとに、影響範囲の記述が次のように異なります。

102489については、DIVDもNVDも7.0以降は悪用できないとしており、ここは三者でおおむね一致しています。差があるのは、7系にも欠陥のコード自体が残っていたかどうかの扱いと、上限が7.1.2か7.1.3かという細部です。悪用可能範囲の上限にも揺れがあり、DIVDのCVEレコードの構造化データは「6.3.0以上6.5.4未満」、ケースページの文章とNVDのCPEは6.5.4を含む表記です。6.5.4を安全な版とはみなさず、6系はすべて更新の対象として扱います。食い違いが大きいのは102490で、DIVDは1.5.0以降のほぼ全バージョンを挙げ、Zammadは影響範囲を確定した数字をまだ示していません。

修正版についても、一部の報道は7.2.0への更新で2件とも解決するかのように伝えていますが、一次情報で確認できるのは、Zammadが102489に関するコードの強化を7.2.0に含めたと説明していることまでです。102490の修正は、10月6日の7.2.1のリリースノートにも、GitHubのセキュリティアドバイザリにも、執筆時点では載っていません。

Zammadのアドバイザリは102490について「This issue is related to a confirmed vulnerability in packager.io, and our team is working on a solution.」と記しています。packager.ioはLinux向けのdebやrpmのパッケージを作成し配布するサービスです。どのインストール方式が影響を受けるのかは、執筆時点で公表されていません。

なお、NVDが付けたCVSS v3.1の基本値は2件とも9.8(AV:N/AC:L/PR:N/UI:N)です。DIVDは自らのCVEページで、CVSS v4.0の基本値を単独では102489が8.7、102490が8.5、互いに連鎖させた場合は9.4と示しています。ローカル権限昇格と説明される102490にもネットワーク経由の評価が付いていますが、評価の根拠は公開されていません。単独の深刻度を比べるより、連鎖した場合に外部からrootまで届くという組み合わせで捉えるほうが、KEVの記述とも合います。

2つの欠陥がつながると何が起きるか#

セッション固定(CWE-384)は、攻撃者が知っているセッション識別子を正規の利用者に使わせたり、認証の前後でセッション識別子が切り替わらなかったりすることで、攻撃者がそのセッションを自分のものとして使えてしまう欠陥の類型です。MITREは、既存のセッション識別子を無効にしないまま利用者を認証したり新しいセッションを確立したりすると、攻撃者に認証済みのセッションを盗む機会を与えると説明しています。DIVDは102489を「session hijack」と表現しており、乗っ取ったセッションからzammadユーザーとしてコードを実行できるところまで進むとしています。どの画面や処理で識別子が扱われるのかは公開されていません。

102490は、Zammadのアプリケーションを動かすzammadユーザーが、そこからrootへ権限を引き上げられる欠陥です(CWE-269)。Zammadが強調するとおり、これ単独ではサーバー上にすでに足場があることが前提です。しかし、102489がちょうどその足場を外から与えるため、2件をつなげると、インターネットに公開されたZammadからサーバーの全権まで届きます。MITRE ATT&CKでは、後段はT1068(Exploitation for Privilege Escalation)にあたります。

ヘルプデスクのサーバーでrootを取られると、影響はチケットの中身にとどまりません。Zammadには、問い合わせメールを受けるためのIMAPやSMTPの認証情報、Microsoft 365やGoogleとのOAuth連携、社員アカウントを取り込むLDAPの接続アカウント、外部サービスとの連携トークンなどが登録されています。サーバー上にはデータベースや検索エンジンへの接続情報もあります。DIVDも、侵入後に攻撃者が他のサービスにアクセスしデータを持ち出せる状態になったと説明しています。

あわせて読みたい

セッション管理とセッションハイジャック対策。Cookie属性とセッションID再生成で不正利用を防ぐ設計

ローカル権限昇格が一般にどのような仕組みで起き、どう防ぐかは別の記事で整理しています。

あわせて読みたい

Linuxで一般ユーザーがrootを奪う典型経路と、SUIDやsudoersの棚卸しから始める防御策

AIエージェントによる攻撃が示したこと#

DIVDの説明は段階的に更新されています。9月24日の最初の声明では、手口から見てエージェント型のAIによる攻撃だと判断したと述べました。9月26日には、攻撃者のスクリプトに、エージェントが自らの行動を正当化する注記が残っていたとして、伏せ字を入れたログの画像を示しています。9月29日には、攻撃は騒がしく雑で、エージェントが自動で次の手を決めながら高速に進めたと説明しました。9月30日の声明が、2件のゼロデイによってzammadユーザーからrootまでの昇格が「in seconds」で行われたと述べた箇所です。

これらはDIVDが観測した挙動から下した評価で、攻撃者の特定には至っていません。DIVDは、既知の攻撃グループとのつながりは見つかっていないと述べています。被害は、ネットワークを分離していたことと検知後の対応によって、それ以上の深部への侵入を防げたとしつつ、ボランティアのDIVDのメールアドレスや連絡先の一部が流出したことを10月1日に公表しました。

防御側にとっての意味は、手作業を前提にした猶予が当てにできなくなるという点に尽きます。脆弱な公開サーバーが見つかってから侵入、権限昇格、横展開までを人が一つずつ進めるなら、検知や遮断が間に合う余地があります。各段階を自動で数秒から数分でこなされると、侵入された後に気づいて止めるより、公開範囲を絞って入口に届かせないこと、更新を当日中に当てられる手順を持っておくことの比重が上がります。今回の事例は、発見者自身が被害者で、ベンダーへの報告より前に悪用が起きていたゼロデイです。パッチの有無にかかわらず、公開範囲とネットワークの分離が被害の広がりを左右しました。

あわせて読みたい

攻撃者が生成AIを道具に使う手口と怪しい兆候の見分け方

管理者が進める対応#

修正の状況が確定していない102490があるため、更新だけで終わらせず、公開範囲の見直しと侵害の確認を並行して進めます。

あわせて読みたい

最小権限の原則（Least Privilege）。なぜ権限を絞ることが最強の防御の一つなのか

侵害の痕跡を確かめる#

DIVDは、CVE-2026-102489に関するIoCとして、Zammadとnginxのログを調べるシェルスクリプトを公開しています。既定では/var/log/zammadと/var/log/nginxを対象に、Zammadのエラー出力にセッション情報が含まれていないかを確かめます。スクリプト自身が、該当がなくても不審なプロセスやファイルなど他の兆候を調べるよう注記しているとおり、検出がないことは安全の証明になりません。外部から入手したスクリプトは、実行前に中身を読み、対象のサーバーで実行してよいかを確かめてから使います。

ログ以外には、次の点を確認します。

• Zammadの管理画面で、見覚えのない管理者アカウントや権限の変更、追加されたトリガーやWebhookがないか(7.2以降は管理者の変更を記録する監査ログも確認できます)
• zammadユーザーで動くプロセスや、その所有で最近作られたファイルに、Zammad本体と関係のないものがないか
• rootのcrontab、systemdのユニット、SSHのauthorized_keysなど、永続化に使われやすい場所に覚えのない変更がないか
• Zammadのサーバーから外部への見慣れない通信や、社内の他のサーバーへの接続が記録されていないか

rootでの侵害が疑われる場合、そのサーバー上の痕跡は改ざんされている可能性があります。痕跡が見つかった、または否定しきれない場合は、そのホストを修復して使い続けるより、隔離したうえで新しいサーバーを構築し、データを移す方針を検討します。日本国内でインシデントの相談先が必要な場合は、JPCERT/CCのインシデント対応依頼の窓口を使えます。

あわせて読みたい

インシデント発生時の初動対応。最初の1時間で何をするか

セッションと連携シークレットを入れ替える#

102489はセッションの乗っ取りを起点とするため、更新後もすでに奪われたセッションが残っていれば使われ続けるおそれがあります。管理画面の「セッション」では現在のセッションの一覧を確認でき、個別に終了できます。全員を一度ログアウトさせたうえで、エージェントと管理者のパスワードを変更し、利用者ごとのアクセストークンも作り直します。「セキュリティ」の基本設定にあるセッションタイムアウトが長すぎないかも見直します。

侵害を否定できない場合は、Zammadに預けている外部の認証情報もすべて入れ替えの対象です。

7.2.1で修正された脆弱性の中には、チャネルの管理APIが保存された認証情報を平文で返すというものもありました。Zammadに登録したシークレットは、Zammadが侵害されたら漏れたものとみなす前提で、変更の手順と担当者をあらかじめ決めておきます。

あわせて読みたい

シークレット管理の実務。APIキー・認証情報をハードコードせず、Vaultやマネージドサービスで守りローテーションする

まとめ#

Zammadの2件は、外部から届くセッションの欠陥と、サーバー内での権限昇格がつながることで、公開されたヘルプデスクからrootまで到達できるという組み合わせの問題です。影響範囲と修正の状況について、発見者のDIVDとベンダーのZammadの見解は執筆時点でも一致しておらず、102490の修正版はまだ告知されていません。確実に言えるのは、6.5以前は直ちに更新すべきこと、7系も最新の7.2.1へ上げるべきこと、そして修正の確定を待つ間は公開範囲を絞り、侵害の確認と資格情報の入れ替えを進めておくべきことです。痕跡の確認やスクリプトの実行は、自組織が管理するサーバーに限って行ってください。

この記事は2026年10月8日時点の情報に基づいています。102490の修正版や影響範囲は今後更新される可能性があるため、Zammadの公式アドバイザリとGitHubのセキュリティアドバイザリ、DIVDのケースページで最新の情報を確認してください。