We asked every .com.au domain for its home page

Sam Lazarus · October 2026

If you would rather start with how the survey was run, skip to How we did it, then come back. The caveats for our findings are in Limitations.

Most registered domains are not websites

Australia has about 3.27 million registered .com.au names, a figure auDA publishes in its monthly registry statistics (3,273,886 at the end of May 2026). Only about three in ten of them are a website.

Of the 932,748 domains that returned a page, 28,795 are parked and a further 177,809 are placeholders: blank stubs, Index of / listings, link-tracking domains and “Account Suspended” notices. Strip those out and 726,144 real websites remain. Every platform, header and JavaScript figure below is measured against those.

How many websites did we miss?

726,144 is 22.2% of all registered names, but it only counts websites on domains we found, and our list holds about 76% of them. To estimate the rest, we used the business-register probe as a second sample, because it finds domains whether or not they have ever appeared on the web. It found 79,465 real websites, and our web-derived sources had found 73.6% of them.

Scaling up by that rate gives about 960,000 real websites, roughly 29% of registered .com.au domains. The domains we missed are poorer in websites than the ones we found, 10.6% against 36.7%, but they are not empty of them. About one in six of the missed sites presents a certificate issued for a different name, often a shared host’s default, so it never appears in certificate logs under its own name.

Three in four sites are hosted offshore

Only 24.9% of real sites sit on Australian-registered networks. Cloudflare alone fronts one in five responding domains, and Synergy Wholesale is the largest Australian host.

WordPress runs a third of the Australian web

More than two in five sites run unsupported PHP

142,504 sites announce their PHP version in a response header. 43.4% run a release that is past end of life, including 3.7% still on PHP 5.6, which last got a security fix in 2018.

Front-end code tells the same story. Of the 82,599 sites that expose their jQuery version, 52.6% run a release below 3.5, the version that closed a well-known class of cross-site scripting holes.

Then PHP shipped an emergency fix

We scanned on 20 and 21 October. On 21 October, the day the scan finished, the PHP project shipped emergency fixes for two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, nicknamed php2shell. Both are rated 9.2 out of 10. CISA added them to its actively-exploited list five days later.

The fixes landed in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Nothing was released for 8.1 or earlier. That line falls in exactly the same place as the red bars above: 61,881 Australian sites are on a branch the PHP project will not patch. Whether they get a fix now depends entirely on whether their hosting provider backports one.

There is one piece of good news in that. 58.5% of those sites are served by LiteSpeed, the signature of large shared hosting, so a handful of providers could fix most of the Australian long tail in a single maintenance window. The 7,732 sites still on PHP 5 are the ones nobody is coming to save.

We have not rescanned, so we cannot say how many have been fixed since, and a version banner is a claim by the server rather than proof.

A scan that only reads the page misses two thirds of the problem

Most of a modern website’s code is not in the page. It is in the JavaScript files the page links to. So we fetched those too, for almost every real site: 6.7 million fetches covering 834,830 distinct scripts.

The culprits are old and ordinary: jQuery 1.12.4, Bootstrap 3, an early axios, and version 8.4.5 of the Swiper slider, which a popular WordPress page builder bundles. WordPress sites fare worst at 34.3%.

Sites on Australian networks look worse than offshore ones, 33.4% against 21.2%, but that is platform mix rather than neglect. Australian hosts are twice as WordPress-heavy. Compare WordPress sites alone and the two are identical, 34.5% against 34.1%.

The scripts leak things the page does not. 12% of sites publish source maps, from which the original code can often be rebuilt. A further 1,260 name an internal development server, and nearly 3,000 contain private network addresses.

Security headers remain a minority practice

Nearly three in five sites do not send HSTS, so a browser can still be steered to an unencrypted first visit. More than four in five send no Content-Security-Policy, the main browser-side defence against injected scripts.

Encryption is in good shape, configuration is not

