We pwned X, Vercel, Cursor, and Discord through a supply-chain attack
TL;DR Highlight
Mintlify's AI docs platform had an internal endpoint validation gap that allowed injecting malicious JavaScript into customer domains like discord.com and docs.x.com.
Who Should Read
Security engineers reviewing SaaS platforms with white-label or custom domain features, and frontend security practitioners.
Core Mechanics
- Mintlify hosts documentation for major tech companies (Discord, X, etc.) and allows custom domains — the vulnerability let an attacker inject arbitrary JavaScript into those customer-owned domains.
- The root cause was insufficient validation of internal API endpoints that were accessible with lower privilege levels, allowing content injection that bypassed CSP for affected domains.
- The injected scripts could steal session tokens, perform phishing, or exfiltrate data from users of the affected documentation sites.
- The scope was significant: any visitor to the affected documentation pages (including enterprise customers' internal docs) could have been targeted.
- Mintlify patched the issue after responsible disclosure, but the exploit window is unknown.
Evidence
- The researcher provided a working proof-of-concept showing malicious JS executing on docs.x.com and discord.com domains.
- HN commenters noted this is a common class of vulnerability in white-label SaaS — the aggregation risk of one platform serving many high-value domains.
- Concern was raised about supply chain implications: documentation sites often load third-party analytics, fonts, and chat widgets — an XSS here could pivot to those.
- Several security engineers noted the specific risk of doc site XSS: developers are often logged in to internal tools while reading docs, making session hijacking especially valuable.
How to Apply
- If you use a third-party docs platform (Mintlify, GitBook, ReadMe, Docusaurus hosting), verify that your custom domain isn't vulnerable to content injection via the platform's admin APIs.
- Apply strict CSP headers on your documentation domains — even if you don't control the underlying platform, you can limit what scripts can execute.
- For internal documentation sites: treat them with the same security rigor as your main product — they're often logged into by engineers with broad access.
- Audit your white-label SaaS vendors for the same class of vulnerability — any platform serving your domain is a potential XSS surface if their internal validation is weak.
Code Example
snippet
# CSP header example - applied to third-party proxy path
# nginx configuration
location /_mintlify/ {
add_header Content-Security-Policy "default-src 'none'; img-src 'self'; style-src 'self'; script-src 'none'; sandbox;";
proxy_pass https://upstream.mintlify.app;
}
# Block code generation from strings when running Node.js
node --disallow-code-generation-from-strings server.jsTerminology
XSS (Cross-Site Scripting)A vulnerability where an attacker injects malicious JavaScript into a web page that executes in victims' browsers, enabling session theft and data exfiltration.
CSP (Content Security Policy)A browser security mechanism that restricts which scripts, styles, and resources can load on a page — effective at limiting XSS damage.
White-label SaaSA SaaS product where customers use their own branding and domain name, but the underlying platform is shared — creating aggregated risk if the platform is compromised.