cisagov

Your Microsoft 365 subscription is current. Are your security settings? CISA’s ScubaGear helps assess configurations against its security baselines. Ask your IT team: When was our last check, what changed, and who owns the gaps? github.com/cisagov/ScubaGear/releases/tag/v2.0.0 t.co

Cisco ASA/FTD CVE-2026-76418: Actively Exploited SSL VPN DoS with Secondary Authentication 1. Basic Information - Advisory: Cisco Secure Firewall Adaptive Security Appliance and Secure Firewall Threat Defense Software Remote Access SSL VPN Tunnel Denial of Service Vulnerability - Publisher: Cisco - Published: 2026-10-28T19:15:00Z - Source: Cisco - Related Sources: BleepingComputer - Related Sources: SecurityWeek - Related Sources: CISA KEV catalog data - Associated Malware: None specified - Associated Threat Groups: None specified - Associated CVEs: CVE-2026-76418 - Affected Products: Cisco ASA, Cisco FTD, SSL VPN/WebVPN - Severity: high 2. Executive Summary Cisco has confirmed active exploitation of CVE-2026-76418, a vulnerability where crafted requests to SSL VPN tunnel groups using secondary authentication cause ASA and FTD devices to reload, and has released fixed software. The issue warrants high priority because unauthenticated attackers can disrupt firewall and VPN availability, exploitation has been confirmed, and no complete workaround is available. 3. Attack Flow Attack Flow 1. An unauthenticated attacker sends a crafted request to an SSL VPN login endpoint meeting the affected conditions. 2. A logic error in secondary authentication processing leads to a null pointer dereference, causing the device to reload and resulting in a denial of service. A successful VPN login is not required. 4. Attacker Position and Execution Location - An unauthenticated attacker with network access to the SSL VPN interface. 5. Victim and Administrator Perspective Victim - Observed as a sudden disconnection from the VPN. Administrator - Observed through reloads, crash info logs, and availability alerts. 6. Conditions for Success and Failure Conditions for Success - Exploitation requires a vulnerable ASA or FTD release, a reachable SSL VPN login service, SSL VPN enabled on at least one webvpn interface, and secondary authentication in an applicable tunnel group. If tunnel-group-list enable is configured, administrators must check all tunnel groups, including DefaultWEBVPNGroup; the device is affected if any applicable group uses secondary authentication. If the group list is disabled, the device remains affected when DefaultWEBVPNGroup uses secondary authentication. Conditions for Failure and Mitigations - Update to the fixed release for the applicable version series. For example, the first fixed releases are ASA 9.20.4.50 for the ASA 9.20 series and FTD 7.4.9 for the FTD 7.4 series. Verify other series using Cisco advisories and the Software Checker. - There is no complete workaround; updating is required. If secondary authentication is not used on DefaultWEBVPNGroup, disabling tunnel-group-list enable serves as a temporary mitigation. Removing secondary authentication when it is used on DefaultWEBVPNGroup lowers authentication strength, so an impact assessment is required. 7. Impact of Successful Exploitation - Degradation of firewall and VPN availability. 8. Observable Logs Inference: The following are candidate logs to investigate within your organization. Availability depends on log collection, retention settings, and product visibility, and does not imply that all items were recorded in primary sources. - Email: None available - Proxy / SWG / DNS: None available - Endpoint / EDR: Collect device-side crash information, reload reasons, and webvpn configurations. General EDR platforms may not capture these items. - Identity / IdP: None available - SaaS / Cloud: None available - Network: Review SSL VPN requests immediately preceding the reload. 9. Attack Success Determination Inference: The following is an internal determination criterion and does not imply that primary sources observed all stages of success. - Attack Attempt Observed (Success Unconfirmed): Criteria: Even if the arrival of a crafted request is confirmed, the occurrence of a reload or denial of service must be verified separately. Denial of service affects availability and does not constitute follow-on compromise. Target: VPN 10. Investigation Playbook Inference: Internal investigation procedure. - Trigger: Unexpected reload, crash info logs - Initial Checks: Verify target product version, exposure scope, time synchronization, and log retention. - Endpoint: Preserve target device configurations, processes, files, and reboot history. - Identity and Cloud: Verify administrator authentication and API operations. - Follow-on Activity: Track subsequent internal connections, credential usage, configuration changes, and outbound traffic. - Containment: Assess availability and business impact, then restrict access, apply fixed versions, and perform recovery. Do not treat denial of service alone as evidence of credential theft; if separate evidence of compromise exists, investigate and respond to that evidence. - Assessment Categories: Distinguish request receipt from a confirmed denial-of-service outcome, and cross-reference configurations, request timestamps, crash information, and reload reasons. Do not conclude exploitation from a reload alone; consult Cisco TAC if necessary. 11. Defense and Detection Ideas - Single Events: Detect crash signatures immediately following SSL VPN requests. - Timeline Correlation: Correlate request bursts with availability loss. - Hunting: Inventory tunnel groups utilizing secondary authentication. - Logging Gaps: Encrypted request contents may not be visible. - Priority Controls: Prioritize patching, high availability setups, and VPN exposure inventories. 12. Facts, Inferences, and Hypotheses Facts - Cisco describes the issue as a logic error in secondary authentication handling, classified as CWE-690 with a CVSS v3.1 score of 8.6. CISA KEV data notes it as a null pointer dereference resulting from an unchecked return value. - Unauthenticated attackers can trigger device reloads without requiring successful VPN logins. - Exploitation requires a vulnerable ASA or FTD release, a reachable SSL VPN login service, SSL VPN enabled on at least one webvpn interface, and secondary authentication in an applicable tunnel group. If tunnel-group-list enable is configured, administrators must check all tunnel groups, including DefaultWEBVPNGroup; the device is affected if any applicable group uses secondary authentication. If the group list is disabled, the device remains affected when DefaultWEBVPNGroup uses secondary authentication. - Cisco acknowledged active exploitation in October 2026, but threat actors, targets, incident counts, and IOCs have not been publicly disclosed. - There is no complete workaround; updating is required. If secondary authentication is not used on DefaultWEBVPNGroup, disabling tunnel-group-list enable serves as a temporary mitigation. Removing secondary authentication when it is used on DefaultWEBVPNGroup lowers authentication strength, so an impact assessment is required. - CISA added CVE-2026-76418 to the KEV catalog on October 29, 2026, confirming active exploitation of this denial-of-service vulnerability, which does not indicate remote code execution or credential theft. Inference - Inference: Do not assume reloads are attacks without verifying preceding requests and crash information. Hypothesis No additional hypotheses. Unconfirmed items are noted in Unknowns and Limitations. 13. MITRE ATT&CK Mapping | ID | Technique | Confidence | Basis | |---|---|---|---| | T1499.004 | Application or System Exploitation | high | Device reload and service disruption caused by crafted requests. Code execution has not been confirmed. | 14. Unknowns and Limitations - Threat actors, targets, incident counts, and request IOCs are unknown. 15. Impact on SOCs and Organizations Inventory SSL VPN implementations using secondary authentication and update them to fixed releases. 16. Summary by Role - SOC: Correlate requests immediately preceding reloads with crash information. - Administrators: Verify webvpn configurations and apply updates. - Users: Follow alternative access procedures during VPN outages.

