The ACSC just flagged Wordpress attacks that end at your donation form. Three things to check this week.

Two weeks ago the Australian Cyber Security Centre published a statement, co-signed by every Five Eyes cyber security agency, warning that adversaries are now using AI to automate attacks at a scale defenders cannot match by hand. Six weeks before that, ACSC put out something more specific: a large-scale exploitation campaign against Wordpress and other CMS platforms, hitting legitimate Australian websites. A related advisory in May documented the technique in detail. Attackers inject a payload delivery domain into a real Australian business's website. That injected code overwrites part of the page with a fraudulent Cloudflare verification prompt, and uses it to deliver credential-stealing malware to visitors.

For a business selling shoes, that pattern loses some carts. For a charity, it loses donations, donor trust, and (if any card data was in flight through the compromised page) triggers a mandatory Notifiable Data Breach obligation.

Why charity websites are the softer target

E-commerce sites have fraud teams, PCI-DSS budgets, and web application firewalls in front of everything. Charity websites are typically maintained by a marketing coordinator with a Wordpress admin login and a small stable of plugins whose last-update dates nobody has audited in months. GiveWP or Charitable for the donation form. Contact Form 7 for enquiries. WooCommerce for the merchandise shop that raises three percent of income and holds forty percent of the attack surface. Every one of those plugins is a supply chain the charity did not consciously choose to inherit.

Plus the update-lag culture. Nobody wants to be the person who upgrades a plugin and breaks the donation form the week before the end-of-financial-year appeal. So updates get deferred. Deferred plugins are exactly what the ACSC advisory is describing.

The attack chain, in the shape the advisories document. An attacker finds an old plugin vulnerability, or acquires a leaked admin credential, and drops one line of JavaScript into a template file or a plugin asset. That line loads a much larger script from an external server they control. The external script overwrites part of the donation page. Sometimes it presents a fake Cloudflare check that installs malware. Sometimes it swaps the real payment button for a lookalike that sends card details to the attacker before proxying to Stripe. Sometimes it just adds a keylogger to the checkout form.

None of these are visible to the charity's team because the compromised page still looks right. The donor sees the same charity name in the same brand colour, on the same domain, over the same TLS certificate. The compromise is a script that ran after page load and rewrote a section of the DOM.

Three checks you can do this week without buying anything

1. Every Wordpress plugin's last update date

Log into Wordpress admin, open Plugins, scan the list. Sort by "last updated" if the view supports it. Anything more than 90 days behind its latest release either needs an update or needs to be uninstalled. Plugins you can't identify (something a previous contractor added, or bundled with a theme) go on the uninstall list too. Most Wordpress compromises trace back to an outdated plugin the site owner had forgotten was even installed.

2. What your donation page actually contacts

Open your donation page in an incognito Chrome window. Right-click, Inspect, Network tab, reload the page. Every row is a network request the page made. Look at the Domain column. Every entry should be either your own domain, your fundraising platform's domain (Funraisin, Raisely, Classy, Stripe, GiveNow), or an obvious analytics provider (Google, Facebook Pixel if you use it). Anything else, especially anything that looks like a random string of characters or ends in a country code you don't recognise, is the exact pattern the ACSC advisory describes. If you see one, you have already been compromised.

3. Wordpress admin exposure

If you go to yourcharity.org/wp-admin in an incognito browser and reach a login screen, so can everybody else on the internet. Compromised admin credentials are how a lot of these attacks start. Put wp-admin behind Cloudflare Access, an IP allowlist, or at absolute minimum enforce a mandatory second factor on every account with admin or editor rights. Cloudflare's free tier covers most charity setups.

What to do after the checks

If check two turned up a domain you don't recognise, treat it as an active incident. Take a full-page snapshot of the page as evidence, then disable the responsible plugin (the DevTools Network tab will usually show you which one is loading the injection). Contact your hosting provider. If donor card data was in flight through that page for any length of time, you have a mandatory Notifiable Data Breach obligation under the Privacy Act.

If check two came back clean, book a monthly recurring reminder to do it again on the first of every month. The whole point of the ACSC advisory is that this is not a one-time problem. New plugin vulnerabilities land every week. Your site's clean surface today is not evidence it will stay clean six weeks from now.

If you want the recurring check to run automatically instead of on your calendar, Cause Shield's monthly pen test scan does exactly this against your donation page and emails a plain-English report. It looks for the ACSC-flagged injection patterns, TLS and header hygiene, exposed admin paths, and diffs each month against the previous scan so a new injection stands out against a stable baseline. Available on the Partner tier. Not the point of this article, but if you have been meaning to automate this and had not found a nonprofit-specific option, that is one.

The wake-up call is the ACSC statement, not us

The reason to do the three checks this week rather than next month is that the advisories are describing an active campaign, not a theoretical one. ACSC has watched compromised Australian