[HackerNotes Ep. 160] Cloudflare Zero-days & Mail Unsubscribing for XSS

A bunch of very interesting research writeups from Cloudflare WAF bypass to Parser discrepancies.

Author

Aituglo ‎
February 05, 2026

Hacker TL;DR

  • Cloudflare WAF bypass: requests to /.well-known/acme-challenge/<token> could disable WAF filtering if the token matched any active ACME challenge across Cloudflare’s infra; path traversal then reached protected origin paths (e.g., /actuator/env).

  • SMTP “List-Unsubscribe” header as an exploit primitive: injecting non-HTTP schemes (e.g., javascript:) can yield stored XSS (Horde mail, CVE-2025-68673); unsubscribe flows can also trigger SSRF (Nextcloud).

  • Managed Postgres escalation pattern: overwriting functions that are later auto-invoked by provider “super users” can hand attackers superuser execution context.

  • Parser discrepancies in Content-Type handling: list-based vs singleton header fields + “last match wins” behaviors can cause backend “JSON” validation while browsers interpret as text/html, enabling XSS (Chrome/Firefox).

  • LLM “magic refusal” string: a documented test string that forces Claude refusals can be used as a denial-of-service vector if injected into persistent conversation history or returned via tool/MCP outputs.

    A gift from Google!

  • Google Cloud VRP Swag Bonus: Mention Critical Thinking Bug Bounty Podcast in any rewarded (cash or credit) VRP report submission before the end of April to receive bonus swag!

Cloudflare: /.well-known/acme-challenge/ token → WAF bypass + path traversal

So the condition here was surprisingly simple: a request to /.well-known/acme-challenge/<token> could flip Cloudflare WAF inspection off for that request path. Token matching wasn’t bound to the target domain; if your <token> matched any active ACME challenge across Cloudflare infrastructure, that was enough to trigger the bypass.

The exploit shape described was basically:

  • Generate/obtain your own valid ACME challenge token.

  • Send a request to the victim domain using that token in the .well-known/acme-challenge path.

  • Append path traversal sequences after the token to reach protected origin paths (like /actuator/env).

Operationally, the impact lands on customers who depend on Cloudflare WAF rules as their main line of origin protection.

SMTP List-Unsubscribe header as XSS/SSRF gadget

To be honest, List-Unsubscribe keeps showing up as a really clean exploit primitive because it’s standardized and tends to get wired into “click this link” flows in UIs and server-side automation. The attack surface is the header itself, which can include mailto: and HTTP URIs.

For stored XSS (Horde mail), the writeup described putting a javascript: URI into List-Unsubscribe. When the unsubscribe link renders in an administrative/backend UI, it can execute script by clicking on it. The referenced CVE is CVE-2025-68673 (stored XSS in Horde mail).

For SSRF (Nextcloud), the unsubscribe action makes a server-side request to whatever URI is in List-Unsubscribe. Internal targeting is configuration-dependent: internal hosts were only reachable if allow local remote servers is set to true.

Hunting takeaway: anywhere list-unsubscribe is supported, test SSRF target URIs and blind-XSS payloads embedded in that header.

Heroku Postgres: function overwrite → provider superuser execution

This one is a managed-service escalation pattern more than a single bug. Providers run background metrics/health collection using privileged access (the “super user” role in the writeup framing). If a tenant can overwrite a function that is later automatically called by that privileged account, then the tenant-controlled function body runs under the provider’s superuser context.

End result, as described: privileged execution translates into attacker-side elevated permissions.

We do subs at $25, $10, and $5, premium subscribers get access to:

– Hackalongs: live bug bounty hacking on real programs, VODs available
– Live data streams, exploits, tools, scripts & un-redacted bug reports

Parser discrepancies: list-based vs singleton fields → MIME confusion → XSS (Chrome/Firefox)

This one came from our lab that you can see here : https://lab.ctbb.show/

The core primitive is parser disagreement: different components parse the same header value into different “effective” MIME types. The focus was Content-Type (and similar headers) that might be treated either as list-based fields (multiple values) or singleton fields (a single value expected), with the edge cases constrained by RFC ABNF.

The discrepancy described builds on MIME validation research: something like application/json; , text/html can pass backend validation as “JSON”, while browsers interpret the content as text/html, which opens an XSS path.

Practical artifact mentioned: a summary table comparing libraries vs browsers in how they parse/validate singleton vs list fields, intended as a hunting map for other stacks that will split on the same boundary.

That was a very interesting research that you should look into.

Claude “magic string” refusal trigger as an application DoS primitive

Anthropic documents a specific test string that triggers a refusal stop reason when streaming classifiers come. So if that “magic string” is inserted into an LLM app’s context (for example via indirect prompt injection), you can force responses into refusal.

The nasty part is the “sticky” failure mode described: if the poisoned turn persists in conversation history, future turns keep refusing until the application drops or rewrites the offending content. Potential delivery points called out include user-controlled fields (like username/email), tool outputs, or MCP server responses.

This was presented as a multi-step chain that ends in remote code execution in an Android app. The steps, in order:

  1. Deep link trust bypass: the app trusted all subdomains of google.com.

  2. WebView exposure: the internal browser exposed a JS native message handler (via postMessage), gated by a registration/handshake flow; the discussion ultimately constrained this to Google origins.

  3. Bridge abuse: once initialized, an attacker could invoke native actions from the WebView JS context (e.g., window.nativeMessageHandler.<function>).

  4. Arbitrary file write via path traversal: the file name was concatenated onto a cache-directory path with insufficient validation.

  5. React Native OTA update hijack: path traversal was used to overwrite OTA-related config and plant a malicious JS bundle; on restart, the OTA loader reads the compromised config and loads the attacker bundle.

A deployment trick mentioned was using sites.google.com to host attacker-controlled content inside an iframe, leveraging the google.com trust decision. Post-exploitation actions described included reading auth tokens from keychain/manager, accessing files from database/files directories, and exfiltrating to attacker-controlled infrastructure.

As always, keep hacking!

Resources