WordPressの脆弱性「wp2shell」を狙った攻撃の観測 1. はじめに 三菱電機の木原です。 三菱電機　情報技術総合研究所では、製品開発時のセキュリティ対策にフィードバックする目的で、複数種類のハニーポットを設置・運用しています。 今回はIoT家電を標的としたサイバー攻撃を観測するハニーポット「IoT家電ハニーポット」で観測した中で、2026年7月に公表された深刻度の高いWordPress[1]の脆弱性「wp2shell」を標的としたとみられるパケットに着目した分析結果をご紹介します。 2. wp2shellとは wp2shellは、2026年7月に公表されたWordPressコアの2つの脆弱性（CVE-2026-63030[2]：CVSS v3.1スコア9.8、CVE-2026-60137[3]：CVSS v3.1スコア5.9-いずれもWPScanによる評価）を組み合わせた攻撃チェーンで、認証なしの状態からリモートコード実行に至る可能性がある、深刻度の高いものです。 さらに、WordPressのプラグインではなく、本体（コア）の脆弱性であることから、影響範囲も広いと考えられます。 CVE-2026-63030は、WordPressに実装されている、複数のREST APIリクエストを1つのHTTPリクエストで処理できるBatch API（/batch/v1）の脆弱性です。この脆弱性を悪用すると、Batch APIで処理の宛先の取り違え（ルート混同）が起き、本来適用されるべきパラメータのサニタイズを回避できてしまいます。 CVE-2026-60137は、WP_Queryのauthor__not_inパラメータのサニタイズが適切でないことによる、SQLインジェクションの脆弱性です。ただし、通常はREST API側で入力がサニタイズされるため、標準構成のWordPressコア単体では悪用されにくいものです。 この2つを組み合わせると、CVE-2026-63030でサニタイズを回避した入力がCVE-2026-60137のSQLインジェクション脆弱性の悪用に使われ、結果として認証なしでリモートコード実行に至る可能性が指摘されています[2][4]。 続いて、wp2shellに関連するニュースの時系列を以下に示します。 | 日付（日本時間） | 出来事 | | ---------- | ------------------------------------------------------- | | 2026年7月18日 | WordPressによる修正版のリリース[5] | | 2026年7月18日 | CVE（CVE-2026-63030[2]、CVE-2026-60137[3]）が公開（NVDに掲載） | | 2026年7月19日 | PoCの公開が報じられる[4][6] | | 2026年7月22日 | CISAのKEV（Known Exploited Vulnerabilities）カタログに掲載[7][8] | | 2026年7月22日 | IPAが注意喚起[9] | | 2026年7月23日 | JPCERT/CC WeeklyReport掲載[10] | ※日付は全て日本時間に換算しています。 日本時間2026年7月18日（米国時間7月17日）に本脆弱性は明らかになり、CVE情報の公開（NVD掲載）とWordPressによる修正バージョンの公開が行われました。影響を受けるバージョンと修正後のバージョンは以下のとおりです[2][3][5]。 | 系列 | 影響を受けるバージョン | 影響を受ける脆弱性 | 修正後のバージョン | | ---- | ----------- | ----------------------------- | --------- | | 7.0系 | 7.0.0～7.0.1 | CVE-2026-63030、CVE-2026-60137 | 7.0.2 | | 6.9系 | 6.9.0～6.9.4 | CVE-2026-63030、CVE-2026-60137 | 6.9.5 | | 6.8系 | 6.8.0～6.8.5 | CVE-2026-60137のみ | 6.8.6 | 6.8系はCVE-2026-63030の影響を受けないため、2つを組み合わせた攻撃チェーン（wp2shell）が成立するのは6.9系と7.0系です。なお、6.8より前のバージョンはどちらの脆弱性の影響も受けません[5]。 公表翌日の7月19日にはPoCの公開が報じられ、さらに3日後の22日には積極的に悪用されている脆弱性として、KEVカタログにも掲載されました。 同じく22日にはIPAが注意喚起を行い[9]、23日にはJPCERT/CCのWeeklyReportでも取り上げられています[10]。 3. 観測結果概要 続いて、当社が運営しているハニーポットで観測された、wp2shellを狙ったと思われるパケットの観測結果をご紹介します。なお、当社のIoT家電ハニーポットでは、WordPressは稼働していません。 観測期間は脆弱性が公表された2026年7月18日0時0分から9月30日23時59分までの75日間です（全て日本時間）。本期間で観測したパケットのうち、HTTPのPOSTリクエストにbatch/v1、batch%2Fv1（スラッシュをURLエンコードしたバージョン）、Batch/v1（Bが大文字のバージョン）、Batch%2Fv1（大文字＆エンコード有）の4種類いずれかの文字列が含まれているパケットの総数は119件でした。なお、本記事では、HTTPリクエスト1件を1パケットとして数えています。 これら119件について、観測件数の推移を以下の図に示します。 !Pasted image 20261028153921.png 上図より、7月21日に最初のパケットが観測されていることがわかります。パケットを受信した正確な時刻は7月21日21時4分であり、これは、wp2shellがKEVに掲載された時刻（KEVカタログデータの更新時刻[8]より、日本時間7月22日0時12分）の約3時間前にあたります。 また、8月22日に、119件中78件のパケットが集中していました。さらに、9月25日・28日にも再び観測されています。 続いて、パケットの内容を分析した結果を下表に示します。 | 日付 | 件数 | 送信元の国 | 送信元IPの種類 | パターン | | ---- | --- | ------ | -------- | ------------ | | 7/21 | 1 | シンガポール | ホスティング | ① 同一リクエストの観測 | | 8/9 | 1 | ブルガリア | ホスティング | ① 同一リクエストの観測 | | 8/18 | 1 | 中国 | ホスティング | 中身が空のリクエスト | | 8/20 | 1 | ブルガリア | ホスティング | ① 同一リクエストの観測 | | 8/22 | 78 | アメリカ | ホスティング | ② 自動化ツール | | 8/30 | 2 | ブルガリア | ホスティング | ① 同一リクエストの観測 | | 9/25 | 14 | ブルガリア | ホスティング | ② 自動化ツール | | 9/28 | 21 | オランダ | ホスティング | ② 自動化ツール | HTTPリクエストの内容を確認すると、7月21日・8月9日・20日・30日に観測されたパケットは、リクエストのURLとボディが同一でした。そのため、パターン①と置きます。 また、8月22日の78件は送信元IPアドレスが全て同一であり、リクエストの挙動から①とは異なるパターンと考えました。9月25日・28日の計35件は、送信元IPアドレスこそ8月22日と異なるものの、リクエストの内容が8月22日のものと類似していました。そのため、これらをまとめてパターン②と置きます。 8月18日に観測された1件のパケットは、/?rest_route=/batch/v1宛てのPOSTリクエストで、User-Agentがwp2shell-rce/1.0と、wp2shellを悪用するRCE用ツールであると名乗るものでした。ただし、リクエストのボディは空のJSONで、パターン①・②のいずれにも該当しなかったため、本記事では詳しい分析を割愛いたします。 :::note warn なお、今回観測した通信には、実際の悪用（リモートコード実行）につながるペイロードは含まれておらず、研究者やセキュリティベンダーによる脆弱性確認のスキャンが含まれている可能性があります。実際に、wp2shellを狙ったスキャンの中に、正当なセキュリティスキャンが含まれていたという報告もあります[11]。 ::: ここからは、パターン①・②について、さらに掘り下げていきます。 4. パターン①：同一リクエストの観測 パターン①に該当するのは、7月21日・8月9日・20日・30日に観測された計5件のパケットです。これら5件は全て、/batch/v1宛てに送られていました。 POST /index.php?rest_route=/batch/v1 HTTP/1.1 リクエストのボディも5件全てで同一で、以下の内容でした（読みやすくするため整形しています）。 { "requests": [ { "method": "POST", "path": "http:///x" }, { "body": { "requests": [ { "method": "GET", "path": "/wp/v2/posts" } ] }, "method": "POST", "path": "/wp/v2/posts/1" }, { "method": "POST", "path": "/batch/v1" } ] } このリクエストは、Batch APIのリクエストの中にさらに別のリクエストを入れ子にしたものです。1つ目の脆弱性であるCVE-2026-63030を悪用して、本来行われるはずの入力の検証（サニタイズ）を回避することを狙ったものとみられます。 入れ子の中身は投稿一覧の取得（GET /wp/v2/posts）という、通常は認証なしでも行える無害なリクエストです。また、GETリクエストはBatch APIでは指定できない仕様になっています[12]。以上より、このリクエストは、情報を盗むことが目的ではなく、本来は受け付けられないはずのGETが処理されるかどうか、つまり脆弱性の有無を確認するためのリクエストと考えられます。 また、8月9日に観測された1件のパケットでは、User-AgentがMozilla/5.0 (compatible; checker) wp2shell/CVE-2026-63030となっており、wp2shell（CVE-2026-63030）の確認用ツール（checker）を名乗る文字列が含まれていました。このことからも、パターン①はwp2shellの脆弱性の有無を確認するためのリクエストであると考えられます。 さらに、5件のパケットのうち8月9日・20日・30日に観測された4件は、IPv4アドレスの上位24ビットが同一で、国情報も全てブルガリアのため、同一の送信者が数日に分けてパケットを送信してきた可能性があります（ただし、ホスティング事業者などでは同じ/24のアドレス帯が複数の利用者に割り当てられている場合もあるため、断定はできません）。 5. パターン②：自動化ツールによる攻撃 パターン②に該当するのは、8月22日・9月25日・28日に観測された計113件のパケットです。送信元IPアドレスは日ごとに異なりますが、いずれもホスティングサービスのIPでした。 まずは、最も多くのリクエストが観測された8月22日の攻撃について、詳しく見ていきます。 8月22日の攻撃について、同じ送信元からの通信をパケットキャプチャで前後も含めて確認したところ、HTTPリクエストは計86件（POST 78件、GET 8件）あり、約30秒の間に次の3つのフェーズで進んでいました。 | フェーズ | 経過時間 | リクエスト数 | 内容 | | ---- | ------ | -------- | ------------------ | | 1 | 0～27秒 | POST 78件 | 入口（/batch/v1）の探索 | | 2 | 27～29秒 | GET 6件 | WordPressかどうかの確認 | | 3 | 29秒 | GET 2件 | SQLインジェクションが通るかの確認 | !Pasted image 20261028133102.png 攻撃自動化ツールの可能性 8月22日の攻撃は、上の表から読み取れる以下の2点から、人の手作業ではなく自動化されたツールによるものと考えられます。 - リクエストの速さ：86件のリクエストが約30秒の間に送られていました。特にフェーズ1では、78件のPOSTを約27秒で送っています。 - フェーズ間の切り替えが速い：フェーズ1からフェーズ3までが途切れることなく続き、フェーズ2・3は合計約2～3秒で終わっていました。人が応答を見て次の手を判断している場合では、さらに時間がかかるはずです。 ここから、各フェーズの詳細な内容をご紹介します。 フェーズ1：入口（/batch/v1）の探索 最初のフェーズでは、/batch/v1へのPOSTリクエストを、URLの書き方を変えながら繰り返し送っていました。使われていた書き方は以下の11種類です。 | No. | URL | 書き方の特徴 | POST件数 | | --- | ------------------------------------- | ------------------------------------- | ------ | | 1 | /index.php?rest_route=/batch/v1 | rest_routeを使う形（index.phpあり） | 7 | | 2 | /index.php?rest_route=%2Fbatch%2Fv1 | No.1のスラッシュを%2Fにエンコード | 7 | | 3 | /?rest_route=%2Fbatch%2Fv1 | rest_routeを使う形（index.phpなし）＋エンコード | 7 | | 4 | /?rest_route=/batch%2Fv1 | 一部のスラッシュだけをエンコード | 7 | | 5 | /?rest_route=/batch/v1 | rest_routeを使う形（index.phpなし） | 8 | | 6 | /wp-json/batch/v1 | wp-jsonを使う形（標準のURL） | 7 | | 7 | /wp-json/Batch/v1 | 大文字・小文字の違い | 7 | | 8 | //wp-json/batch/v1 | スラッシュの重複 | 7 | | 9 | /wp-json/batch/v1/ | 末尾のスラッシュ | 7 | | 10 | /blog/wp-json/batch/v1 | /blog/配下に設置されている場合 | 7 | | 11 | /wordpress/wp-json/batch/v1 | /wordpress/配下に設置されている場合 | 7 | | | 合計 | | 78 | 最初に/?rest_route=/batch/v1を1回送ったあと、この11種類を同じ順番で7周（計77件）、約0.3秒間隔で送っていました。 WordPressのREST APIは/wp-json/～と?rest_route=～のどちらかをURLに指定することで利用できますが、/wp-json/～はパーマリンクが無効なサイトでは使えません[13]。そのため、設定に依存しない?rest_route=～の形もあわせて試していると考えられます。また、WordPressはサブディレクトリに設置されることもあるため[14]、/blog/や/wordpress/配下のURL（No.10、11）も試していると考えられます。 一方、エンコード（No.2〜4）、大文字・小文字の違い（No.7）、スラッシュの重複（No.8）、末尾のスラッシュ（No.9）のようなURLのバリエーションは、文字列の一致でブロックするWAFの検知をすり抜けるためと考えられます。実際にwp2shellについては、すぐにアップデートできない場合の暫定策として、/wp-json/batch/v1と?rest_route=/batch/v1をWAFでブロックする方法が紹介されています[6]。 また、リクエストのボディは全て{"requests":[]}という、中身が空のバッチリクエストでした。つまり、このフェーズではまだ攻撃は行っておらず、「入口があるかどうか」を応答から確認しているだけとみられます。 さらに、User-Agentは最初の6周がWebブラウザ（Chrome 120）を装ったもので、最後の1周だけWordPress/6.4.3に変わっていました。User-Agentを変えることで、応答が変わるかを確かめていた可能性があります。 フェーズ2：WordPressかどうかの確認 入口の探索が終わると、次はGETリクエストで以下のURLにアクセスしていました。 | No. | URL | アクセス先 | | --- | --------------------- | ------------- | | 1 | /wp/v2/posts/999999 | REST APIの投稿取得 | | 2 | /wp-login.php | ログイン画面 | | 3 | /feed/ | フィード | | 4 | /wp-json/ | REST APIのトップ | | 5 | / | トップページ | | 6 | /index.asp | 5のリダイレクト先 | ログイン画面やREST APIのトップ、フィードなど、WordPress独自のURLにアクセスし、対象が本当にWordPressであるか、REST APIに到達できるかを確認していると考えられます。 ただし、No.1の/wp/v2/posts/999999は、本来のREST APIのURL（/wp-json/wp/v2/posts/<id>[15]）とは異なり、先頭の部分が欠けていました。そのため、このリクエストは不完全であり、実際は通りません。 考えられる原因として、フェーズ1でハニーポットがBatch APIへのリクエスト11種類全てに401 Unauthorizedを返したことで、ツールがREST APIの入口を特定できず、不完全なURLのままフェーズ2に進んだ可能性があります。 なお、No.6の/index.aspは、ハニーポットがNo.5のトップページへのアクセスにリダイレクトを返したため、そのリダイレクト先にアクセスしたものとみられます。WordPressを狙ったURLではありません。 フェーズ3：SQLインジェクションが通るかの確認 最後のフェーズでは、CVE-2026-60137のSQLインジェクションが通るかを確認しようとしたとみられるリクエストを2件送っていました。 1件目は、投稿ID（999999）を指定したURLに、author_exclude・orderby・per_pageの3つのパラメータを付けたリクエストです。 GET /wp/v2/posts/999999?author_exclude=1&orderby=none&per_page=5 author_excludeは「指定した投稿者の投稿を除外する」ためのREST APIのパラメータで[15]、投稿一覧の取得（/wp-json/wp/v2/posts）で指定した場合に、WordPressの内部でCVE-2026-60137の脆弱性があるWP_Queryのauthor__not_inに渡されます。この1件目は、2件目の応答と比べるための基準となる、無害なリクエストと考えられます。 2件目は、同じauthor_excludeパラメータにSQL文を埋め込んだリクエストです。悪用を避けるため、SQL文の部分は省略して示します。 GET /wp/v2/posts/999999?author_exclude=1)［SQL文（省略）］&orderby=none&per_page=500 リクエストの詳細に関しては安全のため割愛しますが、1件目の応答を基準として、2件目の応答に違いが現れるかどうかで、SQLインジェクションが通るかどうかを確認しようとしているとみられます。 しかし、フェーズ3のリクエストは、通常のREST APIの処理では意図どおりに動きません。author_exclude・orderby・per_pageは投稿一覧の取得（/wp-json/wp/v2/posts）用のパラメータで[15]、投稿1件の取得用のURL（/posts/<id>）では使われません。また、投稿一覧の取得に送った場合でも、orderby=noneやper_page=500はREST APIの入力検証で拒否されます。 これらの値は、入力検証を経ずにWP_Queryへ直接渡れば受け付けられるものです。つまりフェーズ3は、CVE-2026-63030で入力検証を回避することを前提とした作りと考えられます。しかし、実際にはBatch APIを経由せずに直接送られていたため、脆弱なバージョンのWordPressに送られた場合でも、SQLインジェクションは成立しないと考えられます。このように、2章で示した攻撃チェーンの形になっていないことから、ツールの実装が不完全である可能性があります。 9月25日・28日の攻撃 9月25日・28日にも、8月22日と同じツールによるものとみられる通信を観測しました。送信元IPアドレスと国情報は8月22日とは異なりますが、以下の点が8月22日と一致していました。 - フェーズ1で試すURLの種類と、送る順番 - リクエストのボディ（{"requests":[]}）とUser-Agent 一方で、どちらの日も/batch/v1へのリクエストはフェーズ1の2周目の途中（9月25日は14件、28日は21件）で終わっており、フェーズ2・3のリクエストは観測されませんでした。 どちらの日も、送信件数は14件・21件と異なるものの（ネットワーク応答速度の違いが原因として考えられます）、最初のリクエストから約29秒で送信が止まっていました。また、8月22日の攻撃も約30秒で終了しています。件数ではなく時間で打ち切られていることから、ツールの処理全体に約30秒の時間制限がある可能性があり、9月25日・28日の攻撃はフェーズ1の途中で時間切れとなり、フェーズ2・3に進まなかったと推測されます。 6. まとめ 今回は、当社のハニーポットで観測された、wp2shellを狙ったと思われる通信について、分析結果をご紹介しました。 今回の観測で興味深かった点として、CVEの公表から4日足らずで、KEVへの掲載よりも前に、当社のハニーポットでもwp2shellを狙ったとみられる通信が観測されたこと、また攻撃の自動化が行われているとみられる点が挙げられます。さらに、WordPressが動作していない当社のIoT家電ハニーポットにもパケットが届いていることから、広範囲にスキャンを行いターゲットを探索している様子もうかがえます。 このように、CVE公表からスキャン観測までの期間は短く、また広範囲なターゲット探索がみられることから、脆弱性に対する迅速な対応や、APIエンドポイントのセキュリティ対策がより重要になってくると思われます。 当社では、引き続きハニーポットを用いた観測を行い、こちらで観測・分析結果をご紹介する予定です。 ご質問やコメントもお待ちしております。 参考文献 [1] WordPress.org, wordpress.org [2] NVD, "CVE-2026-63030 Detail", 2026年7月17日（現地時間）, nvd.nist.gov [3] NVD, "CVE-2026-60137 Detail", 2026年7月17日（現地時間）, nvd.nist.gov [4] セキュリティ対策Lab, 「WordPress 本体で危険度の高い脆弱性 wp2shell-サイバー攻撃への悪用が発生(CVE-2026-63030,CVE-2026-60137)」, 2026年7月19日, rocket-boys.co.jp [5] WordPress.org, "WordPress 7.0.2 リリース", 2026年7月18日, ja.wordpress.org [6] BleepingComputer, "WordPress Core "wp2shell" RCE flaws get public exploits, patch now", 2026年7月18日（現地時間）, bleepingcomputer.com [7] CISA, "CISA Adds Four Known Exploited Vulnerabilities to Catalog", 2026年7月21日（現地時間）, cisa.gov [8] CISA, "Known Exploited Vulnerabilities Catalog"（catalogVersion 2026.07.21）, cisagov/kev-data, github.com/cisagov/kev-data/blob/bc9dbb256ec16f37… [9] IPA, 「WordPressの脆弱性対策について(CVE-2026-60137、CVE-2026-63030：wp2shell)」, 2026年7月22日, ipa.go.jp [10] JPCERT/CC, 「Weekly Report 2026-07-23号」, 2026年7月23日, jpcert.or.jp [11] Wiz, "Exploitation in the Wild of wp2shell", 2026年7月20日, wiz.io [12] Make WordPress Core, "REST API Batch Framework in WordPress 5.6", 2020年11月20日, make.wordpress.org [13] WordPress Developer Resources, "Routes and Endpoints", developer.wordpress.org [14] WordPress Developer Resources, "How to install WordPress", developer.wordpress.org [15] WordPress Developer Resources, "Posts", developer.wordpress.org

