A companion plugin is supposed to make your theme easier to use, not hand attackers the keys to your entire site. Yet that is exactly what happened with Hunk Companion, a plugin installed on more than 10,000 WordPress sites to power the demo-import and widget features of ThemeHunk themes. A flaw tracked as CVE-2024-11972 let unauthenticated attackers reach into a site and silently install and activate any plugin from the WordPress.org repository — including old, vulnerable, and already-removed plugins that could then be used to run arbitrary code. It carries a CVSS score of 9.8 (Critical), and it has been exploited in the wild.
If you run a ThemeHunk theme or have Hunk Companion installed, this is one to take seriously. Here is what the vulnerability is, how it works, and exactly what to do about it.
CVE Details
- CVE ID: CVE-2024-11972
- Plugin: Hunk Companion (by ThemeHunk)
- CVSS 3.1 Score: 9.8 (Critical) — Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Vulnerability type: Broken authorization on a REST API endpoint, leading to unauthenticated arbitrary plugin installation and activation (and, in practice, remote code execution)
- Affected versions: All versions before 1.9.0
- Patched version: 1.9.0
- Active installs: 10,000+
- Exploited in the wild: Yes
It is worth noting that this issue has a history. A closely related flaw was previously reported as CVE-2024-9707 and was supposed to be fixed in version 1.8.5, but the fix was incomplete. CVE-2024-11972 is the follow-up: the same class of problem, properly addressed only in 1.9.0.
How the vulnerability works
WordPress plugins can register their own REST API endpoints — custom URLs under /wp-json/ that accept requests and perform actions. Every endpoint is supposed to include a permission callback: a small function that runs first and decides whether the person making the request is actually allowed to do what they are asking. If the permission callback says no, WordPress rejects the request before any real work happens.
Hunk Companion registered an import endpoint (roughly /wp-json/hc/v1/themehunk-import) used to set up theme demo content, which can include installing helper plugins. The problem was that the permission check on this endpoint was not implemented correctly. Instead of verifying that the request came from a logged-in administrator with the right capabilities, the endpoint could be reached by anyone — no login, no password, no nonce. The check that was meant to protect it could be bypassed entirely.
Because that endpoint is capable of installing and activating plugins pulled directly from the WordPress.org repository, an unauthenticated attacker could tell the site: “install this plugin, and turn it on.” To exploit it, an attacker needs nothing more than the ability to send an HTTP request to the site — something any script on the internet can do. There is no user interaction required and no special access needed.
On its own, installing a plugin is bad enough. But attackers took it a step further. In the observed campaigns, they used Hunk Companion to install an old, abandoned plugin that carried its own remote code execution flaw (for example, an outdated version of WP Query Console). Once that vulnerable plugin was active, they chained the two together: Hunk Companion got the malicious plugin onto the site, and the malicious plugin let them execute arbitrary PHP code. From there the attacker effectively owns the server.
Real-world impact
This is not a theoretical concern. Security researchers documented active exploitation, and Wordfence later reported millions of blocked attack attempts as the flaw was folded into large-scale automated campaigns targeting multiple plugins at once. When an unauthenticated attacker can install arbitrary plugins and reach code execution, the potential damage covers essentially everything:
- Full site takeover: Attackers can create hidden administrator accounts and lock you out of your own site.
- Backdoors and web shells: Malicious PHP planted on the server survives plugin removal and lets attackers return at will.
- Data theft: Customer records, order details, email addresses, and password hashes in the database can be exfiltrated.
- Malware and spam injection: Visitors get redirected to scam pages, or your site starts serving malware and gets blacklisted by Google.
- Defacement or destruction: Content can be altered or wiped entirely.
Because the attack is unauthenticated and easily automated, bots scan the entire internet for vulnerable sites indiscriminately. A small business site is just as likely to be hit as a large one — the attackers do not care who you are, only that the door is open.
How to check if you’re affected
You are potentially affected if Hunk Companion is installed on your site at any version below 1.9.0. Here is how to confirm:
- Log in to your WordPress dashboard and go to Plugins → Installed Plugins.
- Look for Hunk Companion in the list. It often comes bundled as a recommended companion for ThemeHunk themes, so you may have it even if you do not remember installing it directly.
- Check the version number shown beneath the plugin name. If it reads anything below 1.9.0, you are vulnerable and need to act.
Because this flaw was actively exploited, also look for signs that your site may already have been targeted: plugins you do not recognize (especially obscure or long-abandoned ones), administrator accounts you did not create, unexpected files in your wp-content directory, or unusual outbound traffic. If you find any of these, treat the site as compromised and move to incident response rather than a simple update.
How to fix it
The core fix is simple: update Hunk Companion to version 1.9.0 or later. The 1.9.0 release corrects the permission handling on the vulnerable REST API endpoint so unauthenticated requests can no longer install plugins.
- Go to Dashboard → Updates or Plugins → Installed Plugins and update Hunk Companion immediately if an update is available.
- Confirm the installed version now reads 1.9.0 or higher.
- Consider enabling automatic updates for this plugin so future security fixes install without delay.
- If you are not actively using the plugin’s import or widget features, the safest option is to deactivate and delete it entirely. A plugin that is not installed cannot be exploited.
Beyond the update itself, a few hardening steps reduce your exposure to this whole class of REST API authorization flaws:
- Put a web application firewall (WAF) in front of your site. A good WAF can block malicious requests to abused REST endpoints even before you have patched.
- Audit your installed plugins. Remove anything you are not using, and be wary of abandoned plugins that no longer receive updates.
- Enforce least privilege. Keep the number of administrator accounts small and use strong, unique passwords with two-factor authentication.
- Monitor for new admin accounts and plugin changes so that if something does slip through, you notice quickly.
Takeaway
CVE-2024-11972 is a textbook reminder that a missing or broken permission check on a single REST API endpoint can compromise an entire website. It is also a reminder that “patched” is not always the same as “fixed” — the first attempt at this flaw left the door open, and attackers noticed. Keep your plugins updated, remove the ones you no longer need, and treat any plugin capable of installing other software as high-value real estate that deserves extra scrutiny. Consistent update hygiene and a firewall in front of your site remain the two most reliable ways to stay ahead of automated WordPress attacks.