Patched a Year Ago, Hacked This Week: WordPress in Fall 2025

In October 2025, attackers sent millions of requests at WordPress plugin vulnerabilities that had been fixed a year earlier, and a lot of those requests found sites that had never installed the fix. Over the next two months the same thing happened again with newer bugs. This article looks at what happened, why known WordPress plugin vulnerabilities keep working long after the patch ships, and gives you a practical hygiene checklist for your marketing sites.

What happened: a timeline of the fall 2025 attack wave

These were not zero-days. In every case below, a fixed version was available before attackers showed up in volume. The problem was the sites that never installed it.

October: GutenKit and Hunk Companion, patched in 2024

According to BleepingComputer's report on the mass attacks against outdated WordPress plugins, Wordfence blocked 8.7 million exploit attempts on October 8 and 9, 2025. The targets were three critical flaws (each rated 9.8 on the Common Vulnerability Scoring System, or CVSS):

• GutenKit (CVE-2024-9234), a page-builder plugin with 40,000+ active installations, was fixed in version 2.1.1 in October 2024.
• Hunk Companion (CVE-2024-9707 and CVE-2024-11972), with 8,000+ installations, was fully fixed in version 1.9.0 in December 2024.

All three bugs let an unauthenticated visitor get a site to install a plugin. Security Affairs' summary of the Wordfence findings explains that attackers used this to plant malicious plugins containing obfuscated PHP backdoors, which gave them remote code execution. SecurityWeek's coverage of the year-old plugin flaws put it plainly: although the vulnerabilities "were patched over a year ago, they continue to represent attractive targets for threat actors."

November: King Addons for Elementor

King Addons for Elementor, used on more than 10,000 sites, had a privilege-escalation flaw (CVE-2025-8489, CVSS 9.8). Anyone could register an account and give it the administrator role. BleepingComputer's coverage of the King Addons attacks lays out the timeline:

• September 25, 2025: version 51.1.35 ships with the fix.
• October 30, 2025: the flaw is publicly disclosed.
• October 31, 2025: exploitation begins the next day.
• November 9–10, 2025: attacks peak. Wordfence had blocked more than 48,400 attempts by early December.

Sites that updated in late September were safe. For sites that hadn't, the risk went from theoretical to active within about 24 hours of the public write-up.

Late November: Sneeit Framework

The Sneeit Framework plugin, which ships with a family of magazine-style themes, had an unauthenticated remote code execution flaw (CVE-2025-6389, CVSS 9.8) in versions up to 8.3. The Hacker News report on Sneeit exploitation says version 8.4 fixed it on August 5, 2025. Exploitation started November 24, and Wordfence blocked more than 131,000 attempts. Attackers created rogue administrator accounts and uploaded backdoor PHP shells. The plugin has only about 1,700 active installations, which shows that attackers will go after small plugins too.

Also on the list: ACF Extended

Advanced Custom Fields: Extended, used on roughly 100,000 sites, fixed an unauthenticated remote code execution flaw (CVE-2025-13486, CVSS 9.8) in version 0.9.2 in November. Some roundups, such as 365i's December 2025 list of critical plugin vulnerabilities, group it with the flaws under attack. But the Jamaica Cyber Incident Response Team's December 9 alert described it as "not yet exploited." Either way, the lesson is the same. A public, unauthenticated, critical bug in a plugin with six-figure installs is exactly what the next wave will target, so update it now rather than after the first attack reports.

Why known WordPress plugin vulnerabilities stay exploitable

The pattern is consistent: the patch comes out, the details go public, and exploitation follows. Whether that takes days or a year depends on how many sites are still unpatched and still worth scanning for. Several structural reasons keep that number high.

Plugin auto-updates are off unless someone turns them on

WordPress added plugin and theme auto-updates in version 5.5, but the WordPress core team's announcement of the auto-update controls notes that "plugin and theme auto-updates are disabled by default." Unless someone switched them on, every plugin fix waits for a person to log in and click Update. On marketing sites, that person is often an agency that finished the build months ago.

The attack surface is plugins, and it keeps growing

Patchstack's State of WordPress Security in 2025 report counted 7,966 new vulnerabilities in the WordPress ecosystem in 2024. 96% were in plugins, and only 7 were in WordPress core. It also found that 43% required no authentication to exploit, and 33% were not fixed in time for public disclosure. The Patchstack 2025 mid-year vulnerability report counted about 6,700 new vulnerabilities in the first half of 2025 alone, and put the share that "can be automatically exploited by a complete outsider" at 57.6%.

Abandoned and forgotten plugins