95.7% of hosts negotiated TLS 1.3, and Let’s Encrypt issues 72.8% of certificates, which has made renewal largely automatic. The gaps are in setup: 11.5% of hosts present a certificate a browser would reject, mostly because the name does not match, and 282 hosts still use 1,024-bit RSA keys, a size deprecated more than a decade ago.

Staging sites: open, older, on the same server

Developers often run a copy of a site at staging. under the company’s domain. We found 39,266 of them. Most came from Certificate Transparency logs, which is a finding in itself: issuing a public certificate for a staging name publishes that name to the world.

Half of reachable staging sites are open to anyone, they run older software than the live site, and about half sit on the same server as it. An outdated staging copy on the production box is a second front door.

We then asked DNS for staging.<domain> on all 2.15 million domains, to find the ones nobody had published. 84% of the staging records we found this way appeared in no public source, which more than doubled the number of open staging pages we could see. Keeping a staging name out of public logs does not make it private. Three-quarters of open staging pages also do not ask search engines to stay away, so they can be indexed and compete with the real site.

Secrets in public code

We searched the stored pages for credentials that belong only on a server, skipping the key formats vendors design to be public. 118 hosts across 95 domains exposed a genuine server-side secret. The most serious were two complete Google Cloud private keys and a page printing its server’s entire cloud environment, AWS credentials included.

Fetching the JavaScript found far more: 74 further organisations leaking database admin keys, live payment keys, cloud access keys and e-commerce admin tokens, all billed to their owners.

Two patterns explain most of it. Build tools compile any variable with a public prefix (REACT_APP_, VITE_, NEXT_PUBLIC_) straight into the code every visitor downloads. And a popular no-code app builder sends an API key to the browser unless it is explicitly marked private. The second is the more instructive, because rotating the key does not fix it. Code that runs in a browser cannot keep a secret.

Not every leak was the site owner’s doing. In a few cases the secret belonged to a vendor: a key built into a product or service that many businesses use, and served by every one of their sites. Those owners cannot fix a key that is not theirs. Only the vendor can, so we reported those cases to the vendors directly.

Subdomains anyone could take over

What is a subdomain takeover? A subdomain is often just a pointer, a DNS record saying “shop.example.com.au lives at this cloud service”. Delete the cloud resource and leave the pointer behind, and whoever creates a resource with the same name inherits the subdomain, usually with a valid HTTPS certificate to match.

107 domains have at least one subdomain that could be taken over today, 199 hostnames in all, with a further 280 domains possible depending on settings we cannot see from outside. Among them: a financial group’s asset-management site, a superannuation fund, a government-owned electricity distributor, two car brands, a national real-estate brand and a retail brand’s dealer network.

One pattern surprised us. Thirteen small businesses point one of their own hostnames, usually www, at a misspelling of their own domain name, and nobody has ever registered the misspelling. For the price of a domain, anyone could take over that address, which in most cases is the business’s main website.

Verification mattered more than detection

A first pass counted 522 domains. Checking each provider’s current rules removed two whole classes, because Heroku and Azure had both changed how names can be claimed.

The biggest correction came from asking the providers directly. A cloud name we had counted as free came back “not available”, because a disabled profile answers DNS exactly like a deleted one. So we put every cloud name to the provider’s own availability check. Of 99 names that DNS said were gone, 30 were still held. That removed eight organisations we had been about to email, including a bank and a gas network.

The lesson: DNS tells you a pointer is broken, but only the provider can tell you whether the name behind it is really free. A takeover statistic that is not checked this way can easily be inflated several times over.

What Australian businesses can do

• Ask your host which PHP version you run. If it is 8.1 or older, it is not getting the October fixes from PHP itself. Ask whether they backport, and schedule the upgrade either way.
• Treat anything in your page source as public. If a key is in there, assume it has been copied. Rotate it and move the call to your server.
• Your theme and plugins ship JavaScript too. Update them, and delete libraries you no longer use.
• Put staging behind a login, or take it down. An open copy of your site on the same server is a second front door.
• Delete the DNS record when you delete the thing it points at. Once a year, list every subdomain and check each still leads somewhere you control.
• Turn on HSTS and a basic Content-Security-Policy, and check your certificate covers every name you serve, including www..

