The flaw that isn't in the code

It helps to be precise about what a misconfiguration is, because it is a different animal from the vulnerabilities we usually write about. A software vulnerability — like the zero-days we covered recently — is a mistake in the code itself. The vendor writes a patch, you install it, the hole closes. A misconfiguration is a mistake in the settings. The software is working exactly as designed and exactly as instructed; the instructions were simply wrong, or were never given at all, and the system stayed however it arrived out of the box.

That difference matters for one blunt, practical reason: nobody is coming to fix it for you. There is no CVE number, no Patch Tuesday, no vendor email. Your settings are yours, and only two parties will ever review them — you, or an attacker.

The usual suspects appear in incident reports year after year:

• Default credentials. Routers, cameras, printers, NAS drives and admin consoles still accepting the username and password printed in the manual — the same manual everyone else received.

• Public cloud storage. Buckets and file shares flicked to "public" during some long-forgotten project and never flicked back, quietly serving sensitive files to anyone holding the URL.

• Exposed databases. Database servers stood up without authentication and left facing the internet, where specialised search engines index them within days.

• Forgotten front doors. Dormant subdomains, test environments and unused APIs that were never decommissioned — online, unmonitored, and absent from everyone's mental map.

• Over-generous permissions. Accounts, keys and services able to touch far more than they need, so that one small compromise becomes a large one.

None of these requires an exploit. Most require nothing more sophisticated than noticing.

 

Read more: Guide to cloud vulnerabilities

 

The copy-paste key: what Sitecore taught everyone in 2025

If you want a single story that captures how a default becomes a disaster, 2025 supplied it. Sitecore is an enterprise content management platform used by large organisations worldwide. For years, its official deployment guides — versions from 2017 and earlier — included a sample ASP.NET machine key: the cryptographic value a web server uses to tell its own data from a forgery. The documentation meant it as a placeholder. Administrators around the world, following the instructions faithfully, copied it straight into production. Every one of those installations now shared the same secret, and the secret was printed in a public document.

In 2025, somebody cashed it in. Investigators at Mandiant caught an attacker using the published key to sign malicious payloads that Sitecore servers accepted as their own and obediently executed — unauthenticated remote code execution against internet-facing systems. The configuration flaw was assigned CVE-2025-53690 with a critical severity score of 9.0, and the US cyber agency CISA added it to its Known Exploited Vulnerabilities catalogue within a day. The intruder did not stop at the front door, either: Mandiant watched them plant reconnaissance malware, harvest credentials and begin moving laterally through the victim's network.

The detail worth sitting with is that nothing was broken. The code performed flawlessly. The key did exactly what keys do. The failure was a copy-paste from official documentation, replicated across countless organisations and left sitting harmlessly for the better part of a decade — until it wasn't. Microsoft had warned earlier that year that thousands of machine keys circulating in public code samples were being abused the same way. Sitecore's remedy says everything: new deployments now generate a unique key automatically. The setting people should have changed is now changed for them.

The Australian picture

Australia does not need to import examples. The Optus breach of September 2022 — 9.5 million current and former customers, roughly a third of the country — is, in the regulator's telling, a story about a door left open. In its Federal Court filings, the ACMA alleges the attacker came through a dormant, internet-facing API whose access controls had been broken by a coding error made in 2018. Optus found and fixed the error on its main website domain in 2021, the ACMA says, but missed the same flaw on a forgotten subdomain — and the domain itself, no longer needed, was left online for years rather than decommissioned. When the attacker finally arrived, they simply asked the API for customer records over three days, and it answered. Optus has said it intends to defend the case.

The broader numbers suggest this is routine rather than rare. The ASD's Australian Cyber Security Centre received more than 84,700 cybercrime reports in 2024–25 — one every six minutes — and responded to over 1,200 incidents, an 11% rise on the year before. The figure that should give every business pause: the ACSC notified organisations more than 1,700 times of potentially malicious activity touching their networks, an 83% jump — which often means someone else found your open door before you did. The average self-reported cost of cybercrime for a small business now sits at $56,600 per incident.

