「認証バイパス」の脆弱性とは？パッチを当てたあとに中小企業が確認すべきこと

セキュリティの注意喚起が出ると、多くの会社はこう対応します。「対象の機器か確認する」「修正プログラムを当てる」「終わり」。ふだんはこれで正しい対応です。

ただ、2026年7月16日に公開されたJPCERT/CC 四半期レポート（2026年4月1日〜6月30日）には、この「終わり」を疑わせる記述があります。攻撃者が認証を回避して接続を確立しても、その認証完了のログが正規の接続と同じ形式で記録されるため、ログを見ただけでは侵害を見分けにくい。そうした製品が挙げられています。

この記事では、社外との境界に置く機器で報告された「認証バイパス」型の脆弱性について、何がふつうの脆弱性と違うのか、パッチを当てたあとに何を確認すればよいのかを、専門用語ぬきで整理します。

この記事でわかること

• 「認証バイパス」の脆弱性が、ほかの脆弱性と何が違うのか
• パッチを当てたあとに「入られていないか」を確かめるのが難しくなる場合があること
• 中小企業が、いま用意しておける現実的な備え

この四半期、境界の機器に関する注意喚起が続いた

JPCERT/CCは、影響範囲の広い脆弱性が公表された場合に「注意喚起」を出しています。同レポートによると、2026年4〜6月に公開または更新された注意喚起は12件でした。

このうち、インターネットとの境界で使われるネットワーク機器に関係するものを抽出すると4件です。

残る8件は、Microsoftのセキュリティ更新、Adobe Acrobat／Reader、メールセキュリティ製品、エンドポイント製品に関するものでした。この四半期の注意喚起のうち3分の1が、社外とつながる境界の機器に関するものだったことになります。

「認証バイパス」は、認証を強くする対策が届きにくい

注意喚起のタイトルに並ぶ「認証回避」「認証バイパス」という言葉は、名前のとおり認証そのものを通らずに入られてしまう種類の欠陥を指します。

ここが、よくある「パスワードを破られる」話と違う点です。認証バイパスでは、脆弱性のある認証処理そのものを迂回されるため、その処理で使うパスワードを強くするだけでは防げません。製品の実装によっては、同じ認証処理に組み込まれた多要素認証も迂回される可能性があります。

一方で、認証を強くする対策がすべて無意味になるわけでもありません。脆弱な機器へ到達する前段に別の制御（接続元の制限、上流での認証、端末証明書など）がある場合、そこまで無効になるとは限りません。何が有効かは製品ごとのアドバイザリで確認することになります。

認証情報の管理そのものは引き続き必要です（共有IDのリスク）。ただ、この種の脆弱性はそれだけでは塞げない、という点は押さえておく価値があります。用語の整理は用語集でも行っています。

ログが「正常」に見えてしまう場合がある

同レポートは、対応事例としてCisco Catalyst SD-WAN コントローラの認証バイパスの脆弱性（CVE-2026-20182）を挙げています。Ciscoが2026年5月14日にアドバイザリを公表した時点で、すでに悪用が観測されていることに言及されていた脆弱性です。

この事例についてJPCERT/CCは、次の点を指摘しています。

攻撃者が認証を回避して接続を確立した際の認証完了を示すログが、正規のピアによるものと同一の形式で記録されるため、ログの確認のみでは侵害の検知が困難であることが考えられます。

つまりこの製品では、接続ログを眺めても、正規の接続と攻撃者の接続を見分けられないということです。「ログに異常がないから大丈夫」という確認の仕方が、この場合には成り立ちません。

すべての認証バイパスの脆弱性でこうなるわけではありません。ただ、少なくともこの製品では、攻撃者による接続の認証完了ログが正規のピアと同じ形式で記録され得ると報告されています。ログに異常がないことは、侵害されていないことの証明にはならない場合がある。この前提は持っておく価値があります。

入られたあと、どこまで届いたのか

同レポートには、この製品に関する国内組織の事案も記載されています。JPCERT/CCが報告を受けて調査を支援し、機器のログなどを分析した結果、確認されたのは次の痕跡でした。

• CVE-2026-20245（Cisco Catalyst SD-WAN Manager の認証済み特権昇格の脆弱性）を悪用した可能性がうかがわれる痕跡が、2026年4月時点のログに確認された
• 管理者権限アカウントが追加されていた
• 追加した管理者権限を使って、内部ネットワークのルーターのWebUIへログインし、設定を変更した痕跡があった

ここには、中小企業にも当てはまる点が2つあります。

1つめは、時系列です。 CVE-2026-20245 のアドバイザリをCiscoが公表したのは2026年6月4日ですが、痕跡が見つかったのは4月時点のログでした。公表より前の活動を後から確認できたのは、そのログが残っていたからです。ログの保存期間が短ければ、この確認自体が成り立ちません（リモートアクセスのログ管理）。

2つめは、到達範囲です。 境界に置いた機器1台の侵害が、内部のネットワーク機器の設定変更にまで届いています。「入口の機器がやられただけ」では済まないという、横移動の具体例です。

「自社では調べられない」ことがある

同レポートには、もう一つ中小企業に関わりの深い事例が載っています。cPanel および WHM の認証バイパスの脆弱性（CVE-2026-41940）です。

