米CERT/CC（カーネギーメロン大学のセキュリティ調整機関）が2026年6月3日、学校向けのWebフィルタリング用Chrome拡張機能「Securly」に、暗号化やアクセス制御に関する7件の脆弱性があると公表しました（VU#595768、CVE-2026-8874ほか）。対象は主に米国の教育機関ですが、露呈した弱点は「ブラウザ拡張機能が抱えがちな盲点」の見本市です。日本の情シスにとっても、自社で許可している拡張機能の棚卸しを促す好材料になります。
本記事では、公表された事実を整理したうえで、拡張機能という『管理から漏れやすい実行環境』にどう向き合うかを実務者目線で掘り下げます。
この記事でわかること
- Securly拡張機能で何が問題視されたのか（7件の脆弱性の要点）
- なぜブラウザ拡張機能はセキュリティ管理の盲点になりやすいのか
- 自社の拡張機能をどう棚卸し・統制すればよいか（公的指針への導線つき）
何が起きたのか
結論から言うと、広く導入されている拡張機能でも、通信・鍵管理・審査回避といった基本的な設計上の弱点を複数抱えていた、という事例です。CERT/CCによると、対象はSecurly Chrome Extension バージョン3.0.7。学校でのフィルタリングや児童の危機兆候（クライシスアラート）検知に使われる拡張機能です。公表時点でベンダーからの回答は得られておらず（Vendor Status: Unknown）、修正版の提供も確認されていません。
個別のCVSSスコアはアドバイザリに記載されていませんが、7件が相互に絡むことで「フィルタリング設定の傍受・改ざん」「暗号化データの復号」「サービス停止」といった複合的な影響が指摘されています。
技術的に何が問題だったのか
公表された7件は、いずれも「攻撃者の高度な技術」ではなく実装側の基本的な手抜きに起因する点が特徴です。要点を整理します。
| CVE | 種別(CWE) | 問題の要点 |
|---|---|---|
| CVE-2026-8874 | 平文通信(CWE-319) | 危機兆候キーワードやフィルタ規則のJSONを暗号化されないHTTPで取得。他エンドポイントはHTTPSなのに一部だけ平文 |
| CVE-2026-8876 | ハードコードされた資格情報(CWE-798) | スクリプト(securly.min.js)内にAESパスフレーズを平文で埋め込み。機微データを復号できる |
| CVE-2026-8878 | 脆弱な難読化(CWE-327) | 公開エンドポイントがSHA-1ハッシュを「シーザー暗号」程度の難読化で露出 |
| CVE-2026-8879 | 不適切なアクセス制御(CWE-284) | manifest.jsonに宣言のないコンテンツスクリプトを実行時に動的登録し、ストア審査を回避。全URLで動作 |
| CVE-2026-8881 | 脆弱な暗号(CWE-327) | 鍵導出にMD5・反復1回。2004年に破られたMD5で鍵ストレッチも無く、オフライン解読が容易 |
| CVE-2026-8888 | ReDoS(CWE-1333) | HTTPで取得した正規表現に破滅的バックトラッキングの余地。サービス停止を誘発 |
| CVE-2026-8889 | 非推奨ハッシュ(CWE-327) | ブロックリスト照合に旧式のSHA-1を使用 |
とりわけ情シスが注目したいのはCVE-2026-8879です。マニフェストに宣言していないスクリプトを実行時に動的登録して全ページで動かす挙動は、Chromeウェブストアの静的審査をすり抜けます。「ストアで配布されている＝審査済みだから安全」という前提が、実装次第で崩れうることを示しています。
なぜブラウザ拡張機能は盲点になりやすいのか
拡張機能は『利用者が閲覧する全ページのDOMに触れる権限』を持ちうる、事実上のブラウザ内エージェントだからです。にもかかわらず、資産管理台帳やソフトウェア更新管理の対象から外れているケースが少なくありません。理由は次のように整理できます。
- 導入が容易すぎる：管理者権限が不要で、利用者が数クリックで追加できる。IT部門の把握を経ずに増殖する。
- 権限の粒度が粗い：「すべてのサイトのデータの読み取りと変更」を要求する拡張が珍しくなく、実質的に閲覧内容・入力内容を覗ける。
- 更新経路が独立：拡張はストア経由でサイレント更新される。ある日から挙動が変わったり、買収でオーナーが替わったりしても気づきにくい。
- 審査は万能ではない：今回のように、審査を回避する実装や、外部から取得する設定ファイル次第で挙動が変わる設計は静的審査で見抜きにくい。
ブラウザ拡張やWeb技術を悪用する攻撃手口の広がりは、ブラウザ拡張を起点にした攻撃の最新動向でも触れています。拡張機能は「便利な小物」ではなく「特権的な実行環境」として扱うのが出発点です。
現場目線の課題
正直なところ、拡張機能の統制は「言うは易し」の典型です。全端末のブラウザに何が入っているかを完全に把握するだけでも、限られた人員では骨が折れます。業務効率化のために現場が自主的に入れた便利な拡張を、セキュリティを理由に一律禁止すれば反発も出ます。「危険だから全部消して」では現場は動きません。
また今回のSecurlyのように、拡張の中身は難読化・圧縮されたJavaScriptで、情シス側がソースを読んで安全性を判断するのは現実的ではありません。結局は「配布元をどこまで信頼できるか」「要求する権限が用途に見合うか」という間接的な判断に頼らざるを得ない――ここに拡張機能ガバナンスの難しさが凝縮されています。
情シスはどうすべきか
個別の脆弱性を追う前に、まず『何が入っているか』の可視化と、追加できる拡張の制限から着手するのが定石です。自前で長大なチェックリストを作るより、公的指針と標準機能を組み合わせるのが近道です。
- 棚卸しと可視化：まずは全端末で導入済みの拡張機能を洗い出す。EDRや資産管理ツールで拡張の一覧を取得できる場合が多い。
- 許可リスト方式（allowlisting）：Google ChromeやMicrosoft Edgeは、グループポリシー／管理コンソールで「許可した拡張だけインストール可」に設定できる。原則ブロックし、業務上必要なものだけ通す運用が堅実。
- 権限の最小化：要求権限が用途に対して過大な拡張は避ける。この考え方は最小権限の原則そのものであり、拡張機能にも等しく当てはまる。
- 更新・供給元の監視：オーナー変更やサイレントアップデートで挙動が変わりうる前提で、重要端末では特に挙動を監視する。
組織的な進め方は、IPAの中小企業の情報セキュリティ対策ガイドラインが土台になります。利用者側の意識づけには対策のしおりが使いやすく、「よく分からない拡張を安易に入れない」という地道な啓発が、結局は最も効きます。ブラウザ本体の更新管理と併せた運用はChromeの脆弱性・連続更新への対応も参考にしてください。
中長期の視点
ブラウザは今や業務アプリの主戦場であり、その内側で動く拡張機能は「管理外のSaaSクライアント」に近い存在になりつつあります。端末やネットワークの信頼を前提にせず、アクセスのたびに検証するゼロトラストの発想を、拡張機能という細部にも広げていく必要があります。エンタープライズ向けブラウザ管理機能や、ブラウザ拡張の脅威検知に対応するツールの整備は、今後の投資判断でも論点になるでしょう。
まとめ
- CERT/CCが学校向けフィルタリング拡張「Securly」（v3.0.7）に7件の脆弱性を公表。平文通信・ハードコードされた鍵・審査回避など基本的な弱点が並ぶ。
- 拡張機能は全ページに触れうる特権的な実行環境。ストア配布や審査済みという看板は、安全性を保証しない。
- 情シスはまず可視化と許可リスト方式で統制を効かせ、権限の最小化と利用者啓発を地道に進めるのが現実解。
出典
- CERT/CC Vulnerability Note VU#595768「Securly Chrome Extension contains multiple weak encryption and access control vulnerabilities」 https://kb.cert.org/vuls/id/595768
- JPCERT/CC JVNVU#97035938 https://jvn.jp/vu/JVNVU97035938/
- NVD CVE-2026-8874 https://nvd.nist.gov/vuln/detail/CVE-2026-8874
- IPA 中小企業の情報セキュリティ対策ガイドライン https://www.ipa.go.jp/security/guide/sme/index.html
※本記事は2026年7月10日時点の公開情報に基づきます。対象製品は主に米国教育機関向けですが、拡張機能管理の教訓として国内の情シス向けに整理したものです。