CISA's ScubaGear v2.0 now says risky AI agents shall be blocked, and that control needs Entra P2 plus Agent 365 or M365 E7. Small business tenants get agents long before they get that license, so what are you doing in tenants that will never buy E7? github.com/cisagov/ScubaGear/releases/tag/v2.0.0

La Cybersecurity and Infrastructure Security Agency (CISA), añadió el 26 de octubre de 2026 tanto CVE-2026-109618 como CVE-2026-109619 (PHP2Shell), a su catálogo oficial Known Exploited Vulnerabilities (KEV). github.com/cisagov/kev-data/blob/develop/known_ex… CISA dice que existen evidencias de explotación real de las dos vulnerabilidades. Esto es nuevo para CVE-2026-109619, porque hasta ahora la evidencia era sólo en cadenas de corrupción de memoria asociadas a CVE-2026-109618. Pero (siempre hay un pero 😆), el catálogo KEV no publica los detalles técnicos que justificaron añadir las dos CVE. Por tanto, no podemos afirmar que exista explotación de ambas CVE contra PHP-FPM. Seguimos esperando alguna prueba de que PHP2Shell se pueda explotar en FPM en producción.

Uppercase the path, skip the auth gate: an unauthenticated nginx bypass in CISA's Malcolm (GHSA-7j32-cf27-cp6h) TL;DR - What: Malcolm — the free network-traffic-analysis suite built by CISA and Idaho National Laboratory — shipped an nginx reverse-proxy config where one route's matcher was case-insensitive but its redirect was case-sensitive. Requesting that route in any non-lowercase casing (/IDDASH2ARK/…) slipped past the redirect and fell through to an unauthenticated proxy_pass, in one of two proxied locations that never got the auth include. - Impact: an unauthenticated network caller reaches the Arkime full-packet-capture backend, and because that same location forwards a client-supplied X-Forwarded-User header un-overwritten — the exact header Arkime is configured to trust as the logged-in user — the caller arrives with a forged, auto-provisioned identity. Rated Moderate 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N). - Fixed in v26.08.0, advisory GHSA-7j32-cf27-cp6h, credited to me as reporter. CVE-2026-107336 lists me as finder. Why you should care Malcolm is a free, full-packet-capture and network-traffic-analysis suite, developed by CISA in collaboration with Idaho National Laboratory for network security monitoring. Its front door is an analyst web UI on 443; behind that sits Arkime, the engine that stores and serves captured sessions and PCAP. For a tool whose entire job is to hold captured network traffic, the auth gate on the front proxy is the security boundary. So when one route quietly falls off that gate, "unauthenticated" doesn't mean a marketing page is exposed — it means an anonymous caller is talking to the packet store. The setup Malcolm's front nginx gates its proxied routes by include-ing a runtime auth file (nginx_auth_rt.conf, which in the shipped default resolves to HTTP basic auth). Most proxied locations include it; two did not. That include does two jobs at once: it demands credentials, and it overwrites X-Forwarded-User with the authenticated user so a client can never forge it. The /iddash2ark/ route is different by design. The "Dashboards → Arkime shortcut" at /iddash2ark/ was only ever meant to hand you a 302 redirect to the real, gated /arkime/sessions?expression=…. It didn't need its own auth, because a redirect leaks nothing. That assumption is where it goes wrong. The bug # nginx/nginx.conf (v26.07.1) location ~* /iddash2ark/(.*) { # ~* = CASE-INSENSITIVE match ... rewrite ^.*/iddash2ark/(.*) $forwarded_scheme://$host/arkime/sessions?expression=($1) redirect; # case-SENSITIVE (no (?i) modifier) proxy_pass $arkime_protocol://arkime; # fall-through target: unauthenticated ... include /etc/nginx/nginx_proxy_forward_headers.conf; # NOT the auth include } Two directives disagree about case. The location ~* matcher is case-insensitive, so /IDDASH2ARK/x enters the block. But the rewrite pattern ^.*/iddash2ark/(.*) has no (?i) modifier, so it is case-sensitive and does not match the uppercase path. No 302 is issued, and nginx falls through to the next thing in the block: a bare proxy_pass to Arkime. This location includes only the header-forwarding file, not the auth file. The request reaches the backend with no credentials checked. (/dashboards/app/extracted-files/ had the same case mismatch and the same missing include; the maintainer fixed both together.) Then the confused deputy. The header file this location does include sets X-Forwarded-For/Host/Proto/... but never touches X-Forwarded-User. On every gated route, the auth include overwrites that header with the authenticated user; here nothing overwrites it, so whatever the client sends survives. And Arkime is configured to trust it: # arkime/etc/config.ini (v26.07.1) userAuthIps=::,0.0.0.0/0 userNameHeader=x-forwarded-user userAutoCreateTmpl={"userId": "${this["x-forwarded-user"]}", ... "enabled": true, ... "webEnabled": true, "headerAuthEnabled": true, ... "packetSearch": true, ...} userNameHeader=x-forwarded-user means Arkime reads the logged-in username straight out of that header; userAuthIps=::,0.0.0.0/0 trusts every IPv4 peer (and nginx is the peer); and the auto-create template provisions that user on the fly with packet search enabled. So the attacker doesn't merely reach the backend unauthenticated — they get to choose who they arrive as. !Diagram: the case-mismatch auth bypass in Malcolm, step by step The "aha" The location matcher was case-insensitive, but the redirect meant to neutralize the request was case-sensitive — so changing one letter to uppercase slipped the request into a route that never had an auth gate, carrying a username the backend had been told to trust. Proof of concept (benign) I didn't need the full suite for this — the bug lives entirely in Malcolm's own nginx config. I stood up a minimal nginx from the verbatim, unmodified shipped config fragments of tag v26.07.1, in front of a tiny stub that just echoes the method, path, and headers it receives (no Arkime logic reimplemented, nothing weaponized). Everything local, synthetic, no live or third-party system touched. The run went over plain HTTP on localhost; this is the recorded output: # [1] positive control: GET /arkime/ (no creds) HTTP/1.1 401 Authorization Required # [2] inverse control: GET /iddash2ark/x (exact lowercase, no creds) HTTP/1.1 302 Moved Temporarily Location: http://127.0.0.1/arkime/sessions?expression=(x) # [3] the bypass: GET /IDDASH2ARK/x (uppercase, no creds, X-Forwarded-User: forged-admin) HTTP/1.1 200 OK ARKIME_STUB_HIT method=GET path=/IDDASH2ARK/x x-forwarded-user='forged-admin' x-forwarded-roles=None authorization=None The last request reached the backend unauthenticated, with the forged header passed through un-overwritten. Mixed case (/IdDaSh2Ark/y) behaves identically, and the raw request URI (path + query) is forwarded verbatim, so the caller controls exactly what Arkime receives. Honest boundary: I confirmed the bypass and the forged, un-overwritten identity reaching the backend. I did not stand up a real Arkime instance to confirm which session/PCAP responses it serves under that prefix. That's why the score sits at Moderate 6.5 (C:L) and not higher — the foothold is proven, the depth of the data read isn't, and I'd rather under-claim than over-claim. (Before the PoC I had it at 7.5, assuming a full data read. I filed it at 6.5 because that read wasn't confirmed.) The fix Shipped in v26.08.0 (2026-08-25), tracked in cisagov/Malcolm#1081. The maintainer's fix does three things. It makes the rewrite case-insensitive with the inline (?i) modifier, so the matcher and the rewrite agree. It deletes the dead proxy_pass and its forwarding headers, so the location can only ever redirect and nothing reaches Arkime through it. And it adds the auth include as a backstop. The location as shipped in v26.08.0: location ~* /iddash2ark/(.*) { include /etc/nginx/nginx_auth_rt.conf; set $forwarded_scheme $scheme; if ($http_x_forwarded_proto = 'https') { set $forwarded_scheme https; } rewrite (?i)^.*/iddash2ark/(.*) $forwarded_scheme://$host/arkime/sessions?expression=($1) redirect; } The same change went into /dashboards/app/extracted-files/ and into the read-only profile (nginx_readonly.conf), where the /iddash2ark/ block was byte-identical. A week later the maintainer fixed a third location of the same shape, /dashboards/app/netbox/ (#1107). Takeaways 1. A case-insensitive location ~* paired with a case-sensitive rewrite is a bug, not a style choice. If a matcher and the directive meant to act on the match disagree about case, requests can enter the block and skip the action — here, skip the redirect that was the only thing standing between an anonymous caller and an unauthenticated proxy_pass. 2. Per-location auth is a checklist, and checklists have gaps. Here two "harmless redirect" locations also carried a proxy_pass and skipped the include. A redirect-only location shouldn't have a proxy_pass at all, and a default-deny backstop — a server-level auth_request that every location inherits — means one forgotten include isn't a total bypass. 3. Never honor a forwarded identity header on a path that isn't behind the auth that sets it. X-Forwarded-User is only trustworthy if something upstream guarantees it. The moment a route forwards it without overwriting it, it's attacker input — a textbook confused deputy. Disclosure timeline - 2026-08-13 — found during a source review of Malcolm's nginx config. - 2026-08-17 — reproduced locally against the shipped v26.07.1 config. - 2026-08-19 — reported privately via GitHub's private vulnerability reporting. - 2026-08-20 — advisory GHSA-7j32-cf27-cp6h published by the maintainer, crediting me as reporter. - 2026-08-25 — fix released in v26.08.0. - 2026-10-08 — CVE-2026-107336 published. This is distinct from Malcolm's earlier nginx-RBAC advisories about URI normalization and percent-encoding, which have a different root cause. This one is the case-sensitivity mismatch on the /iddash2ark/ location plus an un-overwritten forwarded identity header. Credit / CTA If you run nginx with per-location auth, this is a five-minute grep worth doing today: look for ~* matchers paired with case-sensitive rewrites, and for any proxy_pass location missing your auth include. Two directives that disagree about case are enough to open a door. Reported by me. Comments and corrections welcome. --- Santosh Kumar Puppala — AI/ML Platform Architect and security researcher (multiple CVEs; creator of Norviq). GitHub: @Santoshkumarpuppala

