問い合わせ管理OTRSに侵入の脆弱性 CVE-2026-48188、特定設定なら無認証

問い合わせ管理システムOTRSに、ログインしていない相手でも外から侵入できる脆弱性CVE-2026-48188（10点満点中9.1の「Critical」）が見つかりました。OTRSは、顧客や社員からの問い合わせをチケットとして受け付け、対応状況を管理するヘルプデスク向けのソフトです。今回の欠陥を突かれると、ログイン情報を一切持たない相手が、外部のネットワークから本人になりすまして中に入り込めてしまう状態になります。

ただし、影響を受けるかどうかには明確な発動条件があります。データベースにMySQLまたはMariaDBを使い、その設定が NO_BACKSLASH_ESCAPES という特定モードになっている場合にのみ影響します。この条件に当てはまらない構成は、影響を受けません。自分の環境が該当するかどうかをまず判定できることが、本件で最も重要なポイントです。

影響するのは OTRS の 7.0.X / 8.0.X / 2023.X / 2024.X / 2025.X、および 2026.4.X より前の 2026.X、加えて無償だった OTRS Community Edition 6.0.x とその派生製品です。修正版は OTRS 2026.4.X 以降。一次情報は、ベンダーOTRS AGが公開したOTRSセキュリティアドバイザリ 2026-02です。

OTRSとは何か

OTRS（Open Ticket Request System）は、社内外からの問い合わせを1件ずつ「チケット」として記録し、誰が・いつ・どう対応したかを追えるようにする問い合わせ管理システムです。カスタマーサポート窓口、社内のITヘルプデスク、ITサービス管理（ITSM。情報システム部門の運用業務を仕組み化する考え方）の現場で広く使われてきました。提供元はドイツのOTRS AGで、現在は商用版を中心に展開しています。

かつては無償の OTRS Community Editionが広く普及していましたが、こちらは開発が終了しました。その後継として、コミュニティが分岐させたZnunyというフォーク（派生版）が後を引き継いでいます。今回の脆弱性は、商用のOTRSだけでなく、保守の止まった Community Edition 6.0.x やそれをベースにした製品も対象に含んでいるため、無償版を今も自前で動かしている組織が最も危険な立場に置かれます。

自分の環境は該当するのか（判定の流れ）

本件は「動かしていれば全員アウト」ではなく、データベースの設定しだいです。次の2つを順に確認すれば、自社が危険かどうかを切り分けられます。

1つ目は、データベースのSQLモードの確認です。 OTRSがMySQLまたはMariaDBで動いている場合、データベースに対して SELECT @@sql_mode; というコマンドを実行します。返ってきた文字列の中に NO_BACKSLASH_ESCAPES が含まれていれば、影響を受ける条件に当てはまります。含まれていなければ、この脆弱性の影響は受けません（PostgreSQLなど他のデータベースを使っている場合も同様に対象外です）。

2つ目は、バージョンの確認です。 上のSQLモードに該当したうえで、OTRSが 7.0.X / 8.0.X / 2023.X / 2024.X / 2025.X、または 2026.4.X より前の 2026.X、もしくは Community Edition 6.0.x（およびその派生）であれば、影響を受けます。OTRS 2026.4.X 以降に更新済みであれば、SQLモードに関係なく修正されています。下の早見表で、エディションとSQLモードの組み合わせごとの判定をまとめています。

問い合わせ箱の鍵が、外から手探りで開けられる

この脆弱性が際立って危ないのは、悪用にログインも会員登録も要らず、外から無認証で踏める点です。狙ってくるのは脆弱なサポート窓口を自動で探し回る攻撃者、顧客名簿や問い合わせ履歴を欲しがる競合や名簿屋、顧客になりすまして金銭をだます詐欺グループ、サポート対象企業を本命に狙う第三者です。チケット管理システムには、問い合わせてきた人の氏名・メール・電話番号、添付書類、担当者の対応メモ、ときには初期パスワードや契約内容まで溜まっています。該当環境でこの欠陥を踏まれた瞬間、正規の担当者に成りすまされ、溜め込んだチケットの中身がそっくり抜かれてしまいます。

抜かれた先の被害は連鎖します。問い合わせ履歴に並ぶ個人情報は、まとめて名簿として売りさばかれます。次に、その情報を使って「先日のお問い合わせの件で」と本物の文面を真似たサポート窓口なりすましのフィッシングが送られ、受け取った顧客はつい返信してしまいます。聞き出したログイン情報は、別サービスの乗っ取りや、サポート対象企業の社内システムへの侵入の足がかりに使われます。

そして責任は、OTRSを運用する企業やサポート部門に返ってきます。預かった問い合わせ内容が漏れれば、本人への通知や個人情報保護委員会への報告が必要になり、被害者対応や賠償の負担が生じます。何より、サポート窓口は「困ったときに連絡する場所」であり、そこから情報が漏れた事実は、顧客の信用そのものを崩します。この代償を負わずに済むかは、いま発動条件を確認して手を打てるかにかかっています。