And unlike a genuine zero-day, finding these holes takes no talent. Automated scanners sweep the entire public internet in hours, cataloguing open databases, default logins and forgotten services. Your exposed bucket is not hiding. It is listed.

Canberra legislates against the default password

How common does a security failure have to be before a parliament writes a law about it? Australia just answered. Under the Cyber Security Act 2024, the nation's first mandatory security standard for smart devices came into force on 4 March 2026, after a 12-month transition period. Manufacturers and suppliers of consumer connectable products sold in Australia must now meet three baseline obligations: no universal default passwords — every unit unique or user-set, and not derivable from the serial number; a published channel for reporting vulnerabilities; and a stated minimum period of security updates, end date included. The rules align with the UK's equivalent regime and the international ETSI standard both draw on.

The target is well chosen. The most infamous demonstration remains the Mirai botnet of 2016, which conscripted hundreds of thousands of cameras and video recorders still running factory credentials, then used them to knock major services offline across the internet. A default password is not really a password at all; it is a publication.

But notice carefully what the new rules do and do not cover. They fix the shelf — the devices you buy from March 2026 onward. They do not fix your server room, your cloud tenancy, your firewall rules, your SaaS admin panels, or the fleet of older devices already plugged into your network. No regulator will ever set your storage bucket to private. Inside your own environment, the default-hunting remains your job.

What an ordinary business can realistically do

The good news buried in all of this is rare in cyber security: most of these problems cost nothing to fix. No procurement, no project budget — just attention, applied systematically.

• Change every default, everywhere. Routers, cameras, printers, NAS drives, management consoles, and the built-in admin accounts inside your software. If a credential arrived in a box or a manual, treat it as public knowledge — because it is.

• Map what faces the internet. Every domain, subdomain, API and service. The lesson of the Optus filings is that the dangerous asset is the one nobody remembers, so decommission what you no longer need instead of leaving it parked online.

• Audit your cloud storage and permissions. Confirm that everything meant to be private actually is, and be clear about which security settings are your responsibility rather than your provider's — the shared-responsibility trap our cloud vulnerabilities guide unpacks in detail.

• Treat secrets like secrets. Never copy keys, passwords or tokens from documentation, tutorials or sample code into production. Generate unique values, store them properly, and rotate anything that might ever have been shared. That single habit is the entire Sitecore saga, avoided.

• Review configuration on a schedule. Settings drift as staff change and projects rush. Benchmark against the ASD's Essential Eight, work through our system hardening guide, and make the review a calendar event rather than an afterthought.

• Watch for signs someone got there first. Solid logging and a working knowledge of indicators of compromise are what turn "we had no idea" into "we caught it within hours."

A final word

There is something uncomfortable about the quiet breach: it offers no one to blame but ourselves. No genius adversary, no unknowable flaw — just a setting nobody reviewed and a password nobody changed. Read the other way, that fact is the most hopeful one in this field. You cannot patch a zero-day before it is discovered; you can absolutely close a public bucket this afternoon, for free. Configuration is the rare corner of security where the defender holds every card — provided somebody actually picks them up.

That is exactly what a structured review is for. If you would like a systematic, expert pass over your environment — the internet-facing assets you have forgotten, the defaults still in place, the settings that have quietly drifted — our Cyber Security Risk Audit is built to find the open doors before someone else does. Learn more, or get in touch at enquiries@xiphcyber.com.

 

Further reading

• Mandiant, ViewState Deserialization Zero-Day Vulnerability in Sitecore Products (CVE-2025-53690) — https://cloud.google.com/blog/topics/threat-intelligence/viewstate-deserialization-zero-day-vulnerability

• Department of Home Affairs, Security Standards for Smart Devices — https://www.homeaffairs.gov.au/about-us/our-portfolios/cyber-security/security-standards-for-smart-devices

• ASD's ACSC, Annual Cyber Threat Report 2024–25 — https://www.cyber.gov.au/about-us/view-all-content/reports-and-statistics/annual-cyber-threat-report-2024-2025

• The Register, coverage of the ACMA's Federal Court filing on the Optus breach — https://www.theregister.com/2024/06/21/optus_data_breach_faulty_api/