How we did it

There is no public zone file for .au, so nobody outside the registry can simply download the list of registered names. We built ours from six overlapping public sources: Certificate Transparency logs, the Common Crawl web graph, the DomainsProject dataset, the ABN business register (turning business names into candidate domains), an NSEC3 walk of the signed zone, and public top-site lists. That produced 17.9 million hostnames and 3.47 million candidate domains. Asking the registry’s name servers about each one confirmed 2.49 million as registered, about 76% of auDA’s total.

Each of the 5.82 million resulting hosts was queued for one HTTPS request to its home page (GET /). 247,201 sat on servers that rate-limited or refused us and were dropped before any request was made, leaving about 5.57 million sent. The scanner identified itself in its User-Agent, opened no more than four connections to any server, and honoured an opt-out list. All fingerprinting happened afterwards, offline. In a second pass we fetched the JavaScript each real site loads, which is where the most interesting result came from.

One decision shapes every number here: we count domains, not hosts. A quarter of the hostnames we scanned are subdomains that hosting panels create by themselves, such as cpanel. and webmail.. They are infrastructure, not websites anyone published, and counting them roughly halves the apparent share of WordPress.

Any survey of a namespace has to choose its unit deliberately and say which one it chose. Certificate Transparency found the most domains by far, but the business-register probe contributed 196,333 that no other source found, businesses that registered a name and rarely appear anywhere else. That independence is also what let us estimate how many websites the other sources missed.

Limitations

• The domain list comes from public sources, not the registry, and holds about 76% of registered names. The 726,144 websites are the ones we found, 22.2% of auDA’s total, and that is a strict lower bound. The 29% estimate assumes the business-register probe finds websites independently of the other sources. If an active business is also more likely to appear in certificate logs, the true share is somewhat higher.
• Among business-register sites, the ones our other sources missed were more often hosted in Australia, 28% against 20%, so the 24.9% Australian hosting figure is probably slightly low.
• We read only the home page, so anything deeper is out of scope.
• Shopify is excluded, not measured. 87,822 domains sit in Shopify’s IP range but 64,853 rate-limited us, so no trustworthy share could be computed. Other platform shares are therefore computed on a base missing most Shopify stores, which inflates them slightly.
• Sites that hide their version are probably better maintained, so the PHP and jQuery figures describe the worst-maintained slice rather than everyone.
• We left Moment.js out of the vulnerable-library count. Every version is flagged and no fixed version exists, so counting it would add seven points and tell you nothing about maintenance.
• An outdated version is never proof that a site can be exploited.
• Hosting country is where the network is registered, not where the server sits.

Disclosure

Where a finding was serious enough to act on, we contacted the organisation privately before publishing, using the address it publishes itself. In total we contacted 41 organisations directly or through their credential issuer, and referred four more to AusCERT where no route to the owner existed.

We did not contact every organisation behind the findings here, and that is a deliberate choice rather than an oversight. The severe cases, where a credential reaches a database, a payment account or a cloud account, were notified individually. Below those sits a long tail of narrower exposures where there are far too many holders to write to each one. Contacting the serious cases and publishing only aggregates for the rest seemed better than notifying nobody or sending several hundred unsolicited emails. It is also part of why no site is named here and why the dataset is not being shared.

A few findings are left out of this post altogether. Where a problem was live, unfixed and trivially actionable by a reader, we have described it only in general terms, or not at all.

No credential was ever tested or used, and nothing was claimed or registered. We made no request beyond the single ordinary page fetch the survey already makes: no logins, no vulnerability probes, and no guessing of hidden pages.

Data: this survey, October 2026. 5,819,327 hosts queued, about 5.57 million HTTPS requests sent, plus 6.7 million fetches of the scripts those sites load. Registration totals from auDA’s Registry Monthly Statistics, May 2026: 4,367,677 .au names under management, 3,273,886 of them .com.au. Figures are per registrable domain except TLS, certificate and credential measures, which are per host.