WebSub CVE-2026-50571

Exploitation requires a subscriber implementation that returns the hub.challenge value with a dangerous content-type - specifically text/html (the default in many web frameworks), or application/octet-stream when MIME sniffing is not disabled - because the advisory states that both safe media typing and X-Content-Type-Options: nosniff are needed to close the scenarios. The attacker must first initiate a WebSub subscription on the target subscriber (using the attacker's own session) to obtain a valid callback URL, and the victim must hold an active session on the subscriber origin and must click the attacker's crafted verification URL (UI:R) for session-abuse impact. Limiting factors that reduce realistic risk: the required victim interaction, the need for an exploitable default/misconfigured content-type on the specific subscriber, and the fact that subscribers that already set a safe media type plus nosniff are not affected.

This is a CWE-79 reflected XSS in the WebSub intent-verification flow with a vendor CVSS 3.1 base score of 5.7 (AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N), placing it in the medium band, and the vuln.today decision label is 'this_month' rather than act_now/emergency - so this is a schedule-and-fix item, not a drop-everything emergency. The signals are mostly concordant toward moderate real-world risk: network vector and low complexity are offset by the requirement for user interaction (UI:R, the victim must follow a crafted link) and by the attacker first having to initiate a subscription to obtain a valid callback URL. It is NOT listed in CISA KEV, so there is no confirmed active exploitation, and no EPSS score was provided in the input, so probabilistic exploitation likelihood cannot be weighed here. One internal inconsistency should be flagged: the provided vector sets C:N, yet the advisory's impact section describes reading private data and exfiltrating localStorage/sessionStorage - that is a confidentiality impact, so the C:N rating appears understated and I rate confidentiality as High in my independent assessment below. Overall this is a legitimate but conditional web-application flaw whose severity depends heavily on how individual subscriber implementations set their response content-type; it is a real priority for teams running WebSub subscribers but not a high-urgency mass-exploitation threat on current evidence.

An attacker registers a WebSub subscription against a target subscriber application to obtain a valid callback URL, then builds a verification URL whose hub.challenge parameter contains a <script> payload and lures a victim who holds an authenticated session on that subscriber to click it (UI:R). Because many web frameworks return the echoed challenge as text/html by default, the subscriber reflects the payload and the browser executes it in the subscriber's origin, letting the attacker act as the victim and read origin-scoped storage. A public PoC demonstration exists - the reporter demonstrated reflection on WebSub Rocks - but the advisory explicitly states it did not establish practical impact on that demonstration site.