これを機にCISAのSigmaルール提供はじまるのかな？ cisagov/SIGMA_Rules

PHP2Shell Sigma rule from CISA github.com/cisagov/SIGMA_Rules/blob/develop/CISA_…

KEV Observatory: exploring exploited vulnerabilities with an offline cybersecurity dashboard CISA’s Known Exploited Vulnerabilities (KEV) catalog is useful evidence for security teams, but a long list of CVEs can be difficult to explore. I built KEV Observatory to turn that public dataset into a searchable, interactive dashboard. Try the live dashboard · Browse the source on GitHub !KEV Observatory dashboard showing catalog statistics, charts and vulnerability records What you can explore The dashboard answers three questions: - Which vendors have the most entries in the selected records? - Which weakness categories appear most often? - How have catalog additions changed over time? Search by CVE, vendor, product or CWE. Combine vendor, year-added and ransomware-use filters to update the statistics, charts and table together. Open a CVE to inspect its description, CISA’s required action, deadline and source notes. Export the filtered records as CSV, or download the dashboard as a self-contained HTML file. What this snapshot shows The embedded catalog was released on 13 October 2026 and retrieved on 14 October 2026. It contains 1,741 CVEs across 288 distinct vendor labels. In this snapshot: - Microsoft has 390 entries, or 22.4% of the catalog. - 361 entries, or 20.7%, are marked as used in known ransomware campaigns. - CWE-20 is the most frequent CWE label, appearing 119 times. - 32 CVEs were added in the last 30 days relative to the snapshot date. These are descriptive findings about the catalog. They do not rank vendors by security quality: counts are not normalized for market share, product count or disclosure practices. A CVE can also have multiple CWE labels. Keeping the interpretation honest KEV inclusion means there is evidence of exploitation in the wild. It does not prove that a visitor’s own systems are affected, and this app does not assign a severity score. Other distinctions matter too: - The catalog’s addition date is not the date exploitation first occurred. - “Unknown” ransomware use does not mean “No.” - CISA due dates apply to relevant U.S. federal civilian agencies; they do not establish that another organization is overdue. - The dashboard uses a fixed snapshot, not a live feed. Before using a finding operationally, match the affected product and version to your asset inventory and review the vendor’s guidance. How it works KEV Observatory uses plain HTML, CSS and JavaScript with the public dataset embedded in the page. It needs no API key, account, external JavaScript library or backend. The downloaded HTML works offline. It does not collect personal information, send telemetry, scan systems or execute exploits. The source includes build and validation scripts. Checks cover catalog integrity and unique CVE identifiers, filtering, aggregation, HTML escaping, CSV formula protection, offline embedding and JavaScript syntax. Browser checks covered search, combined filters, CVE details, pagination and empty results. To rebuild locally: node build.cjs node test.cjs The development lesson for me was that a dashboard should explain its evidence and limitations as clearly as it displays its charts. Built by Onkar Singh Pawar, with AI assistance for development, testing and this article. Data sources: CISA KEV catalog and CISA’s official dataset repository.