CVE-2026-48188：無認証SQLインジェクションから認証回避まで

問題は、OTRSのデータベース層モジュール（データベースとのやり取りを担う共通部品）にある不適切な入力検証（CWE-20）です。外部から受け取った文字列の扱いが甘く、ここに細工した文字列を送り込むと、本来意図しないデータベース命令がそのまま実行されてしまいます。

SQLインジェクションとは、入力欄や画面操作を通じて、本来は許されていないデータベース命令（SQL文）をこっそり紛れ込ませる古典的な攻撃手法です（脆弱性の分類ではCWE-89）。通常はこうした攻撃を防ぐため、入力に含まれる特殊な記号の前に「これは命令ではなく文字です」という印としてバックスラッシュ（\）を付けて無害化します。ところが、データベースが NO_BACKSLASH_ESCAPES モードのときは、このバックスラッシュを「ただの文字」として扱い、無害化の印として認識しません。そのため無害化したつもりの細工文字列がそのまま命令として通ってしまい、攻撃が成立します。これが発動条件がSQLモードに限られる理由です。

そして本件は、ここから認証回避（CWE-287。本来必要なログイン確認をすり抜けること）につながります。無認証で送り込めるSQLインジェクションを使ってログインの判定処理を欺き、正規の利用者として扱わせることで、IDとパスワードを知らないままシステムの中へ入り込めてしまうわけです。

なお、実際に攻撃が観測されているかどうかについては、米国土安全保障省の機関CISAが公開する「実際に攻撃されている脆弱性リスト」CISA KEVに、本稿の執筆時点（2026年6月1日）では未登録です。開示されたばかりのためで、今後の登録状況は注視する必要があります。報告者など詳細の正式な記述は、ベンダーのアドバイザリ 2026-02を参照してください。

影響範囲の早見表（エディション × SQLモード）

「自社のOTRSが影響を受けるか」は、エディション／バージョンと、MySQL/MariaDBの NO_BACKSLASH_ESCAPES モードの有無の組み合わせで決まります。下の表で自社の位置を確認してください。

注意したいのは、保守の終わった Community Edition 6.0.x です。商用のOTRSと違い、公式の修正版が今後出るとは限りません。該当する場合は、後述の回避策で当座をしのぎつつ、後継のZnunyなどへの移行を前提に動くのが現実的です。詳しい救済の有無は公式アドバイザリを参照してください。

いますぐやるべきこと

対応は、自社がどのエディションかで分かれます。先に発動条件（SQLモード）とバージョンを確認したうえで、次の順に検討してください。

1. 商用・サポート対象は 2026.4.X 以降へ更新する。 根本的な解決は更新です。OTRSのリリースノートとアドバイザリ 2026-02を確認し、修正版へ上げます。更新さえ済めば、SQLモードがどちらでも安全になります。

2. すぐ更新できないなら、SQLモードから NO_BACKSLASH_ESCAPES を外す。 即効性のある回避策です。MySQL/MariaDBで SELECT @@sql_mode; を実行して該当モードが含まれていれば、設定（my.cnf の sql_mode など）からこのモードを外します。MariaDBのSQLモード解説も参考になります。ただし、このモードを外すと文字列の扱いが変わり、他のアプリの動作に影響する場合があります。共用しているデータベースでは、変更前に影響範囲を確認してください。

3. Community Edition利用者は、回避策で当座をしのぎつつ移行を検討する。 保守が終了しているため、公式の修正を待てない可能性が高いのが実情です。上記2のSQLモード変更で当面のリスクを下げたうえで、後継のZnunyなど、保守が続いている系統への移行を前提に計画を立てるのが安全です。

4. 公開範囲を絞り、ログを監視する。 OTRSのログイン画面を不特定多数から到達できる状態にせず、VPNやIP制限の内側に置くと、無認証で外から探られる経路を減らせます。あわせて、ログインやデータベース周辺のアクセスログを点検し、不審なリクエストの連発がないか確認します。WAF（Webアプリケーションファイアウォール）でSQLインジェクションらしい文字列を遮断するのも有効です。

問い合わせ管理システムは、攻撃者から見れば「顧客と社員の個人情報がまとまって置いてある箱」です。同じように自前で運用しているオープンソースのツールに潜む欠陥を素早く把握したい場合は、OSSサプライチェーン・スキャナーもあわせてご覧ください。OTRSやZnunyを自社で動かしている組織は、今回の件を機に、データベースの設定と公開範囲を一度見直しておくことをおすすめします。

参照元

• ▸NVD - CVE-2026-48188 Detail
• ▸OTRS Security Advisory 2026-02（一次情報）
• ▸CWE-20: Improper Input Validation
• ▸CWE-89: SQL Injection
• ▸CWE-287: Improper Authentication
• ▸MariaDB - SQL Mode（NO_BACKSLASH_ESCAPES）
• ▸Znuny（OTRS Community Edition フォーク）
• ▸CISA Known Exploited Vulnerabilities Catalog