# 7 in 10 BC dental websites may be at critical risk right now - check yours in two minutes, and what your College asks you to keep A stranger may be able to read your new-patient forms right now: health history, insurance details, everything patients typed. Your College says “You must keep your patient's personal and health information confidential”, and of 756 BC dental websites I read the day the fix came out, 7 in 10 run on the software with those two holes. Here's how to check yours in two minutes, and the one email that fixes it. *Figure: A filing cabinet whose lock turns freely: new-patient cards drop into its open drawer, marked health history, and a franking machine on its side stamps envelopes with the practice's name. A plate on the cabinet reads PIPA s.34, the section of BC's privacy law that asks for reasonable security arrangements.* What an unpatched practice website puts at risk, and the law that covers it. If a patient filled in your website's new-patient form, a stranger with no password may be able to read it right now: their health history, their insurance details, and everything patients type into it from today on. The same stranger could email your patients from your practice's own address.[5] Two holes in the software that every WordPress site and many others run on were fixed on 21 October, and yours stays open until your host installs the fix. Nine hours after the fix came out, I read 756 BC dental websites: 513 (7 in 10) run on that software, and 410 of those hide which version they run, so only their hosts can say whether they're fixed. Of the 103 that showed one, 95 (9 in 10) were on a version without the fix. To see whether yours is, type its address into [this free check](/php-check). Your College is plain about whose job this is. Its Standards say "You must keep your patient's personal and health information confidential", and "Failure to comply with the standards may be considered misconduct."[3] Checking your site takes two minutes, and the fix is one email to your host. Both are in [the main guide to these two holes](/posts/php-cve-2026-109618-109619-check-your-website). This page is for the part only a practice owner has: what BC's privacy law and your College ask of you, and the record that shows you did it. BC's Personal Information Protection Act says "An organization must protect personal information in its custody or under its control by making reasonable security arrangements to prevent unauthorized access, collection, use, disclosure, copying, modification or disposal or similar risks."[1] A new-patient form's answers are personal information, and health history is the kind patients least want out, so as I read the Act, the server they land on is one of those arrangements. Is yours reasonable, and could you show it? ## Does BC's privacy law cover my practice's website? My reading is yes, wherever the site collects anything about a patient or a prospective one. Neither text mentions websites, software or patching: the Act and the College's Standards say what must be achieved, not how.[1][3] 1. **PIPA section 34**, quoted above, is a "must", and it covers personal information "in its custody or under its control".[1] 2. **The College's Standard 1.6**, "You must keep your patient's personal and health information confidential", with the indicator "1.6.1 You protect patient information in compliance with applicable legislation." The Standards are mandatory for dentists, hygienists and the rest of the regulated team.[3] A brochure site with no forms holds less, but whoever takes its server gets a domain with your practice's name on it to send phishing from, to patients who already trust it. I'm not a lawyer, and this is not legal advice. For the College's view of your own setup, ask the College. *Figure: A new-patient form with name, health history and insurance fields, held flat by two clamps: one engraved PIPA section 34, must, and one engraved the College's Standard 1.6, must. A bar engraved 1.6.1 joins the College's clamp to the law's, because the Standard asks for compliance with the legislation.* Two texts, neither about websites, both about the information a practice website collects. ## What I found on 756 BC dental websites On 21 October, starting at 15:36 PDT, about nine hours after PHP shipped the fix, I visited every BC dental website I could find, once each. 756 answered and were BC dental practices' websites. 513 run on PHP (68%), and 487 of those are WordPress. | What the 513 PHP sites showed | Sites | Share | |---|---|---| | PHP version hidden | 410 | 80% | | A version below the fix | 51 | 10% | | PHP 8.1 or older, which PHP no longer fixes | 44 | 9% | | Patched | 8 | 2% | The number that matters to a dentist is the 80%. Hiding the version is good practice, and it means nobody outside can tell whether those servers are patched, not an attacker and not me. Of the 103 sites that did show a version, 95 (92%) were below the fix or on a branch PHP no longer fixes. A host can patch 8.1 under the old number, so those 44 have no fix from PHP, which isn't the same as proven exposed. Across Canada the picture is the same: of 3,968 dental websites, 68% run PHP, 80% of those hide the version, and 499 of the 544 that show one (92%) are below the fix or on 8.1 or older. Orthodontic practices, counted as those OpenStreetMap lists as orthodontics or that say "ortho" in their domain or page title, look the same: of 45 BC orthodontic websites, 29 run PHP, and 11 of the 12 that show their version are below the fix or on 8.1 or older. How I found them: every OpenStreetMap dentist in Canada with a website, plus every .ca domain in Common Crawl's May to July 2026 web graph with a dental word in its name. A site counts as a BC practice's when its home page has dental words and a BC postal code. A hand check of 40 randomly drawn sites found 39 were BC dental practices (the other was a dental society). The counts are a floor: of 40 sites the scan couldn't place, 19 were dental practices with no address on their home page, so the shares are of the sites I found. I left out 332 sites that send visitors to another address and 41 chains that list five or more locations. That frame favours practices whose .ca domain says "dental" or "smile", so these are the websites I could find, not every practice, and some practices run several sites. I read one home page per site, honoured robots.txt, tried no exploit and name no practice. *Figure: A coin sorter: 756 discs, one per BC dental website, pour in. 243 not on PHP drop into the first tube, and the other 513 run on. 410 fall into an opaque tube marked version hidden, which nobody outside can see into. The 103 that showed a version fill three clear tubes: 51 below the fix and 44 on PHP 8.1 or older, both marked, and 8 patched. A plate above the two marked tubes lights up: 95 of 103.* 756 BC dental websites, read once each from 15:36 PDT on 21 October 2026. ## What to do today, and what to keep on file 1. **Check the version.** On WordPress: Tools > Site Health > Info > Server. On cPanel: MultiPHP Manager. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.[2] [The main guide](/posts/php-cve-2026-109618-109619-check-your-website) shows how to read the number. 2. **Send your host the message** from [the main guide](/posts/php-cve-2026-109618-109619-check-your-website#what-to-send-your-host), with one line added: "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 says patched, you have it in writing. If it gives an update date, put that date in your calendar and check again. If your site runs PHP 8.1 or older and the host can't confirm a patched package, the site needs a supported version; PHP no longer releases fixes for those branches.[2] If someone else looks after the site, such as an agency, your office manager or your IT provider, send them the same three questions. The Act puts the duty on the organization that holds the information, whoever runs the site.[1] *Figure: A desk with three stations: a magnifier over a version tag reading 8.2.34, one release below the fix, with a warning lamp lit beside it; an envelope marked in writing going out to the host and a reply coming back; and a card file where the reply is stamped 21 Oct 2026 and filed, with a diary tab raised for the promised update date.* Check the number, ask the host in writing, file the reply with the date. ## What if someone already got in? PIPA has no section that tells a BC dental practice to report a breach: the Act, current to 13 October 2026, has none.[1] The Commissioner's office would like that changed, and until then says "we strongly recommend that breaches be reported to our office as a best practice."[4] The College's Standards ask you to "take appropriate steps/action should a privacy breach occur", and name no one you must report to.[3] What PIPA does have is a patient's way back to you. A patient can complain to the Information and Privacy Commissioner, and once a commissioner's order against the practice is final, "an individual affected by the order has a cause of action against the organization for damages for actual harm".[1] So the record you keep today, the host's dated reply, is what shows your arrangements were reasonable if a patient ever asks. Ask the host what was reachable and when, in writing, before you decide anything. A patch closes the door from that moment on. It says nothing about who came in before. *Figure: A boom gate over a strip-chart recorder. The paper starts at the fix on 21 October; while the gate stands open, the pen marks a shaded stretch, and when the gate shuts at patched the pen goes flat, but the shaded stretch stays on the paper. A plate asks: reachable when?* A patch stops new break-ins; it says nothing about the ones before it. ## Common questions **My site is on Squarespace or Wix. Am I affected?** Not by these two bugs. Those platforms don't run your site on PHP you control. **Are my practice-management software and online booking affected?** A hosted booking or records system runs on its vendor's servers, not your website's. Ask the vendor separately. These bugs are in PHP itself, so the question is the same: which version, and does it carry the fix? **Does updating WordPress or my plugins fix this?** No. They run on top of PHP, and only the host can change the PHP version. **Will there be another one of these?** Yes. Both bugs are memory-safety bugs in PHP's C core,[5] and AI tools are making that class of bug cheaper to find, for attackers and defenders alike, as [the main guide's sources show](/posts/php-cve-2026-109618-109619-check-your-website#why-one-more-patch-wont-be-the-last). A site built as static files, with no PHP answering each visit, has nothing to patch when the next advisory lands. That's what I build. If you'd like a second read of your host's reply, write to me: mackenzie@mackenziebowes.com. I read the advisory the morning it came out and measured 756 BC dental websites the same day. This page changes as the advisories do. 21 October 2026: first version, 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. *Figure: A three-bay letter sorter. A card reading PHP? drops into the bay for the website's host or agency and into the bay for the booking or records vendor, both marked ask. The third bay, Squarespace or Wix, is capped: nothing to ask about these bugs.* Who to ask, depending on what runs the page. ## Sources 1. British Columbia, Personal Information Protection Act, SBC 2003, c. 63, section 34, current to 13 October 2026. 2. The PHP project, security advisory, 21 October 2026. 3. BC College of Oral Health Professionals, Standards for the Oral Health Team, version 2, 1 April 2026: compliance section and Standard 1.6. 4. Office of the Information and Privacy Commissioner for BC, breach notification page, read 21 October 2026. 5. CERT-EU advisory 2026-018, v1.1. --- Published 2026-10-21. Web page: https://www.mackenziebowes.com/posts/php-cve-2026-109618-109619-bc-dental-websites