WordPress Application Password authorization with off-origin callback (XSS2Shell escalation) - BROAD
SIGMA detection rule by Adama ASSIONGBON (SOC & CTI Consultant), https://linkedin.com/in/adama-assiongbon-9029893a · Unknown
Detects a request to WordPress's Application Password authorization endpoint (authorize-application.php) carrying an absolute, off-site success_url callback. In the CVE-2026-64638 (XSS2Shell) escalation chain, a Same Origin Method Execution (SOME) pivot auto-approves this authorization from the victim administrator's own authenticated session, and WordPress returns the freshly generated Application Password via the attacker-controlled success_url. The underlying vulnerability report (hadrian.io) identifies this off-origin callback as a distinguishing signal on this specific escalation step, distinct from a legitimate third-party integration authorizing against its own registered domain. Requires environment-specific tuning: legitimate off-site integrations exist, this is a BROAD hunting rule, not a zero-FP STRICT signal. The offsite-callback match also covers protocol-relative callbacks (success_url=//attacker.example/...), which browsers and many URL validators treat as absolute off-origin targets exactly like a full https:// URL. The approved-domain filter is anchored immediately after success_url= rather than matched as a free substring, so it cannot be defeated by stuffing the approved domain string as decoy text elsewhere in a malicious URL, nor by a spoofed subdomain suffix appended after the approved domain. SOC L1 should verify the source, affected host, user, process or request fields, timing, and related activity.
Detecte une requete vers l'endpoint d'autorisation d'Application Password de WordPress (authorize-application.php) transportant un callback success_url absolu et hors origine. Dans la chaine d'escalade CVE-2026-64638 (XSS2Shell), un pivot SOME (Same Origin Method Execution) auto-approuve cette autorisation depuis la propre session authentifiee de la victime administrateur, et WordPress retourne l'Application Password fraichement generee via le success_url controle par l'attaquant. Le rapport de vulnerabilite source (hadrian.io) identifie ce callback hors origine comme un signal distinctif sur cette etape d'escalade precise, different d'une integration tierce legitime qui s'autorise vers son propre domaine enregistre. Necessite un tuning specifique a l'environnement : des integrations tierces hors site legitimes existent, ceci est une regle BROAD de hunting, pas un signal STRICT a FP quasi nul. La correspondance sur le callback hors site couvre aussi les callbacks protocol-relative (success_url=//attacker.example/...), que les navigateurs et de nombreux validateurs d'URL traitent comme des cibles absolues hors origine au meme titre qu'une URL https:// complete. Le filtre de domaine approuve est ancre immediatement apres success_url= plutot que recherche comme sous-chaine libre, il ne peut donc pas etre contourne en injectant le domaine approuve comme texte leurre ailleurs dans une URL malveillante, ni par un suffixe de sous-domaine usurpe accole apres le domaine approuve. Le SOC L1 doit vérifier la source, l’hôte affecté, l’utilisateur, les champs de processus ou de requête, la chronologie et les activités associées.
title: WordPress Application Password authorization with off-origin callback (XSS2Shell escalation) - BROAD
id: 6651aeef-a7f9-4aed-95bb-370fbe7da24d
status: experimental
description: |
Detects a request to WordPress's Application Password authorization endpoint (authorize-application.php) carrying an absolute, off-site success_url callback. In the CVE-2026-64638 (XSS2Shell) escalation chain, a Same Origin Method Execution (SOME) pivot auto-approves this authorization from the victim administrator's own authenticated session, and WordPress returns the freshly generated Application Password via the attacker-controlled success_url. The underlying vulnerability report (hadrian.io) identifies this off-origin callback as a distinguishing signal on this specific escalation step, distinct from a legitimate third-party integration authorizing against its own registered domain. Requires environment-specific tuning: legitimate off-site integrations exist, this is a BROAD hunting rule, not a zero-FP STRICT signal. The offsite-callback match also covers protocol-relative callbacks (success_url=//attacker.example/...), which browsers and many URL validators treat as absolute off-origin targets exactly like a full https:// URL. The approved-domain filter is anchored immediately after success_url= rather than matched as a free substring, so it cannot be defeated by stuffing the approved domain string as decoy text elsewhere in a malicious URL, nor by a spoofed subdomain suffix appended after the approved domain. SOC L1 should verify the source, affected host, user, process or request fields, timing, and related activity.
Detecte une requete vers l'endpoint d'autorisation d'Application Password de WordPress (authorize-application.php) transportant un callback success_url absolu et hors origine. Dans la chaine d'escalade CVE-2026-64638 (XSS2Shell), un pivot SOME (Same Origin Method Execution) auto-approuve cette autorisation depuis la propre session authentifiee de la victime administrateur, et WordPress retourne l'Application Password fraichement generee via le success_url controle par l'attaquant. Le rapport de vulnerabilite source (hadrian.io) identifie ce callback hors origine comme un signal distinctif sur cette etape d'escalade precise, different d'une integration tierce legitime qui s'autorise vers son propre domaine enregistre. Necessite un tuning specifique a l'environnement : des integrations tierces hors site legitimes existent, ceci est une regle BROAD de hunting, pas un signal STRICT a FP quasi nul. La correspondance sur le callback hors site couvre aussi les callbacks protocol-relative (success_url=//attacker.example/...), que les navigateurs et de nombreux validateurs d'URL traitent comme des cibles absolues hors origine au meme titre qu'une URL https:// complete. Le filtre de domaine approuve est ancre immediatement apres success_url= plutot que recherche comme sous-chaine libre, il ne peut donc pas etre contourne en injectant le domaine approuve comme texte leurre ailleurs dans une URL malveillante, ni par un suffixe de sous-domaine usurpe accole apres le domaine approuve. Le SOC L1 doit vérifier la source, l’hôte affecté, l’utilisateur, les champs de processus ou de requête, la chronologie et les activités associées.
references:
- https://www.cve.org/CVERecord?id=CVE-2026-64638
- https://nvd.nist.gov/vuln/detail/CVE-2026-64638
- https://wordpress.org/news/2026/08/wordpress-7-0-3-release/
- https://hadrian.io/blog/wordpress-xss2shell-unauthenticated-login-screen-xss-to-php-code-execution-cve-2026-64638
- https://pwn.ai/blog/xss2shell
author: Adama ASSIONGBON (SOC & CTI Consultant), https://linkedin.com/in/adama-assiongbon-9029893a
date: 2026-08-13
related:
- id: 9f2ae8e2-13cc-408c-ae91-8c26fd5f13f5
type: derived
- id: 1cb448aa-2092-4d01-9509-5f723226e3a9
type: derived
- id: 4fc16c50-0ed6-42df-be58-7dd73bedcece
type: derived
tags:
- attack.credential-access
- attack.t1528
- cve.2026-64638
logsource:
category: webserver
definition: >
Web server, WAF or reverse-proxy access logs on the WordPress admin path. Expected
fields: Url, HttpMethod. Field names vary by log source; adapt Url to the local
pipeline (e.g. url.path, http.request.uri).
detection:
selection_endpoint:
Url|contains: '/wp-admin/authorize-application.php'
# Bounded slack (0-15 chars) absorbs the scheme prefix in any form (raw or percent-encoded,
# with or without an explicit scheme) so this also catches protocol-relative callbacks
# (success_url=//attacker.example/...), which browsers and many URL validators resolve as
# absolute off-origin targets exactly like a full https:// URL, but which the original
# scheme-anchored regex did not match.
selection_offsite_callback:
Url|re: '(?i)success_url=[^&]{0,15}(//|%2f%2f)'
# Placeholder only: replace with the organization's actual approved integration domain(s)
# before enabling this rule. Never ship or rely on this example value as-is.
# Anchored to the scheme-prefix slack immediately after success_url=, then requires a path
# separator, end of string or next parameter, so it cannot be satisfied by stuffing the
# approved domain string as decoy text elsewhere in the URL, nor by a spoofed subdomain
# suffix such as example-approved-integration.internal.attacker.example.
filter_optional_known_integration_domains:
Url|re: '(?i)success_url=[^&]{0,15}example-approved-integration\.internal([/%]|$|&)'
condition: selection_endpoint and selection_offsite_callback and not filter_optional_known_integration_domains
fields:
- SourceIp
- DestinationIp
- HttpMethod
- Url
- UserAgent
- StatusCode
falsepositives:
- Legitimate third-party WordPress integrations (mobile apps, automation tools, CI/CD plugins) using the standard Application Password authorization flow with a valid off-site callback, tune filter_optional_known_integration_domains to the organization's approved integration domains before relying on this rule
- Administrators manually testing or documenting a legitimate third-party integration
level: medium