【ITニュース解説】Zammad packages ran as root and executed files the service account could write

システム開発の現場で利用される「Zammad」というツールで発見された、ある重要な脆弱性について解説する。この脆弱性は「ローカル権限昇格」と呼ばれる種類のものであり、システムエンジニアを目指す皆さんにとって、システムのセキュリティ設計や運用において非常に重要な教訓となる。

まず、Zammadとは顧客からの問い合わせを管理する「チケットシステム」と呼ばれるアプリケーションの一つである。今回問題となったのは、CVE-2026-102490という識別番号がつけられた脆弱性だ。これは、同じコンピュータの内部で、低い権限のユーザーが、システム内で最も高い権限である「root（ルート）」権限を不正に取得できてしまう、という性質を持つ。このような攻撃は「ローカル権限昇格」と呼ばれ、一度成功すると、攻撃者はそのコンピュータ上でほぼ何でも実行できるようになり、非常に危険性が高い。この脆弱性の深刻度は、共通脆弱性評価システムであるCVSS 3.1のベーススコアで7.8と評価されており、機密性、完全性、可用性の全てに大きな影響を及ぼす可能性が指摘されている。実際にこの脆弱性は悪用された事例も報告され、CISA（米国サイバーセキュリティ・インフラセキュリティ庁）の既知の悪用された脆弱性リストにも追加されている。

この問題は、Zammadの「パッケージ版」、特にDebian系のDEB形式やRed Hat系のRPM形式で提供されているバージョンで発生した。具体的に何が問題だったのか。Zammadのサービスを起動する際、プログラムは一時的に「root」という最高権限で起動する。これは、システムの一部にアクセスしたり、特定の設定を読み込んだりするために必要な場合があるからだ。しかし、このroot権限を持つプロセスが、本来のZammadサービスを動かすために用意された、より権限の低い「zammad」という専用のユーザーアカウント（これを「サービスアカウント」と呼ぶ）に権限を降ろす前に、ある危険な行動をとっていた。

その危険な行動とは、root権限のままで、これからzammadアカウントで実行する予定のプログラムや設定ファイルなどを読み込み、実行していたことである。ここでの決定的な問題点は、これらのファイルが「zammad」サービスアカウントの権限で所有されており、かつ「zammad」アカウントから書き込み可能な状態にあったことだ。つまり、もし攻撃者がすでに何らかの方法で「zammad」サービスアカウントと同等のファイルシステムへの書き込み権限を手に入れていた場合、root権限で実行されるはずのファイルの内容を、自分の好きなように書き換えることができた。そして、Zammadサービスが次に再起動する際、システムはroot権限で、攻撃者が仕込んだ悪意のあるコードを実行してしまう、という流れである。これにより、低い権限しか持たない攻撃者が、システム全体の最高権限であるroot権限を簡単に手に入れることが可能になってしまう。

さらにこの脆弱性の深刻度を増す要因が二つあった。一つは、Zammadのサービスが何らかの原因で停止した場合、自動的に再起動する設定になっていたことだ。これにより、一度攻撃者が悪意のあるコードを仕込んでしまえば、管理者が特別な操作をしなくても、サービスが再起動するたびに攻撃者のコードがroot権限で繰り返し実行されてしまう可能性があった。もう一つは、この権限昇格がサービス起動シーケンスの非常に早い段階で発生するため、攻撃が数秒という短時間で完了してしまうことだ。

一方で、Zammadをソースコードから直接インストールした場合や、Dockerなどの「コンテナ」技術を使って公式のコンテナイメージから運用していた場合は、この脆弱性の影響を受けなかった。なぜコンテナ版が安全だったのかというと、コンテナのプロセスモデルでは、サービスを起動する際に最初からroot権限で起動し、その後、権限を低いユーザーに降ろす、という複雑な手順を必ずしも必要としないからである。パッケージ版は、かつて一般的だったシステム起動のパターンを踏襲していたために、このような脆弱性が入り込む余地があったのだ。このことは、アプリケーションの「パッケージング（配布形態）」がいかにセキュリティに影響を与えるか、という重要な教訓を示している。

