ASD Issued a Critical Alert on 9 July for Web CMS Exploitation. Three Questions to Ask Your IT Provider This Week.
If someone looks after your website, firewall and IT, you probably assume they are already watching for critical security alerts. But for many small businesses, that responsibility is split between a web developer, hosting provider, marketing team and IT provider which means nobody is actually checking everything. That matters right now. On 9 July 2026, the Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC) issued a Critical alert about a large-scale campaign targeting vulnerable website content management systems (CMS) and plugins. Just three weeks earlier, ACSC had issued another Critical alert involving Fortinet firewalls and VPN gateways. The two incidents are different, but they point to the same problem: businesses need someone actively checking whether their internet-facing systems are patched, secure and already compromised. This guide explains what the alerts mean, what you should check, and how Byteway can help. What was the ACSC Critical alert in July 2026? On 9 July 2026, ASD’s ACSC published a Critical alert warning about a large-scale global campaign exploiting known vulnerabilities in website CMS platforms and plugins. The campaign includes Australian businesses, with many small and medium-sized businesses already affected. The attack method is relatively straightforward. Attackers automatically scan internet-facing websites looking for software with known vulnerabilities. When they find an unpatched system, they exploit it and can install a webshell — code that gives them persistent remote access to the web server. The affected products include around 17 CMS platforms and plugins, with WordPress plugins representing a major attack vector. Other products mentioned include Craft CMS, Joomla JCE, MaxSite CMS and MetInfo CMS. Once attackers gain access, the website can become more than just a defaced webpage. They may be able to: That last point is particularly important. Your website may be a marketing asset to you, but an attacker can see it as an entry point into your business. The biggest problem isn’t a zero-day There is an uncomfortable detail behind the July alert. The vulnerabilities involved already have patches available. This means businesses are not necessarily being compromised because attackers have discovered an unknown vulnerability. Many are being compromised because known vulnerabilities have not been fixed. The referenced CVEs range from recent disclosures back to vulnerabilities dating as far back as 2020. That creates a simple security lesson: Knowing about a vulnerability is not the same as fixing it. ASD’s ACSC has also noted that the speed and scale of scanning and exploitation may indicate the use of AI-assisted tooling, potentially reducing the time businesses have between a vulnerability being publicly known and attackers attempting to exploit it. For a small business, waiting until someone notices something is wrong is no longer a sensible security strategy. What about the Fortinet Critical alert? The website campaign wasn’t the only recent warning. On 18 June 2026, ASD’s ACSC published an alert concerning a widespread campaign targeting Fortinet firewalls and VPN gateways. The alert was subsequently reissued on 22 June following further analysis from Fortinet. The important distinction is that this is not simply a patching problem. The campaign involved compromised administrator and VPN credentials being reused to access FortiGate devices. That means a business could have a fully patched firewall and still have a problem if exposed credentials have never been changed. For organisations using Fortinet equipment, the practical checks include: Patching and credential rotation are two different security tasks. Fixing the software does not automatically invalidate credentials that may already have been compromised. What should you ask your IT provider this week? You don’t need to understand CVEs, webshells or firewall firmware to have a useful conversation with your IT provider. Ask these three questions. 1. Is our website fully patched? Don’t settle for: “It updates automatically.” Ask: When was it last checked and verified? Your provider should be able to confirm that the CMS, plugins and other internet-facing components are running supported versions and that updates have actually been applied. 2. Have you checked whether we’ve already been compromised? This is arguably the most important question. Patching closes the vulnerability. It does not remove an attacker who may already have access. If a webshell was installed before the patch, it may remain on the server. A proper assessment should therefore look for indicators such as: If evidence of compromise is found, the system should be treated as compromised and investigated rather than simply patched and returned to normal. 3. If we use Fortinet, have all administrator and VPN credentials been rotated? Don’t just ask whether the firewall is patched. Ask whether the relevant credentials have been changed and secured, whether MFA is enforced and whether authentication logs have been reviewed. A clear answer should include when these checks were completed. What if nobody manages your website? This is more common than many business owners realise. Your website might have been built several years ago by a web agency. The agency no longer manages it. Your hosting company manages the server but not the CMS. Your marketing person manages content but not security. Your IT provider manages laptops and Microsoft 365 but has never been given website access. Everyone thinks someone else is responsible. That creates a security gap. If there is no clearly assigned owner, start with these steps: 1. Identify who has access Find out who controls: 2. Update the CMS and plugins Make sure the CMS and all installed plugins are supported and patched. Remove plugins you no longer use rather than leaving unnecessary software installed. 3. Check for existing compromise Don’t assume that updating the software means the site is clean. Have someone appropriately qualified inspect the website and server for signs of unauthorised access. 4. Secure administrator accounts Enable MFA wherever available and eliminate unnecessary administrator accounts. 5. Check your backups Make sure you have a usable backup — and, more importantly, that somebody has tested restoring it. A backup that has never been restored is an assumption, not a recovery strategy. 6. Assign ongoing responsibility Someone should own website security going forward. Not