WebPros International が2026年4月28日にアドバイザリを公表したこの脆弱性について、JPCERT/CCが稼働状況を調査したところ、国内で約2,000台が稼働しており、ホスティング事業者の管理下にあるホストの割合が高いことを確認したと記載されています。アドバイザリ公表の翌日には実証コードを含む技術詳細が公開され、翌々日以降はランサムウェアの展開やマルウェアの配布に悪用されているという観測情報が相次ぎました。

注目したいのは、被害を受けた国内組織についての記述です。この組織はホスティング事業者のテナントとして、同事業者が提供するサービスを通じて当該製品を利用していました。そして、次の記述が続きます。

被害組織は、同事業者に対して痕跡調査への協力を求めましたが、利用契約上の制約を理由に協力を得られず、十分な痕跡調査を実施するには至りませんでした。

借りている環境や、任せている機器では、いざというときに自社でログを取れるとは限りません。 これは技術ではなく契約の問題です。ホスティング、レンタルサーバー、保守を委託しているネットワーク機器について、インシデント発生時にどこまで調査に協力してもらえるのかは、平時に確認しておく話です（委託先・協力会社のリモートアクセス）。

連絡は、自社に直接届くとは限らない

JPCERT/CCは、深刻な脆弱性への対策を適用していない「脆弱なホスト」などの利用組織に対して、個別に情報提供を行っています。同レポートによると、この四半期の個別提供情報は38件でした。

その連絡経路について、レポートには次のように書かれています。情報共有プラットフォーム「CISTA」で個別に提供できない場合は、JPNIC WHOIS に登録されている連絡先へ通知する、あるいはISPや保守ベンダーに通知を依頼する場合もある、と。

裏を返せば、自社が「危ないですよ」と知らされるとき、その連絡は保守ベンダー経由で届くかもしれないということです。またWHOISなどの登録連絡先が更新されていなければ、退職した担当者のアドレスなどに通知され、社内での確認が遅れる可能性があります。連絡先の棚卸しは、地味ですが効きます（退職・異動時のアクセス権管理）。

すべてを一度に整える必要はありません。ただ、上4つは対象確認や侵害調査を始める際に求められやすい情報です。事故が起きてから集め始めると、対応が遅れたり、保存期間を過ぎたログを確認できなかったりするおそれがあります（サイバー被害の初動対応）。

自社でログを分析できない場合は、保守会社や販売店に、ログの保存期間、取得できるログの種類、侵害調査の依頼先を確認しておくと、いざというときの出発点になります。

外から触れる面を減らしておく

認証バイパスでは、脆弱性のある認証処理の強化だけでは対処できない場合があります。実際の対処は、次のような組み合わせになります。

1. 修正プログラムを当てる（基本。把握していない機器には当てられないため、棚卸しが前提になります）
2. すぐに適用できない場合は、ベンダーが示す回避策に従う（対象機能の停止、アクセス元の制限、インターネットからの遮断など）
3. すでに悪用されている可能性があるなら、ログの保全と侵害有無の確認を別に行う

同レポートでも、別のメールセキュリティ製品の脆弱性について、修正パッチの適用に加え、すでに侵害を受けている可能性も考慮した侵害有無の確認、必要なログの保全、回避策の実施を呼びかけたと記載されています。

そのうえで、平時にできるのが外部から到達できる管理機能やサービスを必要最小限にしておくことです。管理画面をインターネットへ常時公開しない、接続元を制限する、不要な機能を停止する、といった構成の話になります。VPN機器の脆弱性が放置されやすい構造についてはSSL-VPNの脆弱性でも整理しています。

ForceLink では、このうち管理画面をインターネット側に常時公開しない設計を採用しています。あわせて、鍵ベース接続（端末ごとの鍵で接続を管理）、企業ごとの分離、利用者ごとの到達範囲の制御を組み合わせています。

ただし、置き換えれば脆弱性と無縁になるわけではありません。どんな製品も修正プログラムの適用は必要ですし、ForceLink は現時点で多要素認証（MFA）に未対応です。MFAが必須要件の場合は、要件に合う構成を別途ご確認ください。

まとめ：パッチのあとに、3つだけ確認する

注意喚起が出て、修正プログラムを当てた。そのあとに確認したいのは次の3点です。

1. その脆弱性は、認証を回避される種類のものか（そうであれば、その認証処理に組み込んだパスワードや多要素認証では防げていなかった可能性がある）
2. 適用より前に入られていた可能性を確認できるだけのログが残っているか（管理者アカウントの増減、設定変更の履歴）
3. その機器が委託先の管理下にある場合、調査に協力してもらえる契約になっているか

3点とも「はい」と言えないなら、次に注意喚起が出たときも同じ状態で迎えることになります。全体の考え方は中小企業のゼロトラスト入門、脅威への備えの全体像は中小企業のランサムウェア対策で整理しています。現在の構成については比較ページと製品ページ、費用は料金ページ、細かい条件はFAQを確認してください。

参考・出典

• JPCERT/CC 四半期レポート（2026年4月1日〜6月30日、2026年7月16日公開）
• JPCERT/CC「『JPCERT/CC 四半期レポート』公開のお知らせ」（2026年7月16日）
• JPCERT/CC 注意喚起