システム管理者やエンジニアは、この問題に対してどのような対策をとるべきか。まず第一に、Zammadのベンダーが提供しているセキュリティアドバイザリを確認し、修正済みの新しいパッケージバージョンに速やかにアップデートする必要がある。その上で、実際にシステムが起動する際に、どのようなファイルが実行されているかを具体的に確認することが重要だ。単に設定ファイルに書かれている内容だけでなく、実際にプロセスがどのようなパスをたどって起動しているのか、そしてそのパスにあるファイルが「zammad」ユーザーによって書き込み可能になっていないか、といった点を詳細に監査することが求められる。具体的には、アプリケーションがインストールされているディレクトリや、サービス起動時に環境変数を読み込むためのファイル、あるいはパッケージがインストールする補助的なスクリプトの中に、zammadユーザーが書き込み可能なファイルや、誰もが書き込み可能な「world-writable」なファイルが存在しないかを確認するべきだ。特に、システムの起動シーケンスで実行されるにもかかわらず、アプリケーション自身が内容を書き換えられるようなファイルは、警戒すべき対象となる。

また、サービスの自動再起動ポリシーについても見直す必要がある。通常、自動再起動はシステムの可用性を高める便利な機能だが、今回のような起動シーケンス中に脆弱性がある場合、それは攻撃を助長する要因となってしまう。もしシステムに侵害の兆候が見られる場合は、調査期間中に一時的に自動再起動を無効にすることも検討すべきである。

今回の脆弱性は、Zammadというチケットシステムで発生したことに、さらに大きな意味がある。Zammadは顧客からのメール本文、添付ファイル、そしてそれらに紐づくアカウント情報といった、非常に機密性の高いデータを扱う。もし攻撃者がZammadが稼働するサーバーのroot権限を奪うことに成功すれば、アプリケーションがデータベースに接続するための認証情報、ユーザーのセッションを管理する秘密鍵、ファイルストアに保存されたデータなど、あらゆる機密情報にアクセスできるようになる。

もしZammadサービスアカウントの下で不審な活動の痕跡が見つかった場合、すでに権限昇格攻撃が成功し、目に見える証拠が消されている可能性もある。このような場合、攻撃の痕跡を特定するためには、ファイルが作成された時間と、root権限を持つプロセスが起動した時間との間に不自然な関連性がないか、というタイミングの分析が非常に重要となる。一般的なアプリケーションのログだけでは、このような微妙なタイミングのずれを捕捉するのは難しい。そのため、可能であれば、ファイルシステムへのアクセス履歴を詳細に記録する「ファイルシステム監査ルール」を事前に設定しておくことが、今回の脆弱性のような攻撃を検知し、分析する上で非常に有効な手段となる。

今回のZammadの脆弱性から得られる最も重要な教訓は、「特権降下（privilege drop）」というセキュリティメカニズムが、「単なる状態」ではなく「一連の厳密な手順（シーケンス）」である、という点だ。高い権限（root）で起動したプロセスが、その後の処理で低い権限のユーザーに切り替える際、権限を降下させる前に触れる全てのファイルに対して、極めて慎重に扱う必要がある。この「規律」が欠けている場合、脆弱性が生まれるのはアプリケーションそのものではなく、プログラムが実行され（exec）、ユーザーIDが変更される（setuid）までの、ごく短い間の「瞬間」に存在する。

CVE-2026-102490には既に修正プログラムが提供されており、パッケージ版を利用している組織は速やかに適用すべきである。また、コンテナやソースコードからのインストールで運用している場合も、「私たちは影響を受けない」という安易な結論に留まらず、なぜ影響を受けないのか、そのアーキテクチャが本当に安全な設計に基づいているのかを確認することが重要である。システムの起動パスは時間の経過とともに変更される可能性があり、常にその安全性について意識し続ける必要がある。