Webflow and hosted CMS security guide
Published 4 Nov 2026 · Updated 2026-11-05
Hosted site builders patch their own platform, so there is usually no CMS CVE for you to fix. What remains is yours: custom code and third-party scripts pasted into the site, editor and agency accounts without two-step login, form data flowing to other tools, and an email domain scammers can spoof. Enforcing DMARC and auditing embedded scripts are usually the quickest wins.
Who this is for: Australian organisations whose marketing website runs on a hosted builder such as Webflow, Framer or HubSpot CMS. Written by our collective of Melbourne web and app developers; facts checked against NVD, the CISA KEV catalog and vendor advisories on 2026-11-05. Free to use and share.
Book a free stack check Already breached? First steps
Supported versions
Webflow (hosted)
Webflow (like Framer and HubSpot CMS) is a hosted site builder: the vendor patches the hosting and platform, so there is no platform version for you to update. Your responsibility is custom code embeds, third-party scripts, editor and agency accounts, forms and your email domain.
Source: Webflow (hosted) official lifecycle (checked 2026-11-05).
jQuery
jQuery 3.5.0 (April 2020) fixed the two widely flagged XSS issues below. Many older CMS themes still load jQuery 1.x, 2.x or 3.0 to 3.4 from a CDN; the version is visible in the script URL.
Source: jQuery official lifecycle (checked 2026-11-04).
DMARC set to p=none and email spoofing
What the issue is
DMARC is a DNS record that tells receiving mail servers what to do with email that claims to come from your domain but fails SPF and DKIM checks. A policy of p=none only asks for reports; spoofed messages are still delivered.
Why it matters
Hosted marketing sites are often wired to several email senders (CRM, newsletters, form notifications). Scammers exploit the trust in your domain with fake invoices and login prompts. Without an enforced DMARC policy those messages can reach inboxes.
How to fix it
- List every service that sends email as your domain (mailbox provider, CRM such as HubSpot, newsletter tool, form notifications).
- Publish one SPF record that includes those senders, ends in -all or ~all, and stays under the 10 DNS lookup limit. Anything after the first 'all' is ignored, so remove duplicates.
- Turn on DKIM signing in each sending service.
- Monitor with p=none and a rua= address for a few weeks, then move to p=quarantine and p=reject.
- Follow the ACSC's email security guidance.
Sources: ACSC: How to combat fake emails · RFC 7208 (SPF)
Custom code embeds and third-party scripts
What the issue is
Hosted builders let you paste code into site-wide head/footer settings and page embeds. Every script loaded there (tag managers, chat widgets, trackers, form tools) runs with full access to the page.
Why it matters
This is the main way a hosted site gets malicious code: a compromised vendor script or a script injected via a hijacked editor account can skim form entries or redirect visitors, with no platform vulnerability needed.
How to fix it
- Inventory every script in site-wide and page-level custom code and remove ones you no longer use.
- Prefer scripts loaded through one tag manager with restricted publish rights.
- Use Subresource Integrity (integrity= attributes) for scripts loaded from fixed-version CDN URLs.
- Set a Content-Security-Policy where the platform allows custom headers, or via your CDN.
- Review custom code after every agency engagement.
Sources: OWASP Third-Party JavaScript Management Cheat Sheet · MDN: Subresource Integrity
Editor, designer and agency accounts
What the issue is
Anyone with editor or designer access can publish code to your live site.
Why it matters
Shared or stale agency logins without two-step authentication are an easy route to defacing a site or adding a skimming script.
How to fix it
- Require two-step authentication for every account.
- Give each person their own login; remove shared logins and ex-staff.
- Limit publish rights to the people who need them.
- Review workspace members quarterly.
Sources: Webflow security · HubSpot security
Old jQuery added through custom code
What the issue is
Some themes, templates and custom embeds load their own copy of jQuery. Versions before 3.5.0 are affected by CVE-2020-11023, an XSS issue in HTML handling.
Why it matters
An old library you added yourself is not patched by the platform. Check before assuming you are affected: many builders already ship a patched version.
How to fix it
- Check which jQuery versions the page loads (view source, look for jquery-x.y.z).
- Remove duplicate copies added in custom code, or upgrade them to a current 3.x release.
- Re-test forms and sliders after upgrading.
Sources: NVD: CVE-2020-11023
Key high and critical CVEs for this stack
These are recent high or critical vulnerabilities. "KEV" means CISA lists it as known to be exploited in the wild.
| CVE | Component | Affected | Fixed in | CVSS | KEV |
|---|---|---|---|---|---|
| CVE-2020-11023 | jQuery: XSS when HTML containing <option> elements from untrusted sources is passed to DOM manipulation methods | 1.0.3 up to (not including) 3.5.0 | 3.5.0 | 6.1 (CVSS 3.1, NVD) | Yes (added 2025-01-23) |
| CVE-2020-11022 | jQuery: XSS when untrusted HTML, even after sanitising, is passed to .html(), .append() and similar | 1.2 up to (not including) 3.5.0 | 3.5.0 | 6.1 (CVSS 3.1, NVD) | Not listed |
How attacks on this stack typically work
- Phishing emails that spoof your domain trick customers, donors or staff into paying fake invoices or entering passwords; a DMARC policy of p=none does not stop them.
- A compromised editor or agency account is used to add a malicious script to the site-wide custom code.
- A third-party script (chat, analytics, tag manager, A/B testing) is compromised or abandoned and starts serving malicious code to every visitor.
- Old JavaScript libraries added through custom code can carry known XSS bugs, such as jQuery before 3.5.0 (CVE-2020-11023).
Patch and hardening steps
- Find your exact versions. There is no platform version to find. In your site settings, review the custom code (head and footer) sections and page-level embeds, and list every external script they load. Ask your developer which version of any JavaScript library you added yourself.
- Back up first (files and database), and keep the backup off the server.
- Webflow (hosted): no customer-side patch to apply; review the settings, apps and accounts you control.
- Update jQuery to at least: 3.5.0. Move off any end-of-life branch.
- Remove unused plugins, apps, themes and accounts, and turn on automatic updates for minor and security releases where available.
- Lock down admin: Require two-step authentication for every editor, designer and agency account, remove people who have left, and review which integrations (CRM, forms, analytics) hold API keys for the site.
- Check for signs of compromise after patching a KEV-listed flaw: unknown admin users, unexpected new files on the server, changed checkout or header scripts.
- Follow a patching cadence. The ACSC's Essential Eight treats patching applications as a core mitigation.
What this means for your industry
Healthcare clinics, allied health, legal and accounting practices often run a CMS such as WordPress or Silverstripe for bookings and enquiry forms, which collect sensitive personal information. A compromise can become a notifiable data breach: see data breach help for Australian businesses. Industry-specific guides are coming.
Melbourne or Victorian public-sector supplier? See Melbourne and Victorian breach contacts. We will cover reported incidents involving these technologies in our Australian breach news.
Want a second pair of eyes on your stack?
Book a short call and one of our developers will talk through your versions and patch plan. No pressure, no scare tactics.
Frequently asked questions
Do I need to patch Webflow, Framer or HubSpot CMS?
No. These are hosted platforms and the vendor applies platform security updates. You are responsible for custom code, integrations, accounts and your domain's DNS. Source
What is DMARC and why does p=none matter?
DMARC tells receiving mail servers what to do with email that fails SPF and DKIM checks for your domain. p=none only monitors; quarantine or reject actually blocks spoofed mail. The ACSC recommends configuring SPF, DKIM and DMARC. Source
Are third-party scripts really a risk?
Yes. Any script you embed runs with full access to your pages and form fields, so a compromised vendor can read what visitors type. OWASP recommends inventorying and controlling third-party JavaScript. Source
I think our site or forms were tampered with. What first?
Remove unknown custom code, reset editor passwords and enforce two-step login, review form and CRM integrations, report to the ACSC and assess whether the Notifiable Data Breaches scheme applies. Source
Related stack guides
- Drupal and PHP stack breach guide
- Adobe Commerce (Magento) and PHP stack breach guide
- Next.js, React and Node.js stack breach guide
- PHP + WordPress stack breach guide
- Shopify store security guide
- Silverstripe CMS, PHP and jQuery stack breach guide
- WordPress, PHP and Node.js stack breach guide
- WooCommerce, WordPress and PHP stack breach guide
- All stack security guides
Sources
- webflow.com/security
- github.com/jquery/jquery/security
- nvd.nist.gov/vuln/detail/CVE-2020-11023
- www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-11023
- github.com/jquery/jquery/security/advisories/GHSA-jpcq-cgw6-v4j6
- blog.jquery.com/2020/04/10/jquery-3-5-0-released/
- nvd.nist.gov/vuln/detail/CVE-2020-11022
- www.framer.com/security/
- legal.hubspot.com/security
- www.cyber.gov.au/resources-business-and-government/maintaining-devices-and-systems/system-hardening-and-administration/email-hardening/how-combat-fake-emails
- www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight
General information only, not legal or professional advice. Versions and CVEs change quickly; always confirm against the vendor before acting.