Australia’s cyber agency has warned that attackers are exploiting known content management system and plugin flaws at scale to plant webshells on public websites, turning ordinary business sites into remote-control points for credential theft, malware delivery, disruption, and deeper network compromise.
The critical alert, published July 9 by ASD’s Australian Cyber Security Centre, is aimed at website owners and administrators rather than only large security teams. The agency says many small and medium-sized Australian businesses have already been affected, and the activity is global. BleepingComputer reported the warning more broadly on July 11, highlighting the same webshell-driven attack pattern.
The useful way to read the alert is not as another generic “keep WordPress updated” reminder. ACSC named a concrete set of exploited CMS products and plugins, most of them WordPress-related, and described the attacker workflow: scan public sites, exploit already-known vulnerabilities, upload a webshell, then use that foothold for persistence or follow-on activity.
The affected CMS and plugin stack is broad
ACSC’s list includes WordPress plugins and site components such as Simple File List, WavePlayer, BerqWP, WPBookit, Ninja Forms, ThemeREX Addons, Breeze Cache, pay-uz, ACF Extended, Sneeit Framework, WPvivid Backup, Gravity Forms, and GutenKit/Hunk Companion. It also names Craft CMS, MaxSite CMS, MetInfo CMS, and Joomla JCE.
The vulnerability classes matter because they explain why the campaign is moving quickly. ACSC says the exploited bugs primarily involve unauthenticated file upload, remote code execution, server-side request forgery, or deserialization. For a public website, those are not theoretical risks. They can give an attacker a direct path to place executable code on the server or make the CMS process hostile input in a way that leads to code execution.
Several examples show the pattern. CVE-2026-0740 in the Ninja Forms File Uploads plugin involves missing file type validation that can let unauthenticated attackers upload arbitrary files. CVE-2026-3844 in Breeze Cache is also an arbitrary-file-upload flaw, though NVD notes it depends on the “Host Files Locally – Gravatars” setting being enabled. CVE-2026-48907 in the Joomla JCE editor extension can allow unauthenticated users to create editor profiles and ultimately upload and execute PHP code. Craft CMS patched CVE-2025-32432 in versions 3.9.15, 4.14.15, and 5.6.17 after a Yii-related remote-code-execution issue.
Why webshells change the response
A vulnerable plugin can be patched quickly; a compromised server may not be clean just because the plugin version changes. That is the core operational point in ACSC’s alert.
A webshell is usually a small script placed somewhere the web server can execute it. On PHP-based CMS platforms, that can mean a suspicious PHP file inside a plugin directory, theme directory, upload path, cache folder, or other writable web directory. Once active, the webshell can receive web requests and run commands, upload more files, read local data, or act as a bridge into systems reachable from the website host.
That is why site owners should treat this campaign as both a patching event and a compromise check. If an attacker already uploaded a shell, updating the original plugin may close the front door while leaving a side door on the server.
What site owners should check first
Start with a plugin and platform inventory. For WordPress sites, check whether any of the named plugins are installed, active, inactive but still present, or bundled through a theme. Inactive plugins should not be ignored; if the files remain on disk and the vulnerable endpoint is reachable, the site may still have exposure depending on the flaw and configuration.
- Update the CMS core, plugins, themes, and extensions, with priority on the ACSC-named products.
- Remove unused plugins and themes rather than leaving old code installed.
- Confirm whether the site uses Ninja Forms File Uploads, Breeze Cache, WPvivid Backup, Gravity Forms, ACF Extended, GutenKit/Hunk Companion, or Joomla JCE.
- For Breeze Cache, check whether local Gravatar hosting is enabled, because that setting affects exploitability for CVE-2026-3844.
- For Craft CMS, verify that the site is on a patched branch: 3.9.15, 4.14.15, 5.6.17, or later.
After patching, review the file system. Look for recently created or modified files in web-accessible directories, especially PHP files that do not match the plugin, theme, or CMS package. Upload folders deserve close attention because many sites allow media writes there but should not execute server-side scripts from that location.
How to look for webshell activity
ACSC recommends inspecting web directories for abnormal changes, reviewing web access logs for GET or POST requests to suspected webshell paths, and looking back in time for the first suspicious request that may have dropped the file. That history matters because it can show whether the attacker merely tested access or spent time issuing commands.
Practical indicators include newly created PHP files with short or random-looking names, files that contain functions commonly used to execute commands, unexpected writes under plugin or cache directories, and repeated POST requests to files that are not normal CMS endpoints. Administrators should also check whether new CMS users, FTP accounts, SSH keys, scheduled tasks, cron jobs, or hosting-panel users appeared around the same time.
Network and host logs matter after the first webshell is found. A compromised website may have contacted attacker infrastructure, downloaded additional payloads, reached internal systems, or attempted credential access. On hosted sites, that may require help from the hosting provider or managed service provider because the website owner may not have access to server, firewall, process, or outbound connection logs.
Do not just delete the suspicious file
If a webshell is confirmed, the safer path is to isolate the site, preserve logs, identify the initial vulnerability, remove malicious files, rotate exposed credentials, and restore from a known-good backup if there is uncertainty about the server state. Database credentials, CMS administrator passwords, mail-service API keys, payment plugin secrets, SFTP accounts, hosting-panel logins, and connected cloud tokens should be reviewed and rotated where exposure is plausible.
For small businesses that outsource website maintenance, the right immediate question for the provider is direct: did you check for webshells and unauthorized file creation, or did you only apply updates? A clean patch report is useful, but this campaign calls for evidence of file-system review, log review, and backup integrity.
Controls that reduce the next exposure window
The most durable fix is to reduce how much of the website can write and execute code. ACSC recommends making web directories read-only where possible, monitoring new file creation when read-only enforcement is not feasible, restricting access to sensitive paths, and monitoring unexpected child processes spawned by the web server.
For WordPress and similar CMS deployments, that usually means separating upload paths from executable code, disabling PHP execution in uploads where the hosting stack supports it, limiting plugin installation rights, using automatic security updates when rollback risk is acceptable, and keeping a current inventory of plugins, themes, owners, versions, and business purpose. If nobody can explain why a plugin is installed, it should probably not be on a production site.
The campaign also shows why CMS security cannot be treated as a low-priority marketing-site chore. A public website often touches customer data, email systems, analytics accounts, payment tools, CRM integrations, and internal network paths. Once attackers have a webshell, the site is no longer just a defaced page risk. It becomes an internet-facing foothold that may sit quietly until someone looks for it.
