6 in 10 BC law-firm websites may be at critical risk right now from two PHP bugs - check yours in two minutes, and what Law Society Rule 10-4 asks you to keep

If your firm's website runs on WordPress, a stranger with no password may be able to take it over right now, with whatever your intake form has stored and your firm's domain to email your clients from. Of 446 BC law-firm websites I read the day PHP fixed the two bugs that allow it, 6 in 10 run PHP, and 9 in 10 of those showing their version were on one PHP hasn't fixed. If someone already got in, Law Society Rule 10-4(2) says you must report it in writing.

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

If your firm's website runs on WordPress, or anything else built on PHP, a stranger with no password may be able to take over its server right now with one request. They'd get whatever your intake form has stored there, every name and matter note it collects from then on, and your firm's domain to email your clients from.[4] Your site stays open until your host installs PHP's 21 October fix. Seven and a half hours after it shipped, I read 446 BC law-firm websites: 278 (6 in 10) run on PHP, and 204 of those hide their version, so only their hosts can say whether they're patched. Of the 74 that showed one, 66 (9 in 10) were on a version PHP hasn't fixed. To see whether yours is patched, type its address into this free check. The fix is one email to your host, and it's in the main guide to these two bugs.

This page is for the part only a lawyer has. Law Society Rule 10-4 says a lawyer "must protect all records related to the lawyer's practice and the information contained in them by making reasonable security arrangements against all risks of loss, destruction and unauthorized access, use or disclosure."[1] An intake form's submissions are information about clients, so as I read the rule, the server they land on is one of those arrangements. Is yours reasonable, and could you show it? And if someone has already got in, Rule 10-4(2) says you must tell the Law Society's Executive Director, immediately and in writing.[1]

Does Rule 10-4 cover my firm's website?

My reading is yes, wherever the site collects anything about a client or a prospective one. None of the Law Society's texts mentions websites or PHP. The duties they do state fit an intake form closely:

1. Rule 10-4(1), quoted above, is a "must", and it covers "all records related to the lawyer's practice".[1]
2. Code rule 3.3-1: a lawyer "at all times must hold in strict confidence all information concerning the business and affairs of a client".[2] It is a duty not to divulge, and it is why client details sitting on a web server matter.
3. Commentary [4.1] to Code rule 3.1-2, added in 2024: a lawyer "should understand the benefits and risks associated with relevant technology, recognizing the lawyer's duty to protect confidential information".[2]

A brochure site with no form holds less, but whoever takes its server gets a domain with your firm's name on it to send phishing from.

I'm not a lawyer, and this is not legal advice. For the Law Society's view of your own setup, ask its practice advisors.

What I found on 446 BC law-firm websites

On 21 October, starting at 13:56 PDT, about seven and a half hours after PHP shipped the fix, I visited every BC law-firm website I could find, once each. 446 answered and were BC law firms' sites. 278 run on PHP (62%), and 271 of those are WordPress.

The number that matters to a lawyer is the 73%. 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 74 sites that did show a version, 66 (89%) were below the fix or on a branch PHP no longer fixes. A host can patch 8.1 under the old number, so those 30 have no fix from PHP, which isn't the same as proven exposed. Across Canada the picture is the same: of 3,114 law-firm websites, 60% run PHP, 72% of those hide the version, and 484 of the 534 that show one (91%) are below the fix or on 8.1 or older.

How I found them: every OpenStreetMap law office in Canada with a website, plus every .ca domain in Common Crawl's May to July 2026 web graph with a law word in its name. A site counts as a BC firm's when its home page has law words and a BC postal code. A hand check of 50 randomly drawn sites that could be judged found 48 were BC law firms (the other two were a medical-legal society and a notary). The counts are a floor: of 40 sites the scan couldn't place, at least 15 were law firms with no address on their home page, so the shares are of the sites I found. That frame favours firms whose .ca domain says "law", so these are the websites I could find, not every firm, and some firms run several sites. I read one home page per site, honoured robots.txt, tried no exploit and name no firm.

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.[3] The main guide shows how to read the number.
2. Send your host the message from the main guide, with one line added: "Please reply in writing, as I keep a record of security arrangements for my practice."
3. File the reply with today's date. If it says patched, you have it in writing. If it gives an update date, diarize that date 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.[3]

If someone else looks after the site, such as an agency, a staff member or your IT provider, send them the same three questions. As I read 10-4, the duty is the lawyer's whoever runs the site.[1]

What if someone already got in?

Rule 10-4(2) says a lawyer "must immediately notify the Executive Director in writing of all the relevant circumstances" if the lawyer has reason to believe "anyone has improperly accessed or copied any of the lawyer's records".[1]

So if your host tells you the server was compromised, and your forms collected client information, I read that as the situation 10-4(2) describes. An unpatched site with no sign of access doesn't trigger the report; that's a question under 10-4(1). Ask the host what was reachable and when, in writing, before you call. A patch closes the door from that moment on. It says nothing about who came in before.

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.

Is my client portal or practice-management software affected? A hosted portal 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,[4] and AI tools are making that class of bug cheaper to find, for attackers and defenders alike, as the main guide's sources show. 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 446 BC firm websites the same day.

This page changes as the advisories do. 21 October 2026: first version, from a 13-site Victoria check at 12:43 PDT and the Law Society Rules and Code as published on its website that day; later the same day, the scan of 446 BC and 3,114 Canadian law-firm websites.