CVE-2026-50571: WebSub: Reflected script execution through intent-verification challenges
WebSub is a W3C recommendation produced by the Social Web Working Group. In recommendation REC-websub-20180123, the intent-verification protocol requires a subscriber to echo the hub.challenge value, also exposed as hubchallenge by some frameworks, but does not require safe response media typing or disabled MIME sniffing. An attacker can initiate a subscription to obtain a callback URL and redirect a victim browser to a crafted verification request containing HTML or JavaScript. Subscribers that return the challenge as text/html can execute the reflected content in the subscriber origin, using a victim's existing session to read private data or perform actions, exposing localStorage or sessionStorage and browser permissions granted to that origin. An alternative uses the verification response as an attacker-controlled same-origin script resource to bypass script-src 'self'; this can remain possible with application/octet-stream when MIME sniffing is allowed. Safe media typing and X-Content-Type-Options: nosniff are both needed to address the described scenarios. WebSub Rocks demonstrated reflection, but the advisory does not establish practical impact on that demonstration site.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Return the hub.challenge response using safe media typing; do not serve the reflected challenge as text/html or application/octet-stream.
WebSub intent-verification response Content-Type = safe media type - Configuration
Set X-Content-Type-Options: nosniff on the verification response to disable MIME sniffing.
WebSub intent-verification response X-Content-Type-Options = nosniff
Event History
Frequently Asked Questions
Which deployments are exposed?
Exposure is limited to WebSub subscribers that reflect the intent-verification challenge in a browser-interpretable response, such as text/html, or otherwise permit the response to be MIME-sniffed as script. The advisory does not state that every WebSub implementation or default configuration is affected.
What does an attacker need to exploit this?
An attacker needs to initiate a subscription to obtain a callback URL and cause a victim browser to visit a crafted verification request. Successful impact depends on the victim having an existing session or browser-granted permissions for the subscriber origin.
What should be changed if patching is not immediately possible?
Return verification challenges with a safe media type and send X-Content-Type-Options: nosniff. Both measures are needed to address the described reflected-content and same-origin script-resource scenarios.
How can I assess whether a subscriber is vulnerable?
Inspect the response to intent-verification requests containing hub.challenge or hub_challenge. A subscriber is at risk if it reflects attacker-controlled challenge content as text/html, or serves it in a way that browsers may MIME-sniff as executable content without X-Content-Type-Options: nosniff.