Patchstack's 2025 report says 1,614 plugins and themes were removed from WordPress.org in 2024 because of unpatched security issues. A removed plugin keeps running on every site that already has it installed. It stops getting updates, and nothing in the dashboard makes its status obvious. Deactivated plugins that are still installed are a related blind spot: they are easy to forget, and their files are still on the server.

Generic firewalls miss WordPress-specific exploits

Many site owners assume their host handles security. In its review of Q3 2025's most exploited WordPress vulnerabilities, Patchstack reported that 87.8% of the attacks it tested got past host-level protections. Network firewalls are useful, but they rarely understand what a specific plugin's REST endpoint or AJAX action is supposed to accept.

What a compromised WordPress site means for a marketing team

For a marketing team, a hacked WordPress site is a business problem as well as a security one. The payloads in this wave (rogue administrator accounts, backdoors and file managers) give an attacker lasting control. Common results include spam or redirect injections that damage organic rankings, landing pages quietly altered or used to host phishing, and form submissions or tracking tags tampered with. Paid traffic can end up on a compromised page, and ad platforms and browsers may flag the site before anyone on the team notices.

Mass exploitation also creates a lot of junk traffic. Millions of automated probe requests across the web mean your server logs, and sometimes your analytics, pick up requests that were never real visitors. That's one more reason to know what share of your traffic is automated. Our explainer on how ad fraud works covers the ad-side version of the same bot problem.

A practical WordPress security checklist for marketing sites

None of these steps require exotic tooling. Most of them just need someone to own them on a schedule.

1. Inventory every plugin and theme. List what is installed on each site, including deactivated items, bundled "framework" plugins that came with a theme, and anything installed by a past agency. You can't patch what you don't know you have.
2. Delete what you don't use. Deactivating a plugin is not enough. If a plugin isn't needed, remove it from the server.
3. Turn on auto-updates for low-risk plugins. Since auto-updates are off by default, enable them for plugins where a failed update wouldn't break revenue pages. Test the rest on staging, but on a weekly cadence rather than "whenever someone remembers."
4. Check premium and bundled plugins separately. Plugins sold outside WordPress.org or bundled with themes often update through their own license system. Confirm license keys are active so updates actually arrive.
5. Watch for abandoned plugins. If a plugin hasn't been updated in a long time or has been removed from the directory, plan to replace it.
6. Subscribe to vulnerability alerts. Follow a WordPress-focused vulnerability feed such as Wordfence Intelligence, Patchstack or WPScan, so a critical disclosure reaches you within a day. The King Addons timeline shows why a day matters.
7. Audit administrator accounts. Review every user with the Administrator role and remove any you don't recognize. Wordfence's guidance after the King Addons attacks, quoted in The Hacker News coverage of the King Addons flaw, was to "audit their environments for any suspicious admin users." Turn off open registration if you don't need it, and check that the default role for new users isn't anything above Subscriber.
8. Check file integrity. Compare WordPress core and repository plugin files against official checksums (WP-CLI has commands for this), and look in the plugins folder for directories nobody installed. In the GutenKit and Hunk Companion campaign, the malicious code arrived as extra plugins.
9. Enforce strong authentication. Use unique passwords and two-factor authentication for every admin and editor account, and remove accounts for staff and agencies who no longer need access.
10. Keep tested backups offsite. Make sure you can restore a clean copy quickly. A backup you have never restored is untested.
11. Review logs after big disclosures. When a plugin you run is in the news, check access logs for requests to its endpoints around the disclosure date, even if you have since updated.

If you think a site was already hit

Updating a plugin closes the hole but does not remove anything an attacker has already left behind. A rogue administrator account or a backdoor plugin will survive the update. If a site ran a vulnerable version during an active campaign:

• Look for unfamiliar administrator accounts and recently created users.
• Look for plugins and PHP files you didn't add, especially recently modified ones.
• Reset passwords and security keys (salts) after cleanup, not before.
• If you find signs of compromise, restore from a known-clean backup or bring in a professional incident responder rather than deleting files one at a time.

Patch speed is the difference

The fall 2025 wave did not depend on new techniques. It depended on WordPress plugin vulnerabilities that were already fixed and on sites that had not caught up. Attackers exploited GutenKit and Hunk Companion a year after the patches, Sneeit almost four months after, and King Addons about five weeks after. In every case, the sites that were safe were the ones that had updated. A written inventory, a weekly update routine and a regular admin-user audit would have covered all of them.

Patching keeps attackers out of your CMS. To see how much of the traffic reaching your marketing site is automated, Ðeny classifies every visit in real time as clean, good bot, residential proxy, invalid traffic (IVT), out-of-geo or AI agent, and breaks it down by channel. Explore the Ðeny feature overview or request a demo of Ðeny to see it on your own traffic.