When the leak attacks your visitors: Webflow CMS token abuse

A Webflow site token controls what the public sees. Unlike a back-office leak, abuse here hits outsiders: a script injected into the live site attacks every visitor.

How the attack works

The site API token leaks from a build pipeline. The attacker uses it to modify CMS content and custom code from an IP outside the deploy pipeline, adding a script tag to site custom code or a rich-text field and publishing it live, where it executes in every visitor’s browser as a watering hole. The same token then pulls collected form submissions, exfiltrating lead and contact PII via the API. In ATT&CK terms this is T1078, Valid Accounts, and T1565, Data Manipulation, with T1213, Data from Information Repositories, and T1567, Exfiltration Over Web Service, for the form-data theft.

Why it works

The publish token was exposed and broadly scoped, and it could silently alter the live site with no change review or content-integrity monitoring to flag an injected script.

How to fix it

The non-obvious move is that you do not wait for the next deploy window, because every visitor in the meantime is served the watering hole. Containment is urgent and two-part: revoke the token so it cannot re-edit, and republish clean content to strip the malicious script from production now. A Content-Security-Policy tweak or a warning email does not remove the live script. For the class fix, store the publish token in a secret store with rotation and least scope, restrict and review who can publish, and add content-integrity monitoring that alerts on injected scripts. The site activity and publish logs scope the content changes, and the form-submission API logs scope the export.

Practice it

We built this as a GraphLattice Range scenario so teams can rehearse the live-site injection, the revoke-and-republish-clean containment, and the dual duty of third-party visitor harm plus form-PII notification.