I Read 756 BC Dental Websites Nine Hours After a PHP Fix Shipped. Here's What I Found.

Someone buy eight BC web hosts a cake, they were the only ones who patched PHP before a stranger came counting.

By Mackenzie Bowes · mackenzie@mackenziebowes.com · @_mackenziebowes on X

On the morning of 21 October 2026, PHP shipped a fix for two security holes - the kind of memory-safety bugs in its C core that let a stranger with no password read things they shouldn't, and email people from addresses that aren't theirs.

Nine hours later, at 15:36 PDT, I had visited every BC dental practice website I could find. Once each. Politely. I honoured robots.txt, tried no exploit, and named no practice, because I am a man with a scanner and a conscience, not a man with a warrant.

Here's the headline: 513 of the 756 sites (7 in 10) run on PHP. Of those, 410 hide which version they run. And of the 103 that showed one, 95 - nine in ten - were on a version without the fix.

Eight sites were patched. Eight. I want to buy those eight hosts a cake.

The part where it gets funny (it's not funny)

The 80% hiding their version are doing the right thing. Concealing your PHP version is good security practice. It also means nobody outside - not an attacker, not me, not the practice owner - can tell whether those servers are patched. The single most responsible act in this dataset is also the reason the dataset can't answer its own question.

That's the joke, and it's on all of us. The only person who can close the loop is the host, and the only person who can ask the host is the dentist. Which brings us to the law.

The law doesn't say "websites" anywhere, and it doesn't have to

BC's Personal Information Protection Act, section 34: an organization must protect personal information in its custody by "making reasonable security arrangements to prevent unauthorized access, collection, use, disclosure, copying, modification or disposal or similar risks."

Neither PIPA nor the College's Standards mention websites, software, or patching.[1] They say what must be achieved, not how. But if your new-patient form collects health history and insurance details - the information patients least want loose - then the server it lands on is one of those "security arrangements." Is yours reasonable? Could you show it?

The College is blunter: "You must keep your patient's personal and health information confidential," and "Failure to comply with the standards may be considered misconduct."[3]

And here's the kicker for anyone who thinks this is theoretical: PIPA has no breach-reporting section at all (current to 13 October 2026).[4] The Commissioner's office merely "strongly recommend[s]" reporting as a best practice. What PIPA does have is a patient's way back to you: once a commissioner's order is final, "an individual affected by the order has a cause of action against the organization for damages for actual harm."

So the record you keep today - a dated reply from your host - is what shows your arrangements were reasonable if a patient ever asks. A patch closes the door from that moment on. It says nothing about who came in before.

How I found them (builders, this is the good part)

The methodology is where a scan lives or dies, so here's mine, warts first:

• The frame: every OpenStreetMap dentist in Canada with a website, plus every .ca domain in Common Crawl's May - July 2026 web graph with a dental word in its name. A site counts as BC when its home page has dental words and a BC postal code.
• The honest caveat: this frame favours practices whose .ca domain says "dental" or "smile." These are the websites I could find, not every practice, and some practices run several sites.
• The hand check: I drew 40 sites at random and checked them by hand. 39 were BC dental practices. (The other was a dental society. Close enough to make you nervous, honest enough to tell you.)
• The floor, not the ceiling: of 40 sites the scan couldn't place, 19 were dental practices with no address on their home page. So the true numbers are higher than mine.
• The exclusions: 332 sites that redirect to another address, and 41 chains with five or more locations. Somebody has to draw lines; these are mine.

The Canada-wide picture is the same shape: 3,968 dental websites, 68% on PHP, 80% of those hiding the version, and 499 of the 544 that show one (92%) below the fix or on PHP 8.1 or older. Even the orthodontists - 45 BC sites, 29 on PHP - follow the pattern: 11 of the 12 that show a version are below the fix or unsupported.

Same bug class, same day, same story at every scale. That's what a real census looks like: the numbers repeat.

What a dentist actually does (two minutes, one email)

1. Check the version. WordPress: Tools > Site Health > Info > Server. cPanel: MultiPHP Manager. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.[2]
2. Email the host, with one line that does more work than it looks like: "Please reply in writing, as I keep a record of the security arrangements for my patients' information."
3. File the reply with today's date. If it promises an update date, that date goes in the calendar. If the site runs PHP 8.1 or older and the host can't confirm a patched package, it needs a supported version - PHP no longer releases fixes for those branches.

If an agency or IT provider runs the site, send them the same three questions. The Act puts the duty on the organization that holds the information, whoever runs the server.

Why I'm telling you this, builder-to-builder

Three lessons I'd steal for your next project:

Same-day is a feature. The advisory came out and the scan existed the same day. The shelf life of "I measured the internet's reaction to a fix" is measured in days. Speed is the moat.

Radical methodology honesty is a trust hack. Floors, exclusions, hand-checks, the one dental society in my sample - publishing your error bars makes your real numbers more credible, not less. Every number in this post is a floor, and I say so.

Niche × niche × niche = a post only you could write. PHP advisories are global. Dental websites are national. BC privacy law is provincial. The intersection is a page nobody else has, aimed at people who genuinely need it. PIPA's missing breach-reporting section is a plot twist you can't get in Ontario.

And yes - there will be another one of these. Both bugs are memory-safety bugs in PHP's C core, and AI tools are making that class cheaper to find, for attackers and defenders alike. A site built as static files, with no PHP answering each visit, has nothing to patch when the next advisory lands.

Your turn

Want to feel what a same-day census feels like? Pick a fix, pick a niche, pick a province, and go read some home pages. Honour robots.txt. Try no exploit. Name no one. Then count.

This page changes as the advisories do. First version: 21 October 2026, from the College's Standards and BC's privacy law as published that day, and a scan of 756 BC and 3,968 Canadian dental websites from 15:36 PDT.