Compudent Systems

AI Just Helped Turn a Linux Bug Into a Root Exploit — and It Shrinks the Window Your Practice Has to Patch

Raymond — Mon, 19 Oct 2026 09:38:09 +0000

In late July, at the TyphoonPwn 2026 hacking competition, a security researcher named Lee Jia Jie disclosed a working root exploit for a flaw in the Linux kernel. That, on its own, is routine — competitions like this exist to surface exactly these bugs so they can be fixed. The detail that should make every IT decision-maker pay attention was how he built it: he said artificial intelligence helped him find the bug, speed up writing the exploit, and even tune the split-second timing the attack depended on.

The vulnerability itself — tracked as CVE-2026-53264, a use-after-free race condition in the kernel’s network traffic-control subsystem — matters far less than the method. This is a concrete, public demonstration that AI can compress one of the slowest, most specialised steps in an attack: turning a theoretical flaw into a reliable, working exploit. And that compression lands directly on the single defence most dental practices are weakest at — patching before someone shows up to use the hole.

AI is shortening the distance between a bug being found and a working exploit existing for it.

The quiet metric: time from flaw to working exploit

Every security patch you install is really a race against an invisible clock. When a vulnerability becomes public, it is usually just a description of a weakness, not a ready-to-use weapon. Someone still has to do the hard, skilled work of building an exploit that reliably triggers the flaw on real systems. Historically that gap — between “a bug is known” and “a dependable attack exists” — gave defenders breathing room. It was the window in which you could patch and be safe before anyone could realistically use the flaw against you.

That window is the whole game, and AI is shrinking it. The hardest part of the Linux exploit above was the timing: a race condition only works if the attacker hits an incredibly narrow window where the software is briefly in a vulnerable state, and getting that reliable normally takes serious expertise and painstaking trial and error. The researcher used AI to help optimise exactly that. The lesson generalises: work that once took a skilled specialist days or weeks can increasingly be accelerated with AI assistance, which means exploits for newly disclosed flaws will tend to arrive faster.

The defender’s safety margin is the gap between a flaw going public and a reliable exploit existing. That gap is shrinking.

Keep this in proportion — but take the trend seriously

It is worth being precise, because overstatement helps no one. This particular flaw is a local privilege escalation, not a remote-code-execution bug. In plain terms, an attacker cannot use it to break into your network from the internet; they first need an existing foothold on the machine — a logged-in account, or malware already running with limited rights. Only then does the exploit let them climb from that limited access to full root (administrator) control. So this is not a “the sky is falling” alert about one Linux bug.

The significance is the direction of travel. AI did not invent a new category of attack here; it lowered the effort and skill required to weaponise an existing one. Repeat that across the thousands of vulnerabilities disclosed every year, and the practical effect is that the comfortable gap between disclosure and exploitation gets narrower for everyone — including small healthcare practices that assumed they were too minor, and too slow a target, to be reached before they got around to patching.

Why “we’ll patch it next month” is now a risk, not a routine

For a dental practice, vulnerabilities rarely feel urgent. Updates get deferred because a reboot interrupts the schedule, because the imaging software “works fine,” or because nobody is formally responsible for tracking them. That inertia was always a gamble; AI-accelerated exploitation raises the stakes on it. When a critical flaw is announced, assuming you have weeks before anyone could exploit it is no longer a safe default.

This is the same discipline we urged after Microsoft’s record-breaking October Patch Tuesday and the emergency Exchange Server fix earlier this month: the goal is not to patch everything instantly, but to patch the serious, actively relevant things fast — within days, not quarters. A practice that cannot answer “when did we last apply updates, and to what?” has no idea how wide its own exploit window is.

A privilege-escalation flaw turns a limited foothold into full control of the machine — the attacker just needs to get a foot in the door first.

The practical defence: shrink your own exposure faster than they shrink the window

You cannot stop attackers from using AI. What you can control is how little time and room a fresh exploit has to work with inside your practice. A few concrete habits do most of the work:

Prompt, managed patching. Workstations, servers, firewalls, and the firmware on imaging devices all need a defined process that applies critical updates on a short, tracked schedule — ideally automated and monitored, so nothing sits exposed for months because one machine was off that day.
Least privilege. Privilege-escalation exploits are only valuable if there is a low-privilege foothold to escalate from, and only dangerous if ordinary accounts are one step from full control. Staff should work from standard user accounts, not administrator ones, so a compromised login is a contained problem rather than a master key.
Deny the initial foothold. Nearly every one of these attacks still needs a way in first — most often a phished credential or a staff member’s click. Awareness training and strong authentication remain the cheapest way to make sure the clever exploit never gets the foothold it requires.

Detection and segmentation: for the flaw you did not patch in time

No practice patches perfectly, and some flaws are exploited before a fix even exists. That is why speed has to be paired with containment and visibility. Network segmentation — keeping imaging devices, clinical workstations, office IoT, and guest Wi-Fi on separate zones — means an attacker who escalates privileges on one machine cannot simply roam to the server holding your patient records. It is one of the concrete reasons we steer practices toward business-grade network security rather than a consumer router.

Alongside it, endpoint detection and response watches each machine for the behaviour an exploit produces — an ordinary account suddenly acting with elevated rights, a process probing the system, credentials being harvested — and flags it as it happens, rather than waiting for damage. Faster exploitation makes fast detection the backstop that buys back the time the shrinking patch window took away.

When the exploit window shrinks, prompt and automated patching stops being housekeeping and becomes a frontline defence.

What this means for your practice

The headline here is not one Linux bug; it is a shift in the tempo of the whole threat landscape. The tools attackers use to turn vulnerabilities into working weapons are getting faster, which means the margin between “a flaw was announced” and “a flaw is being used” is closing. Defence does not require matching that with exotic technology — it requires doing the unglamorous fundamentals faster and more consistently: patch on a short clock, keep everyday accounts out of administrator roles, segment the network, and watch the endpoints so a slipped patch is caught, not catastrophic.

No single control is perfect, so defensible practices layer them — patching, segmentation, least privilege, and detection together.

How Compudent Systems can help

At Compudent Systems, we help dental practices across the GTA and Ontario stay ahead of this curve — running managed, monitored patching so critical updates are applied in days rather than forgotten for months, locking down account privileges, segmenting imaging and clinical systems, and deploying endpoint detection so an exploit that slips through is spotted early. Contact Compudent Systems for a security assessment, and let us make sure your practice’s patch window is measured in days, not left wide open for whatever the attackers build next.

Sources & further reading:

Researcher Says AI Helped Develop Linux Traffic-Control Race Into Root Exploit (The Hacker News)

Ten Months Inside: The O2 Dental Breach and the Security Metric Your Practice Is Ignoring

Raymond — Sun, 18 Oct 2026 09:37:08 +0000

In early October, the Interlock ransomware group added O2 Dental Group — a US dental services organization operating under the O2 Smiles brand — to its public leak site, claiming it had taken patient health records, dental imaging, and insurance billing data. We covered that disclosure, alongside a second practice and a six-figure HIPAA penalty, in our look at two dental breaches landing in a single week. The breach itself was grimly familiar. One detail in the subsequent analysis was not.

According to incident researchers, the attackers may have first gained access to O2’s network back in December 2025 — the better part of a year before the ransomware actually fired. That timeline is an estimate, not a confirmed fact, but it describes something that is now the norm rather than the exception: a long, quiet occupation of the network, spent on reconnaissance and lateral movement, before a single file was encrypted. There is a name for the time an intruder spends inside a network before they are discovered. It is called dwell time, and it is the one security metric most dental practices never think to measure.

The dangerous phase of a modern breach is the quiet one: months of a hidden presence before anything visibly breaks.

The breach you see is the end of the story, not the start

It is tempting to picture a ransomware attack as a single moment — a bad click on Monday, encrypted files by Tuesday. Modern intrusions rarely work that way. The visible event, the encryption and the leak-site listing, is the final act. Everything that matters happens before it, out of sight.

A typical intrusion unfolds in stages: initial access (often a phished credential or an unpatched edge device), then a patient period of reconnaissance — mapping the network, finding the server that holds the patient records, learning where the backups live and how they are protected. Then lateral movement, quietly stepping from the first compromised machine to more valuable ones, and persistence, planting ways back in so a single cleaned computer does not evict them. Only when they have mapped everything and located your backups do they detonate. By then they have had, in cases like O2’s, months to prepare the maximum-damage version of the attack.

Encryption is the last act, not the first. Most of an attack is the quiet reconnaissance that precedes it.

Why dwell time is the metric that matters

Most of a dental practice’s security spending — and nearly all of its attention — goes to prevention: the firewall, the spam filter, the password policy. Prevention is essential, but it answers only one question: how do we keep attackers out? Dwell time answers a second, more uncomfortable one: when they get in anyway, how long will it take us to notice?

For a practice relying on a consumer antivirus and a hope that nothing gets through, the honest answer is often “not until the files are encrypted.” That is a dwell time measured in months, and it is the difference between the two possible endings to this story. Catch an intruder during reconnaissance, and you have a contained incident and a cleanup. Catch them at the moment of encryption, and you have O2’s: stolen records, a public leak site, regulatory exposure, and weeks of downtime. The attack is the same; only the detection speed changed the outcome.

Shrinking the gap: detection, not just defence

Reducing dwell time means investing in the half of security that watches the inside of the network, not just the wall around it. For a dental practice, that comes down to a few practical capabilities:

Endpoint detection and response (EDR). Unlike traditional antivirus, which checks files against a list of known-bad signatures, EDR watches behaviour on each workstation and server — an account suddenly probing other machines, a process trying to disable backups, credentials being harvested — and flags it as it happens. This is the single most effective tool for catching the quiet middle of an attack.
Managed detection and response (MDR). Alerts only help if someone is watching them. Few practices have a security analyst on staff, which is why many pair EDR with a managed service that monitors around the clock and responds to alerts at 2 a.m. so the practice does not have to.
Meaningful logging and review. A business-grade firewall and your servers can record what is happening at the perimeter and inside — but logs nobody reads catch nothing. Centralised, reviewed logs turn scattered records into early warning.

Prevention guards the perimeter; detection watches the inside. A long dwell time is a failure of the second, not the first.

Limiting how far a quiet intruder can travel

Detection shortens dwell time; good architecture limits what that time is worth to an attacker. The reconnaissance and lateral-movement phases are only dangerous because, on a flat network, every machine can reach every other one. Network segmentation — keeping imaging devices, clinical workstations, office IoT, and guest Wi-Fi on separate isolated zones — means an attacker who lands on the front-desk PC cannot simply stroll to the imaging server. It is one of the concrete benefits of moving to business-grade network security, and it turns a whole-practice compromise into a contained one.

It also matters where the intrusion starts. The majority of these long-dwell attacks begin with a phished credential or a staff member’s click, which is why awareness training is not a soft, optional extra — it is the control that denies attackers the quiet head start in the first place.

Endpoint and managed detection shrink dwell time by watching behaviour continuously, not just blocking known-bad files.

What this means for your practice

The lesson of the O2 breach is not “ransomware exists” — every dental practice knows that by now. It is that the clock starts long before the alarm goes off, and that a practice which only measures whether it has been breached, rather than how fast it would know, is flying blind through the most dangerous part of the attack. Prevention keeps the odds in your favour; detection decides how bad it gets when the odds lose.

And because no detection is perfect, the backstop still matters most. When an attacker has had months to find and target your backups, the only recovery you truly control is one they could not reach — which is exactly why an immutable, air-gapped backup is the last line that turns a catastrophe back into an inconvenience. Prevention, detection, segmentation, and recoverable backups are not competing choices; they are the four things that, together, make a practice defensible.

A defensible practice layers prevention, segmentation, detection, and recoverable backups — so a quiet intruder has nowhere far to go.

How Compudent Systems can help

At Compudent Systems, we help dental practices across the GTA and Ontario close the detection gap — deploying endpoint detection and response, pairing it with monitoring so alerts are actually acted on, segmenting imaging and clinical systems to limit how far any intrusion can spread, and maintaining the logging and immutable backups your HIPAA and PHIPA obligations expect. Contact Compudent Systems for a security assessment, and let us make sure that if someone gets into your network, you find out in minutes — not in months.

Sources & further reading:

A Consumer Router Is Not a Firewall: Why Your Dental Practice Needs Business-Grade Network Security

Raymond — Sat, 17 Oct 2026 10:31:08 +0000

Walk into most small dental practices and the device standing between the open internet and every patient record in the building is the same box you would find in a family home: a consumer wireless router from an electronics-store shelf, installed years ago, never updated, doing double duty as the practice’s gateway, Wi-Fi, and — in name only — its firewall. It works. The phones connect, the X-rays open, the insurance claims go out. And that is precisely the problem: it works just well enough that no one questions whether it is actually protecting anything.

Through 2026, the agencies whose job is to watch this closely made the answer blunt. CISA and the FBI issued repeated warnings that small-office and home-office (SOHO) routers are now a primary target for both criminal botnets and nation-state actors, who quietly conscript thousands of unpatched edge devices into covert networks used to launch further attacks. The compromised-device campaigns documented this year share one trait: the routers were vulnerable because they were end-of-life — out of date and no longer receiving security patches. For a practice holding thousands of patient histories, that shelf router is not a convenience. It is an exposure.

The same job, two very different tools: a consumer router forwards traffic; a business-grade firewall inspects and defends it.

A router forwards traffic. A firewall defends it.

The words get used interchangeably, and that is where the trouble starts. A consumer router’s core job is to move data — to connect your devices to the internet and to each other. It includes a basic packet filter and calls it a firewall, but that filter does little more than block unsolicited inbound connections. It does not meaningfully inspect what is inside the traffic it passes, cannot recognise an attack in progress, offers no useful logging, and stops receiving firmware fixes a year or two after it ships.

A business-grade firewall is a different class of device built for a different job: scrutinising traffic rather than merely routing it. The category is often sold as a next-generation firewall (NGFW) or unified threat management (UTM) appliance, and the distinction matters for a clinic because the threats that reach a dental office are no longer crude port scans — they are malicious payloads hidden inside ordinary-looking web and email traffic.

What business-grade actually buys you

The premium over a consumer router pays for capabilities a home device simply does not have:

Deep (stateful) inspection. It examines the content and context of traffic, not just where it is headed, so it can catch threats riding inside permitted connections.
Intrusion prevention (IPS). It recognises the signatures and behaviours of known attacks — including attempts to exploit the very network-device flaws attackers favour — and blocks them in real time.
Content and DNS filtering. It can stop staff from reaching known-malicious or phishing domains before a bad click ever becomes a bad connection.
A real VPN for remote access. Encrypted, authenticated tunnels for a doctor reviewing images from home or a remote IT provider — not a port forwarded to the open internet.
Logging you can actually use. Durable records of what crossed the perimeter, which is both an early-warning system and, after an incident, the evidence of what did and did not happen.
Sustained firmware support. A vendor commitment to patch newly discovered vulnerabilities for years — the single feature whose absence turned so many consumer routers into botnet nodes.

Business-grade gear adds layers a home router never had: deep inspection, intrusion prevention, filtering, secure VPN, and audit logging.

Segmentation: your X-ray sensor does not belong on the front-desk network

One of the most valuable things a proper firewall enables is something a flat home network cannot: segmentation. In most practices, everything sits on one undivided network — reception PCs, clinical workstations, the CBCT and intraoral scanners, the practice management server, the smart thermostat, the staff phones, and the guest Wi-Fi in the waiting room. If any one of those is compromised, the attacker can reach all of them.

A business-grade firewall lets you carve that single network into isolated zones (commonly using VLANs): imaging devices on their own segment, clinical workstations on another, building IoT on a third, and guest Wi-Fi fully walled off from everything clinical. This is not academic. Many imaging and point-of-care devices run embedded operating systems that cannot be patched or run antivirus — exactly the risk we examined in the context of network-device vulnerabilities that expose a practice’s whole LAN. Segmentation contains a breach to the room it started in instead of letting it walk the length of the office.

Segmentation keeps an X-ray sensor, a smart thermostat, and a guest phone off the same network as your patient records.

End-of-life is the silent killer

Even the right hardware becomes a liability if it is left to rot. The defining lesson of 2026’s router attacks is that an unsupported edge device is worse than an old one — it is an open door. Once a manufacturer stops issuing firmware updates, every vulnerability discovered afterward stays unfixed forever, and attackers specifically hunt for those models because they know the holes will never close.

Washington took this seriously enough to codify it: CISA’s binding operational directive BOD 26-02 ordered federal agencies to inventory their unsupported edge devices within months, begin replacing them within a year, and complete remediation within eighteen months. Your practice is not a federal agency, but the threat is identical — and so is the fix. Know what your gateway is, confirm it is still receiving security updates, apply those updates promptly (the same discipline we urge for operating systems and applications on patch day), and replace anything the vendor has abandoned. A firewall that has reached end-of-life should be retired the way you would retire an expired autoclave: not when it fails, but when it can no longer be trusted to do its job. This is also why the FCC moved to restrict certain foreign-made consumer routers outright.

What this means for a dental practice

Beyond the direct risk of a breach, your network perimeter is a compliance artifact. A reasonable, documented safeguard at the edge is exactly what HIPAA’s Security Rule and Ontario’s PHIPA expect, and a regulator reviewing an incident will ask what stood between the internet and the protected health information. “A seven-year-old consumer router” is not a defensible answer. Cyber-insurance underwriters have converged on the same expectation: a managed, supported firewall with logging is increasingly a precondition for coverage, not a nice-to-have, and its absence is a reason claims get questioned.

None of this replaces your other controls — multi-factor authentication, staff awareness, and above all tested backups still carry the load if the perimeter is breached, which is why an immutable, air-gapped backup remains the exit you ultimately control. The firewall is the front gate. The point is to have a gate that is actually built to be one.

An edge device that no longer gets firmware updates does not just age — it becomes a standing invitation.

A properly chosen, maintained firewall is both the practice’s front gate and the evidence that the gate exists.

How Compudent Systems can help

At Compudent Systems, we design and manage network security for dental practices across the GTA and Ontario: assessing what your current gateway actually is and whether it is still supported, deploying and configuring business-grade firewalls, segmenting imaging devices and IoT away from your clinical and patient data, keeping firmware current, and maintaining the logs your PHIPA and HIPAA obligations — and your insurer — expect to see. Contact Compudent Systems for a network security assessment, and let us make sure the box guarding your patients’ records was actually built for the job.

Sources & further reading:

Sending a 3D Scan for a Second Opinion: How to Share CBCT Data Without Putting a Patient’s Record at Risk

Raymond — Fri, 16 Oct 2026 12:01:29 +0000

It is one of the most routine requests in a dental practice. A patient needs a second opinion on an implant site, an impacted third molar, or an unclear lesion, and the specialist’s office calls and says: just send us the CBCT. The clinical instinct is to be helpful and fast. The fastest answers — attach the file to an email, burn it to a disc, or drop it on a USB stick for the patient to carry across town — are also the ones most likely to turn a simple favour into a reportable privacy breach.

A three-dimensional scan is not just a picture. It is a complete volume of a patient’s anatomy, bound to their name and record, and it is personal health information the moment it leaves your operatory. How it travels matters as much as what it shows. Here is how to share a 3D dental scan for a second opinion the right way — so the specialist gets everything they need to read it, and nothing leaks on the way there.

The clinical question is simple; the data path is where the risk lives. A second opinion should travel over an encrypted channel, not a plain email or a USB stick.

Why the easy methods are the risky ones

Ordinary email is the classic trap. A standard message crosses several servers in plain text, lands in an inbox you do not control, and then gets forwarded, replied-to, and backed up in ways you can never retract. Once a scan is sitting in someone’s personal mailbox or on their phone, you have lost every bit of control over where that patient’s data goes next. A USB stick or a burned disc is no better: it is an unencrypted copy of a health record walking out the door, trivially lost in a car, a waiting room, or a jacket pocket.

There is also a quieter failure mode — sending the wrong thing. Under pressure, staff sometimes screenshot a few slices from the imaging software and send those flat pictures instead. The specialist cannot scroll, re-slice, or measure a flattened screenshot, so the second opinion is built on a fraction of the information the scan actually holds. You have taken on all of the privacy risk of sharing and delivered almost none of the diagnostic value.

Export the right data: DICOM, not screenshots

A 3D scan should leave your system as a proper DICOM export — the medical-imaging standard that carries the full volume, the acquisition parameters, and the metadata a radiologist or specialist needs to interpret it correctly. Most CBCT and practice-management platforms can export a study as a DICOM dataset, often bundled with a small standalone viewer so the receiving office can open it without owning your exact software. That viewer question is precisely the kind of interoperability headache we covered in our explainer on imaging bridge software and why X-rays break when you switch systems; the same mismatch that breaks imaging in-house is what strands a referral if you send a format the specialist cannot open.

Before you send anything, confirm two things with the receiving office: the exact format they can ingest, and whether they want the full study or a specific region. Sending a complete, correctly exported volume once beats three rounds of re-sending because the first file would not open. And because that study has to live somewhere while it is prepared and transmitted, the storage and handling of DICOM data is an IT design decision in its own right — the same point we made about dental MRI being an IT project before it is a clinical one.

A proper DICOM export preserves the full 3D volume a specialist needs to read; a folder of screenshots throws most of the diagnostic information away.

Consent and the law: this is health information, wherever you practise

Sharing a scan for a care-related second opinion is generally permitted, but it is not consent-free. In Ontario, the Personal Health Information Protection Act (PHIPA) treats imaging as personal health information and expects disclosures to be limited to what is reasonably necessary, with the patient’s knowledge. Practices serving U.S. patients or working with U.S. specialists face the parallel HIPAA Security Rule, which specifically addresses how electronic health information must be protected in transit.

The practical takeaway is the same under either regime: get and document the patient’s agreement to send their scan to the named specialist, share only what that opinion requires, and keep a record that you did so. If the patient is the one carrying or receiving the scan, giving it to them is straightforward — it is their record — but you still owe them a secure method and a clear explanation, not a naked USB stick.

A five-step secure sharing workflow

Turn the one-off favour into a repeatable process your whole team follows the same way every time:

1. Confirm consent and the recipient. Verify who is asking, that they are the specialist the patient actually wants, and that the patient has agreed. Note it in the chart.

2. Export properly. Produce a DICOM study (with a viewer if needed), not screenshots, and confirm the receiving office can open it.

3. Minimise and label. Send only the study required. Where a platform supports it, keep identifiers to the minimum necessary and label the package clearly so it is matched to the right patient on arrival.

4. Encrypt and send through a controlled channel. Use a secure patient portal, an encrypted file-transfer service, or a dedicated imaging-exchange platform that produces an expiring, access-controlled link. Never plain email, never an unencrypted drive.

5. Log it. Record what was sent, to whom, when, and under whose authorisation. If a question ever arises, that audit trail is the difference between a clean answer and a scramble.

A repeatable five-step path turns an ad-hoc favour into a defensible process: consent, de-identify where possible, encrypt, send through a controlled channel, and log it.

Choose the channel deliberately

The channel is where most practices either get this right or quietly get it wrong. A good option gives you three things: encryption in transit, an access control you own (a login or a one-time link rather than an open attachment), and the ability to expire or revoke access after the specialist has what they need. A secure portal or a purpose-built imaging-exchange service does all three. A chain of forwarded emails does none of them — it scatters permanent copies across inboxes and personal devices you will never be able to recall.

This is the same discipline that decides whether a breach becomes a catastrophe elsewhere in the practice. The offices that fare worst after an incident are usually the ones who could not say where their data had gone or who had touched it — a theme that runs straight through recent dental ransomware cases and their HIPAA penalties. Control and auditability are not bureaucracy; they are what keeps a routine referral from becoming a regulator’s file.

Control is the whole point: a secure link you can expire and audit beats a scan that quietly multiplies across inboxes and personal phones you will never see again.

Build it once, use it every day

None of this should slow your front desk down. The goal is to set up the secure channel, the DICOM export routine, the consent note, and the log once, so that “just send us the CBCT” becomes a thirty-second task that happens to be defensible. A scan that leaves your practice the right way protects the patient, the specialist, and you — and it keeps the second opinion focused on the tooth, not on how the file got there.

Secure sharing is not one tool but a layered posture — encryption, access control, auditing, and a single sanctioned channel — applied to the imaging data a practice is trusted to hold.

How Compudent helps

Compudent helps dental practices across the GTA and Ontario set up secure imaging workflows that fit real clinical life — reliable DICOM export, encrypted and audited sharing channels for referrals and second opinions, and storage and access controls that keep patient scans protected and PHIPA-aligned without slowing your team down. If sending a 3D scan today means an email attachment or a USB stick, let’s replace that with a channel you can trust and audit. Contact Compudent to review how your practice shares imaging.

Sources & further reading:

The Breach Almost Always Starts With a Click: How to Run Security-Awareness Training and Phishing Tests in a Dental Practice

Raymond — Thu, 15 Oct 2026 10:32:04 +0000

Read back through the dental data breaches of 2026 and a pattern emerges that has nothing to do with sophisticated malware. A staff member opened an attachment. Someone typed their password into a convincing fake login. A receptionist, trying to be helpful, approved a login prompt or gave a “technician” on the phone the access they asked for. The expensive firewall was never the problem. A person was persuaded.

Verizon’s 2026 Data Breach Investigations Report puts a number on it: the human element was involved in 62% of breaches, with phishing responsible for a large share on its own. For a dental practice, that statistic points to the single most cost-effective control you can add — and it is not a product. It is a security-awareness program: recurring training plus realistic phishing tests that teach your team to recognise the lure before they click.

The real perimeter of a dental practice is the person at the keyboard deciding whether to click.

The common thread in 2026’s dental breaches is a person

We have documented the year’s incidents on this blog, and the root cause is remarkably consistent. The Hawaii Family Dental breach that exposed 45,853 patients traced back to a single compromised account. Attackers have called front desks directly, impersonating IT to walk a trusting employee through handing over a Microsoft login. Across the string of dental breaches already reported this year, the breach rarely began with a flaw in the software. It began with a flaw in the moment — a busy person, a plausible message, and no pause to verify.

That is not a criticism of your team. It is the design of modern attacks. Phishing and social engineering are engineered to exploit exactly the instincts a good dental employee has: be responsive, be helpful, open the attachment the “insurer” sent, answer the “colleague” who needs something urgently. You cannot patch that instinct. You can, however, train it.

What security-awareness training actually is (and is not)

The phrase conjures a dreaded hour-long video watched once a year with the sound off. That version does almost nothing, and the research is blunt about why: people forget, attacks evolve, and a single session cannot build a reflex. Effective awareness training looks different in three ways.

Short and frequent beats long and annual. A few minutes a month — a two-minute clip on gift-card scams, a one-screen refresher on spotting a spoofed sender — keeps the topic alive without stealing clinical time. Habit, not homework.
Specific to dental work. Generic “don’t click suspicious links” advice slides off. Training that uses the lures your staff actually see — a fake lab invoice, a bogus insurance EOB, a “patient” email with a malicious form, a text claiming to be the practice owner asking for gift cards — sticks because it is recognisable.
Role-aware. The front desk faces inbound email and phone pretexting all day; the office manager handles invoices and payroll changes that wire-fraud scams target; clinicians use personal phones and cloud logins. Each role needs the slice of training that matches its real exposure.

Awareness is a habit, not an event: short, frequent reinforcement beats a single annual video everyone forgets.

Phishing simulation: testing, not punishing

A phishing simulation is a safe, fake phishing email your IT provider sends to your own staff to see who clicks, who enters credentials, and who reports it. Done well, it is the single best way to turn abstract advice into a measured, improving skill. Done badly, it breeds fear and resentment and teaches people to hide mistakes — which is the opposite of what you want.

The difference is culture. The goal is never to catch and shame the person who clicks. It is to create a teachable moment: someone who clicks a simulated lure lands on a short, friendly page that explains the exact tell they missed, and that is the end of it. Meanwhile the real win is the report button — a one-click way to flag a suspicious message to IT. You want to measure two numbers over time: the click rate falling, and the report rate rising. A team that reports a real attack within minutes is worth more than a team that merely avoids clicking, because reporting is what lets you contain the one message that does get through.

A good phishing test ends in a teachable moment and a clicked report button, not a public telling-off.

Building a program that fits a small practice

You do not need an enterprise security department. A workable program for a practice of five to forty people looks like this:

Baseline first. Run one quiet simulated phishing test before any training, so you know your real starting click rate. It is almost always higher than owners expect — and that honest number is what justifies the effort.
Train monthly, test quarterly. Short monthly micro-lessons, a simulated phishing email roughly once a quarter, with the scenarios rotating so no one memorises a single “trick.”
Onboard new hires on day one. New staff are a favourite target precisely because they do not yet know who is who. Awareness belongs in onboarding alongside the PHIPA privacy briefing, not months later.
Give everyone the report button and a rule. One simple, repeated rule closes most of the gap: verify unexpected requests through a second channel before acting. An email asking to change banking details? Phone the known contact. An “IT” caller asking you to approve a prompt? Hang up and call your provider’s real number.
Track and share the trend. Celebrate the falling click rate and the rising report rate in a team meeting. Visible progress is what keeps a program alive past month two.

Measure two things over time: fewer people clicking, and more people reporting. Both are signs the program is working.

It is also a compliance and insurance requirement

Security-awareness training is not only good practice — increasingly it is expected of you. Workforce security training is an explicit expectation under HIPAA, and a reasonable safeguard under Ontario’s PHIPA; a regulator reviewing a breach will ask what training your staff received, and “none” is an answer that compounds the penalty. Cyber-insurance underwriters have moved the same way: as we covered when examining the security controls that decide whether a claim gets paid, carriers now commonly require documented, recurring awareness training and will question a payout if it was absent. A training program you can evidence is both a defence against the breach and a defence against having the claim denied after one.

A layer, not a replacement

None of this displaces your technical controls. Multi-factor authentication, timely patching, and tested backups remain non-negotiable — and awareness training makes each of them stronger. A trained employee is far less likely to approve the fraudulent MFA prompt that defeats multi-factor authentication through sheer fatigue, and far more likely to report the intrusion early enough that your backups never have to be used. The human layer and the technical layer are not alternatives; they are two rings around the same practice, and attackers only need one of them to be missing.

Training is the outer ring, not the only ring: it works with multi-factor authentication, patching, and backups, not instead of them.

How Compudent Systems can help

At Compudent Systems, we run managed security-awareness programs built for dental practices across the GTA and Ontario: a baseline phishing assessment so you know where you stand, short recurring training tuned to the lures your team actually faces, periodic simulated phishing with teach-don’t-punish follow-ups, a one-click report button wired to our team, and the documented records your PHIPA and HIPAA obligations — and your cyber insurer — expect to see. Contact Compudent Systems for a security-awareness assessment, and turn the weakest link in most breaches into your practice’s most reliable line of defence.

Sources & further reading:

October 2026 Patch Tuesday: Microsoft Fixes a Record 1,400+ Flaws and an Exploited Windows Zero-Day — What Dental Practices Must Patch Now

Raymond — Wed, 14 Oct 2026 10:32:40 +0000

On October 13, 2026, Microsoft released the largest Patch Tuesday in its history — more than 1,400 vulnerabilities fixed in a single month. For a dental practice, the headline number is not the point. The point is that buried in that pile is CVE-2026-96951, a Windows flaw that attackers are already using, and that it undoes one of the quiet safety features standing between your front desk and a malicious email attachment. This is the one to act on first, and there is a public deadline attached to it.

Here is what shipped, which fix cannot wait, and the Windows versions that just received their final update ever.

A record month: more than 1,400 fixes in a single release, with one flaw already being exploited in the wild.

A record month — but counts are not the story

The scale of this release is genuinely unusual. BleepingComputer tallies 1,411 flaws fixed on Patch Tuesday itself and three zero-day vulnerabilities, while Tenable counts 1,407 CVEs; other trackers land near 1,414, including dozens rated critical. The small differences come down to how each one counts updates released earlier in the month versus on the day — not to any disagreement about what matters.

And that is the trap with a number this big: it invites paralysis. No practice patches 1,400 things by hand, and you do not need to. Your Windows machines pull the monthly cumulative update automatically; the job is to make sure that update actually installs, prioritise the handful of flaws under active attack, and not let the sheer volume become an excuse to do nothing.

The one that cannot wait: CVE-2026-96951

Of the three zero-days, one stands apart because it is confirmed to be exploited in the wild. CVE-2026-96951 is a Windows Shell security feature bypass, and both Microsoft and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) have flagged it as actively abused. CISA added it to its Known Exploited Vulnerabilities catalog and set a patch deadline of October 16, 2026 for federal agencies. Your dental office is not a federal agency — but when CISA puts a date that tight on a flaw, treat it as the clock the attackers are working against, not a bureaucratic formality.

What makes this one worth understanding rather than just patching is what it bypasses: the Mark of the Web.

The exploited flaw strips away Windows’ Mark of the Web warning, so a malicious attachment can run without the usual safety prompt.

What “Mark of the Web” is, and why a dentist should care

Whenever a file arrives from outside your computer — downloaded from a website, saved from an email attachment — Windows quietly tags it as having come from the internet. That tag, the Mark of the Web, is what triggers the familiar safeguards: the “this file came from another computer, are you sure you want to open it?” prompt, and Microsoft Office opening the document in read-only Protected View before you click “Enable Editing.” Those warnings are annoying by design. They are the pause that gives a busy person a half-second to think before a booby-trapped file runs.

A Mark-of-the-Web bypass removes that pause. A malicious attachment engineered to exploit CVE-2026-96951 can execute without the warning banner and without Protected View — it simply looks and behaves like a safe, local file.

Now picture where that lands in a dental office: the front desk, where staff open emailed insurance forms, referral documents, lab correspondence, and resumes dozens of times a day, every one of them a plausible excuse to send an attachment. Phishing already targets reception precisely because that is the role trained to open things from strangers. This flaw turns the last automatic safety net in that workflow off. One convincing email, one double-click, and the usual “are you sure?” never appears.

The front desk opens attachments all day. A warning-bypass flaw turns a routine lure into a one-click compromise.

The other two zero-days

The remaining two zero-days were publicly disclosed but are not known to be exploited yet. They sit in .NET Framework-related components, and one — CVE-2026-92707 — is a denial-of-service flaw in MessagePack-CSharp, a data-handling library. In practice these matter most to software developers and to vendors who build on those components; for a typical practice they are covered by applying the monthly update rather than by any special action. Worth knowing they exist; not worth losing sleep over relative to the Shell bypass.

Quietly important: some Windows versions just got their last update

This month also marked an end-of-support milestone. According to the same reporting, Windows 10 Enterprise LTSB 2016 and certain editions of Windows 11 version 24H2 reached end of support, meaning the October release is the final security update those versions will ever receive. Because Windows editions and servicing dates vary, the practical move is to confirm, with your IT provider, exactly which Windows version each machine in your office is running and when it stops receiving updates.

Why this belongs in a security article: an unsupported operating system does not just miss new features — it stops getting security patches entirely, so every flaw found after its cut-off date stays open forever. A reception or operatory PC running an end-of-life Windows while holding patient records is a standing PHIPA and HIPAA exposure, not a someday-problem. We made that case in detail when a Windows update knocked Server 2019 domain controllers offline — the lesson there and here is the same: know what you run, and know its lifecycle.

Some Windows versions received their final update this month. An unsupported operating system holding patient data is a standing compliance risk.

What to do this week

Confirm your Windows machines are updating. Check that the October cumulative update is installed on every workstation and server — not just assumed. A device that silently stopped updating months ago is the one that gets hit.
Prioritise CVE-2026-96951. It is the exploited flaw with a public deadline, and it directly weakens your email-attachment defences. Make sure it is covered before anything else in this batch.
Test before mass deployment. A record-sized release is also a larger surface for update side-effects. Apply to one representative machine first, confirm your practice-management software and imaging bridges still launch cleanly, then roll out. This is exactly the caution that pays off when a patch itself breaks a critical server.
Remind the front desk, briefly. Until every machine is patched, the Mark-of-the-Web warning cannot be relied on. A 60-second note — verify unexpected attachments with the sender before opening — closes the gap that the flaw opens.
Patch more than Windows. This release is the Microsoft stack; the same discipline applies to everything else, as the recent office-document flaws that run code the moment a file opens showed. Attackers do not limit themselves to one vendor.

The habit behind a calm Patch Tuesday

A 1,400-fix month sounds alarming and is mostly routine — if you have a routine. The practices that handle these calmly are not the ones with the biggest security budget; they are the ones that patch on a schedule, test before they deploy, and keep a short list of what is actually under attack so they know what to do first. That same discipline is what turns an emergency like last week’s out-of-band Exchange Server patch into a non-event. And when prevention does fail, it is a tested, immutable, air-gapped backup — not the patch log — that decides whether a bad day becomes a closed practice.

The calm response is a routine: prioritise the exploited fix, test on one machine, then deploy across the practice and verify.

How Compudent Systems can help

At Compudent Systems, we manage exactly this for dental practices across the GTA and Ontario. We confirm every workstation and server is current, prioritise and verify the flaws that are actually being exploited — like CVE-2026-96951 — test updates against your practice-management and imaging software before they go out, and flag any machine running a Windows version that has reached end of support so it can be replaced or upgraded before it becomes a compliance problem. Contact Compudent Systems for a patch-readiness and endpoint-lifecycle assessment, and make the next record-breaking Patch Tuesday a routine your office has already rehearsed.

Sources & further reading:

Dental MRI Is Arriving in Practices — and It Is an IT Project Before It Is a Clinical One

Raymond — Tue, 13 Oct 2026 09:40:42 +0000

For more than a century, the dental image has been a picture made with radiation — film, then phosphor plates, then digital sensors, then the 3D volumes of cone-beam CT. A new modality is now entering the operatory that breaks that pattern entirely: magnetic resonance imaging. In early 2026 the first dental-dedicated MRI (ddMRI) system cleared the U.S. FDA, and it has since begun reaching practices through the major dental distributors. It uses no ionizing radiation at all, and it is built to see the soft tissue that X-ray and CBCT render poorly — pulp, nerves, the temporomandibular joint, and soft-tissue pathology.

The clinical case will be made at every study club and trade show this year. This article is about the part that will not be on the booth banner: a dental MRI is an IT project before it is a clinical one. The scan is radiation-free, but the data it produces is anything but weightless, and the network, storage, backup, and integration it demands land squarely on your practice’s technology — the same way every previous imaging advance eventually did.

A dental-dedicated MRI is no longer a hospital-only machine. The first FDA-cleared system is compact enough for a practice — which means the practice’s IT now has to support it.

What the new modality actually is

The system that received clearance is a low-field, helium-free MRI designed specifically for the head and jaw rather than the whole body. The low-field, helium-free design matters because it lowers the siting and facilities burden that has always kept MRI in hospitals and imaging centres — less specialized shielding and infrastructure than a conventional high-field scanner. It is still a magnet, and siting still deserves professional planning, but the premise is a scanner that can realistically live in a dental practice. For the clinician, the draw is straightforward: a radiation-free way to image structures that current dental imaging shows only indirectly.

This continues a long arc we have written about before — the steady transformation of dental imaging from a darkroom craft into a data discipline. If MRI feels like a leap, it is worth remembering that every modality felt that way once; our piece on how dental X-ray imaging became an IT discipline traces how each generation of technology quietly moved the work from the operatory to the server room. MRI is the biggest step in that direction yet.

The clinical leap comes with a data leap

Here is the number that should frame every planning conversation: an MRI study is large. A single intraoral radiograph is a modest file. A CBCT volume is substantially bigger, and most practices already felt that jump when they adopted 3D. A volumetric MRI dataset is larger still — and unlike a quick bitewing, it is the kind of study a practice will want to keep, compare over time, and retain for the full records-retention period.

Multiply one large study by a schedule of patients, across the years your regulatory obligations require you to keep records, and the storage question stops being an afterthought. This is not a reason to avoid the technology; it is a reason to size for it honestly. A practice that bolts a high-volume modality onto storage that was specified for intraoral images and a bit of CBCT will run out of room, slow down, or quietly stop backing everything up — usually discovering which, at the worst possible moment.

The clinical leap comes with a data leap. An MRI study is far larger than the intraoral images and even the CBCT volumes a practice is used to storing and backing up.

It has to move, land, and be found

Capturing the image is only the first step. Every study then has to travel your network, land in storage, and file itself into the correct patient record where a clinician can actually open it. Large datasets moving across an office network that was sized for email and intraoral images will expose every weak link — an aging switch, a tired wireless segment, a workstation that cannot load a big volume without stalling.

Then there is integration, which is where many imaging headaches actually live. A new modality has to speak to your practice management system through the DICOM standard and the connectors — the imaging bridges — that tie acquisition to the patient chart. We have written at length about how fragile that layer can be in our explainer on imaging bridge software; the lesson applies doubly to a brand-new modality. Before you buy, the question is not “does it make great images” but “is there a tested path for those images into the system my team already uses every day, attached to the right patient, viewable on the workstations we have?”

Every MRI study has to travel the same path your other images do — over the network, into storage and archive, and into the right patient’s record — only the files are much bigger.

Backup and retention are not optional extras

Larger, clinically valuable studies raise the stakes on the least glamorous part of IT: backup. If a radiograph is a diagnostic record you are legally required to retain, an MRI study is that same obligation at many times the size. Your backup and archive strategy has to absorb the new data volume without silently falling behind, and it has to be verifiably restorable — not merely “running.”

This is also where imaging intersects with security. Valuable, hard-to-recreate patient data is exactly what ransomware operators hold hostage, which is why we keep returning to the theme of a backup you actually control — immutable and air-gapped. Adding a modality that generates large, irreplaceable studies makes that discipline more important, not less. A practice that cannot restore its imaging archive has not bought an imaging upgrade; it has bought a bigger single point of failure.

A scanner is also a networked computer

A dental MRI, like every modern imaging device, is a networked computer running an operating system, sitting on your practice network, often with vendor remote-access for support. That makes it part of your attack surface as much as your clinical arsenal. It deserves the same discipline as any connected medical device: placed on a segmented part of the network, kept patched or otherwise protected where it cannot be, and covered by a clear understanding of who is responsible for its software security over its service life. The clinical conversation is about what the magnet can see; the IT conversation is about making sure the device cannot become the way an attacker sees everything else.

The right time to size the network, storage, backup, and security for a new imaging modality is before the purchase order is signed — not on installation day.

The questions to ask before the purchase order

You do not need to be an imaging engineer to protect the investment — you need to force the infrastructure questions to the surface while you still have leverage, the same discipline the latest imaging guidance on selecting and documenting studies brings to the clinical side.

How much data per study, and how much per year? Get a concrete figure from the vendor and size storage and backup for several years of it, not for launch week.
Is there a tested DICOM path into our specific practice management system? Ask for written confirmation and, ideally, a demonstration with your software — not “it supports DICOM” in the abstract.
Will our network and viewing workstations actually handle these studies? Have someone assess the switches, cabling, and the computers clinicians will use to open large volumes, before install day.
Can we back up and verifiably restore the new data? Confirm the archive strategy absorbs the volume and that a restore has actually been tested.
How is the device secured and supported over its life? Clarify patching, remote-access, and network placement, and who owns each.

The takeaway

Dental MRI is a real clinical advance and a genuinely exciting one — a radiation-free window onto tissue that dentistry has long struggled to image. But excitement is not an implementation plan. The practices that adopt it well will be the ones that treated it, from the first conversation, as the infrastructure project it quietly is: sizing storage, hardening the network, proving the integration, verifying the backups, and securing the device. The magnet is the easy part to admire. The data is the part that has to be engineered.

A dental MRI is also a networked computer. Treating it as a device to be segmented, patched, and secured — not just a clinical tool — is part of owning one.

How Compudent Systems can help

At Compudent Systems, we help dental practices across the GTA and Ontario bring new imaging technology online without the hidden surprises — sizing the storage and backup, checking that the network and workstations can carry the load, confirming a real integration path into your practice management system, and securing connected imaging devices as the networked computers they are. If a dental MRI, a new CBCT, or any imaging upgrade is on your horizon, contact Compudent Systems for an imaging-readiness assessment, and make sure the infrastructure is ready before the equipment arrives.

Sources & further reading:

First-ever Dental Dedicated MRI Validated in Clinical Trial and Cleared by FDA for Advanced Soft-Tissue Diagnostics

The ADA Now Says Scan Less — So Your Records Have to Say Why: What the 2026 Imaging Guidelines Mean for Your Practice Software

Raymond — Mon, 12 Oct 2026 09:39:42 +0000

For most of the last decade, the question of when to take a dental radiograph had a comfortable, semi-automatic answer: bitewings at recall, a panoramic every few years, a full series for new patients. In early 2026 the American Dental Association, together with the American Academy of Oral and Maxillofacial Radiology, replaced that reflex with something more demanding. In the first major revision of dental imaging guidance since 2012, the message is blunt: image only when clinically necessary, choose the smallest exposure that answers the clinical question, and base the decision on the individual patient in front of you — history, prior films, and risk — rather than the calendar.

Clinically, that is sound radiation-safety practice and few will argue with it. But there is a quieter consequence that lands squarely in the lap of whoever runs your practice’s technology and recordkeeping: if an image must now be justified by a documented clinical reason, then your software, your charting habits, and your retention policy have to be able to prove that reason existed. “We always do bitewings at recall” is no longer a defensible record. This is as much an IT and compliance change as a clinical one.

The 2026 guidance quietly shifts the burden: an image is no longer self-justifying. The record now has to show why it was taken.

What actually changed in the 2026 guidance

The headline is a shift from routine, schedule-driven imaging to individualized, needs-based imaging. The guidance brings two-dimensional radiographs and three-dimensional cone-beam CT under one selection-criteria framework and leans hard on the long-standing ALARA principle — keeping exposure As Low As Reasonably Achievable. Practically, it asks clinicians to review the patient’s history and any existing images first, order imaging only when it will change diagnosis or treatment, and when CBCT is indicated, use the smallest field of view that captures the needed information.

It arrives alongside other moving parts practices are already absorbing, including earlier ADA guidance that routine thyroid and abdominal shielding be discontinued, and a patchwork of state-level rule changes catching up to it — Nevada, for example, moved to align its requirements with ADA guidance as of mid-2026. The result is that “what we have always done” is now out of step with both the national guidance and, increasingly, the rules your own regulator enforces.

Why this is a documentation problem, not just a clinical one

Think about what the new standard implies for the record. If imaging is only appropriate “when clinically necessary,” then the absence of a documented reason is no longer neutral — it is a gap. In an audit, a College inquiry, a malpractice claim, or an insurance review, the question is not just “was the X-ray appropriate?” but “where is the contemporaneous note showing the clinical indication?” A practice that images correctly but documents poorly can still be the one that cannot defend itself.

That exposure is not hypothetical. Dental practices are already under real regulatory and financial scrutiny over how they handle patient records — we have written about a week in which one practice absorbed a six-figure regulatory penalty tied to its recordkeeping and security failures. The new imaging guidance adds one more place where the record has to hold up, and in Ontario it intersects directly with your PHIPA obligations around complete, accurate, and retained health records.

The new model of care: review what already exists, decide whether a new image is genuinely indicated, and record the decision either way.

Build the justification into the software, not the memory

The fix that fails is “everyone, please remember to write why you took the X-ray.” Under pressure, in a busy operatory, free-text good intentions evaporate. The fix that works is structural: capture the clinical justification as a defined field or template inside the practice management system, attached to the imaging event itself, so the record is created as a by-product of normal workflow rather than an extra chore.

Most modern practice management platforms can be configured with custom clinical note templates, required fields, or quick-pick justification codes tied to an imaging order. The goal is that when a radiograph is captured, the chart automatically prompts for and stores the indication — new symptom, specific diagnostic question, treatment planning, trauma, caries risk — alongside the date, the operator, and a link to the image. Done well, compliance stops depending on individual discipline and becomes the path of least resistance.

Where the proof should live: a structured field inside the chart, not a free-text afterthought that no one can find two years later.

Retention and retrieval become clinical tools

The guidance’s instruction to review prior images before exposing a patient quietly raises the stakes on something practices often treat as mere storage. You cannot avoid a redundant radiograph if the earlier one is unfindable, stranded in a retired system, or lost to a failed drive. Retention and fast retrieval of historical images are now part of delivering care to the standard, not just a bookkeeping nicety.

This is where imaging infrastructure earns its keep. Your images have to be retained for the full period your regulator requires, retrievable in seconds at chairside, and portable enough that a change of software does not orphan a decade of history — a fragility we explored in our piece on why imaging breaks when you switch practice management systems. It also has to survive the bad day. A verified, immutable and air-gapped backup of your imaging database is what turns “review the prior image” from an aspiration into something you can actually do after a ransomware hit or a server failure.

A practical checklist for your practice

You do not need to overhaul everything at once. A focused pass across process, software, and policy closes most of the gap:

Add an imaging-justification step to your charting template. Make the clinical indication a structured, prompted field on every imaging event, not an optional free-text note.
Write a one-page imaging policy that cites the 2026 selection-criteria approach. It signals to staff, patients, and any future auditor that your protocol is deliberate and current, not habitual.
Confirm prior images are easy to pull up before exposure. If retrieving last year’s bitewings takes more than a few clicks, your workflow is quietly pushing people toward re-imaging.
Verify retention settings and backups against your regulator’s required period. Know where images live, how long they are kept, and that a restore actually works.
Check your current state and provincial rules. National guidance and local requirements are converging but not identical — confirm yours, especially around shielding and CBCT.

You can only avoid a redundant exposure if the prior image is retained, findable, and actually reviewed first — which makes retention a clinical tool, not just storage.

The takeaway

The 2026 imaging guidance is good medicine: less unnecessary radiation, more deliberate decisions, better care. But “image only when necessary” carries an implicit second half — and be able to show why. The practices that come through this change cleanly will not be the ones that simply image less; they will be the ones whose software, charting templates, and retention policies turn every imaging decision into a defensible record automatically. That is a configuration and process project, and it is one worth doing before, not after, someone asks you to justify a radiograph you took two years ago.

Compliance with the new guidance is largely a configuration and process exercise — set the practice up so the right record is created automatically.

How Compudent Systems can help

At Compudent Systems, we help dental practices across the GTA and Ontario turn clinical guidance like this into systems that actually hold up. That means configuring your practice management software to capture imaging justification as part of normal workflow, confirming your image retention and retrieval meet PHIPA and your College’s requirements, and making sure your imaging history is backed up and portable rather than trapped or at risk. Contact Compudent Systems for an imaging-records and compliance assessment — so when the standard says prove it, your records already do.

Sources & further reading:

One Logged-In Account Could Read the Whole Office’s Email: The Exchange Server Emergency Patch (CVE-2026-96940) Dental Practices Must Apply

Raymond — Sun, 11 Oct 2026 09:37:14 +0000

On October 2, 2026, Microsoft did something it only does when a problem will not wait for the usual monthly schedule: it pushed an out-of-band emergency security update for Exchange Server. The flaw it fixes, CVE-2026-96940, carries a severity score of 8.8 out of 10 and is flagged by Microsoft as “exploitation more likely.” In plain terms, it lets an attacker who is already signed in to your email system read the emails and attachments belonging to other people in the same organization — without needing their passwords and without setting off anything that looks like an attack.

If your dental practice still runs its own email server, this one is yours to act on, and quickly. Here is what happened, why the attachments matter more than the messages, and what to do this week.

The flaw in one picture: a single logged-in account becomes a master key to everyone else’s mailbox in the same organization.

What the flaw actually does

According to Help Net Security, CVE-2026-96940 is a weak authorization bug: an authenticated attacker can read emails and attachments of other users within the same organization, though the flaw “does not allow access across tenant boundaries.” Microsoft says it found the issue internally and is not aware of it being exploited in the wild — but it also notes that this type of flaw has been abused before, which is why it is urging administrators to patch sooner rather than later.

The important word is authenticated. This is not an anonymous intruder on the internet; it is someone who already has a valid login in your environment. That could be a disgruntled staff member, a contractor, or — far more commonly — an outsider who has phished or purchased the password to a single ordinary mailbox. Normally one compromised account exposes one inbox. With this flaw, that same foothold becomes a skeleton key to every mailbox on the server.

Weak authorization means the server never firmly asks whether the mailbox you requested is actually yours to open.

Why this is a dental-practice problem

It is tempting to file “email server bug” under general IT and move on. But stop and think about what actually moves through a dental office’s email. Patient referrals to specialists. Lab prescriptions and case notes. Insurance pre-authorizations and claims correspondence. Scanned consent forms and treatment plans. And increasingly, imaging — radiographs and intraoral photos sent as attachments between the practice, specialists, and labs. Under both PHIPA and HIPAA, every one of those is protected health information, and your duty to safeguard it does not evaporate because the data happens to be sitting in a mailbox.

That is why the attachments, not just the message text, are the real exposure here. The flaw specifically reaches emails and their attachments across the organization. For a practice, that is the difference between an attacker seeing that a referral was sent and the attacker walking away with the referral, the x-ray, and the patient’s insurance details. A single exposed server can quickly become a reportable breach affecting everyone whose information ever passed through it — the same costly aftermath we described when two dental practices were hit in one week, one of them facing a six-figure HIPAA penalty.

On-premises servers only — and why that distinction matters

Here is the good news, and it is worth saying clearly: this flaw affects on-premises Exchange Server, not Microsoft 365 / Exchange Online. If your practice’s email lives in Microsoft’s cloud, Microsoft deployed a service-side fix on its own and there is nothing for you to install. The vulnerable products are the ones you run and maintain yourself — Exchange Server Subscription Edition, Exchange Server 2019 (cumulative updates 14 and 15), and Exchange Server 2016 (cumulative update 23).

This is a recurring theme worth internalizing. When you host your own server, you are the one who has to notice the emergency bulletin, schedule the downtime, and apply the fix — at 2 a.m. if that is when the patch drops. When the service is Microsoft’s responsibility, that burden is simply gone. It is the same lesson that sits behind a vendor freezing its own development to deal with security bugs: the maturity and speed of whoever maintains your infrastructure becomes your security posture, whether that is your own team or a provider.

If your email still runs on a server in your own building, the emergency patch is yours to apply. If it lives in Microsoft’s cloud, the provider already closed this one.

What to do this week

If you are not certain whether your practice runs its own Exchange server or uses Microsoft 365, that uncertainty is itself the first thing to resolve — your IT provider can answer it in minutes. From there:

If you are on Microsoft 365 / Exchange Online: you are covered for this specific flaw. No action needed beyond confirming with whoever manages your tenant.
If you run on-premises Exchange: apply the out-of-band update now. Microsoft’s guidance is explicit that the update belongs not only on the Exchange servers themselves but also on every server and workstation that has the Exchange Management Tools installed, so that management clients and servers stay compatible. Skipping the workstations is a common way to leave a job half-done.
If you run a hybrid setup (some mailboxes on-prem, some in the cloud): you have on-premises Exchange servers, so you are in scope. Patch them.
After patching, verify. Confirm the update installed and the services restarted cleanly — a patch that silently failed to apply is the same as no patch at all.

One scheduling note worth flagging to your IT team: Microsoft’s rollout of this update was, by its own admission, a little disorderly — it arrived ahead of its intended schedule and was initially labelled as a “September 2026 v2” update, briefly without clear documentation. If your administrator was confused by the naming, that is why; the fix is legitimate and should be applied.

In a dental office the real exposure is the attachments: referrals, lab scripts, insurance forms, and imaging all travel through the inbox.

The habit that makes the next one easier

CVE-2026-96940 will not be the last urgent Exchange patch, just as it was not the first internet-facing emergency we have covered recently — from the FortiMail flaw guarding the inbox to the Citrix NetScaler zero-days on the remote-access gateway. The practices that handle these calmly are not the ones with the most expensive tools; they are the ones that know what they run, that have someone watching for emergency bulletins, and that can apply a critical patch within days rather than discovering the problem months later in a breach notice.

Two principles make every future alert less painful. First, reduce how much you have to patch yourself — moving email to a maintained cloud service removes an entire category of 2 a.m. emergencies. Second, wherever you do keep infrastructure in-house, practise least privilege: the fewer accounts with broad access, and the faster departed staff logins are removed, the smaller the blast radius when an “authenticated attacker” flaw like this one appears.

The fix is straightforward once identified: apply the out-of-band update to every Exchange server and management workstation, then confirm it took.

How Compudent Systems can help

At Compudent Systems, we help dental practices across the GTA and Ontario stay ahead of exactly this kind of emergency. We can confirm whether your email runs on-premises or in the cloud, apply the CVE-2026-96940 update across your Exchange servers and management workstations and verify it took, and — where it makes sense — help you move email to a maintained Microsoft 365 environment so the next out-of-band patch is Microsoft’s problem, not yours. We will also review who has access to what, so a single compromised login stays a single-mailbox problem. Contact Compudent Systems for a mail-security and patch-readiness assessment, and turn “there’s an emergency Exchange patch” from a scramble into a routine you have already rehearsed.

Sources & further reading:

What Is Imaging Bridge Software — and Why Your X-Rays Break Every Time You Switch Practice Management Systems

Raymond — Sat, 10 Oct 2026 13:31:28 +0000

Ask a dental team what their practice management software does and they will describe scheduling, charting, billing, and recall. Ask what makes an X-ray appear on screen the instant the sensor is exposed, and most will shrug — it simply works. Until, one day, it does not. The sensor fires, the radiograph is taken, and nothing shows up in the patient’s chart. No error that means anything, no obvious cause, and a waiting room that does not care why.

Behind that moment sits a piece of software almost nobody talks about: the imaging bridge. It is one of the most important components in a modern dental practice and one of the least understood, and it is very often the thing that breaks when you change practice management systems, move to a new computer, or install a Windows update. Understanding what it is will not let you fix it yourself — but it will tell you where the risk lives and what to protect.

Your sensor and your practice software rarely speak the same language. A small, often-overlooked piece of bridge software does the translating — and it is the weakest link in the chain.

What an imaging bridge actually is

Your X-ray sensor, phosphor-plate scanner, and intraoral camera are each made by a manufacturer — Dexis, Carestream, Air Techniques, iTero, and others — and each ships with its own imaging software and drivers. Your practice management system, whether Dentrix, Eaglesoft, Open Dental, abeldent, or another, is made by a different company. These two worlds do not natively understand each other. The bridge is the translator that sits between them.

When a clinician clicks “acquire” inside a patient’s chart, the bridge is what reaches out to the sensor’s software, says “capture an image for this specific patient,” receives the resulting radiograph, and files it back into the correct record. Much of this is done through a decades-old imaging standard called TWAIN, sometimes alongside direct integrations or the medical imaging standard DICOM. We have covered the mechanics of these connections in more depth in our explainer on how dental imaging tools connect through TWAIN, DICOM, APIs, and PMS bridges — the short version is that the bridge is doing quiet, constant translation every single time an image is captured or opened.

The normal flow: the sensor captures, the bridge hands the image to the practice software, and it files itself under the right patient. Every step depends on the one before it.

Why it is so fragile

The bridge’s weakness is structural: it depends on three independently moving parts staying in agreement. The sensor manufacturer updates its drivers. The practice management vendor updates its software. Microsoft updates Windows. Each of those updates is reasonable on its own, and any one of them can quietly break the handshake the bridge relies on.

This is why imaging problems so often appear out of nowhere “without anyone changing anything.” Usually something did change — a background update, a new permission requirement, a driver that no longer loads the way the bridge expects. We have seen exactly this pattern when operating-system updates disrupt otherwise-stable systems; our write-up on a Windows update that knocked domain controllers offline is a reminder that the most disruptive IT failures in a practice rarely announce themselves. A broken bridge behaves the same way: the sensor still powers on, the software still opens, but the two can no longer talk.

Why switching software is the riskiest moment of all

If a routine update can break a bridge, replacing the entire practice management system is the high-wire act. When you migrate to new software, the new system needs its own bridge to every imaging device you own — a bridge written, tested, and licensed for that specific combination of sensor and software. A sensor that worked flawlessly for a decade can suddenly have no supported path into the new system, not because the hardware failed, but because nobody built or verified the connector for that pairing.

Then there is the data. Years of radiographs living in your old system are not always stored in a neutral, portable format. Some vendors keep images in proprietary databases that do not export cleanly, which means a migration can range from a straightforward transfer to a painstaking extraction — or, in the worst cases, a decision to keep the old system running in read-only form purely to retain access to patient history. This is the quieter face of vendor lock-in: the barrier to leaving is not the software license, it is your own imaging archive.

The most common failure after a software change: the sensor fires, the X-ray is taken, but the image never makes it into the chart — because the bridge no longer connects the two.

The questions that de-risk a software change

You do not need to become an imaging engineer to protect yourself. You need to force the compatibility questions to the surface before you commit, when you still have leverage, rather than discovering the gaps on go-live morning.

“Is every one of our imaging devices on your supported bridge list?” Provide the new vendor an inventory of each sensor, scanner, camera, and pan/CBCT unit by make and model. Ask for written confirmation that a tested bridge exists for each — not “it should work.”
“Will our existing images come across, in full resolution, attached to the right patients?” Clarify whether historical radiographs migrate into the new system or stay behind, and in what format. Ask to see a test migration of a sample of real records before signing off.
“What happens to our data if we ever leave you?” A vendor confident in its product will give a clear, non-defensive answer about export in a standard format such as DICOM. Evasiveness here is itself the answer.
“Who owns the bridge when it breaks — you, the sensor maker, or us?” Bridge failures notoriously fall into a finger-pointing gap between vendors. Establish before purchase who is accountable for fixing the connection when an update breaks it.

What practices can do on their own side

A few disciplines dramatically reduce imaging risk regardless of which software you run. Keep a current inventory of every imaging device with its make, model, and driver version, so a compatibility conversation takes minutes instead of a scavenger hunt. Do not let sensor drivers, imaging software, and the operating system update blindly on production machines; changes to clinical workstations deserve to be tested, not trusted. Before any migration or major upgrade, confirm you have a verified, restorable backup of your imaging database specifically — not just “the server” in the abstract. And treat imaging continuity as part of your broader resilience plan; if radiographs are down, so is much of your clinical day, which is exactly why imaging belongs in the same modern imaging workflow planning as the tools you are adding, not just the ones you are replacing.

When imaging is stored in one vendor’s proprietary format, moving to a new system is rarely a clean copy — some of your history can be effectively locked in place.

The takeaway

The imaging bridge is a perfect example of a dependency that is invisible right up until it fails. It quietly earns its keep thousands of times a week and gets no credit, then becomes the single point of failure that stops a practice cold. The practices that handle software changes without a crisis are not lucky — they are the ones who treated the bridge as a first-class part of the decision, inventoried their devices, demanded written compatibility answers, protected their data, and tested before they trusted. A software switch should never be the reason a dentist cannot take an X-ray.

A software switch succeeds or fails before it begins: on whether someone confirmed every sensor, scanner, and image archive will still work on the new system.

How Compudent Systems can help

At Compudent Systems, we help dental practices across the GTA and Ontario manage exactly this kind of hidden complexity — the sensors, bridges, imaging databases, and practice management systems that have to work together flawlessly or not at all. Whether you are evaluating a move to new software, troubleshooting an imaging connection that suddenly stopped working, or simply want a clear inventory and a tested backup of your imaging data before your next upgrade, we can make sure the bridge holds. Contact Compudent Systems for an imaging and practice-systems assessment — and turn “why won’t the X-ray open?” from an emergency into a problem you planned for.

Two Dental Breaches, One Week: A Ransomware Hit, a $140K HIPAA Penalty, and What Your Practice Must Do Now

Raymond — Fri, 09 Oct 2026 14:31:46 +0000

Within a single week this October, two very different dental practices served as cautionary tales. A multi-location family dentistry group in North Carolina turned up on a ransomware crew’s leak site, its patient records allegedly among 20 gigabytes of stolen data. Days earlier, a Pennsylvania dental practice agreed to pay $140,000 to the U.S. Department of Health and Human Services to settle a HIPAA case. The two incidents share no attacker, no vulnerability, and no common thread — except the one every practice owner should take to heart: a dental office can be hurt by the criminal and by the regulator, and defending against one does nothing to defend against the other.

Two separate ways to get hurt in the same week: the criminal who breaks in, and the regulator who holds you to account for how you handle patient data.

Incident one: a dental group on a ransomware leak site

According to reporting from ClassAction.org, O2 Dental Group — a six-location family dentistry practice in North Carolina — may have suffered a data breach. An October 5, 2026 post on a dark-web monitoring site attributed the attack to the ransomware group Interlock, which claimed the incident compromised patient health records, billing and insurance documents, and authorization forms, with a separate monitoring service reporting a claim of roughly 20 gigabytes of data. It is important to be precise here: at the time of writing these are the attackers’ claims as surfaced by monitoring sites, and the practice has not publicly confirmed the scope or nature of the incident. Claims on leak sites are sometimes exaggerated to pressure a payment.

But the pattern is familiar and it does not depend on the exact numbers. Ransomware crews now routinely steal data before they encrypt it, then post a listing naming the victim to force a decision. By the time a practice sees its name on a leak site, the exposure has usually already happened. We walked through how this plays out when a single compromised account exposed tens of thousands of patients at another dental practice — and the entry points are mundane: a reused password, a phishing email, or a remote-access tool left exposed.

Incident two: a $140,000 penalty with no hacker involved

The second case is the one that surprises people. As the HIPAA Journal reports, the owner of a Pennsylvania dental practice agreed to pay $140,000 to HHS’s Office for Civil Rights — the 56th financial penalty under OCR’s Right of Access enforcement initiative. The trigger was not a breach at all. It began with a complaint that the practice had failed to provide a patient a copy of their records despite repeated requests. When investigators asked for the practice’s policies and procedures, the documentation could not be produced; the practice stated the relevant records had been stolen by a staff member, and when asked for its breach-notification policies and any notifications issued over that theft, the answer was “none.”

That is the quiet lesson buried in the headline. A regulator can penalize a dental practice heavily for ordinary administrative failures — not answering a patient’s request for their own records, not having written policies, not having a breach-notification process — entirely separate from whether anyone was ever hacked. Security protects you from the attacker. Compliance protects you from the regulator. You need both, and they are not the same work.

Modern ransomware crews steal the files first, then publish a listing to pressure payment — the exposure happens before any encryption does.

Why this matters for a practice in Ontario, not just the U.S.

These two cases are American, but the obligations they illustrate map directly onto Ontario and the rest of Canada. Under PHIPA, a dental practice is a health-information custodian: patients have a right to access their records, and the practice must notify affected individuals — and, at the first reasonable opportunity, the Information and Privacy Commissioner of Ontario — when personal health information is stolen, lost, or used or disclosed without authority. A ransomware crew copying your patient files is exactly that kind of event. The dollar figures differ across borders; the duty to protect patient data, produce it when a patient asks, and report when it is breached does not.

What your practice should do now

Treat the pair of stories as a checklist covering both fronts — keeping the attacker out, and being able to prove you handled patient data properly.

Close the common entry points. Enforce multi-factor authentication on every account that touches patient data, retire reused and shared passwords, and lock down remote access. Attackers increasingly ride in through legitimate tools — we covered how remote-management software gets turned against a practice — so inventory what is installed and remove what you do not use.
Segment the network. The imaging server, the practice-management database, the front-desk workstations, and any guest Wi-Fi should not all sit on one flat network where a single compromised PC can reach everything. Segmentation limits how far an intruder — or ransomware — can spread.
Make recovery something you own. A clean, offline, immutable and air-gapped backup covering both your practice-management data and your imaging is the only ransomware exit you fully control — and the only way to say no to a ransom with confidence.
Write the policies the regulator expects to see. Have documented procedures for patient records-access requests, for administrative safeguards over who can use and disclose patient data, and for breach notification. The Pennsylvania case turned a records dispute into a six-figure penalty precisely because those documents did not exist.
Rehearse the incident-response plan. Decide in advance who declares an incident, who isolates systems, how you preserve evidence, how the front desk keeps running, and crucially who notifies whom and by when. A plan practised before the bad night is the difference between an orderly response and an improvised one.

Regulators penalize administrative failures — ignoring a records request, missing policies — not only cyberattacks. The $140,000 case was about access and paperwork, not a hacker.

Security and compliance are one project

It is tempting to file “cybersecurity” and “HIPAA/PHIPA compliance” in separate drawers — one for the IT company, one for the lawyer. These two October cases show why that split is a trap. The same patient record that an Interlock-style crew wants to steal is the record a patient has a legal right to receive and that you are legally obligated to protect and, if breached, to report. Lock it down and you have done the security half. Be able to produce it, document how you guard it, and notify properly when something goes wrong, and you have done the compliance half. Skip either and one of these two stories becomes yours.

A written, rehearsed incident-response plan turns a chaotic night into an orderly sequence: isolate, preserve, restore, and notify within the deadlines the law sets.

How Compudent Systems can help

At Compudent Systems, we help dental practices across the GTA and Ontario tackle both fronts at once. On the security side we deploy multi-factor authentication, network segmentation, and immutable, air-gapped backups that cover your imaging as well as your practice-management data. On the compliance side we help you build the records-access, safeguard, and breach-notification policies PHIPA expects, and a rehearsed incident-response plan so a bad night follows a script instead of panic. Contact Compudent Systems for a combined security and compliance assessment — so neither the attacker nor the regulator catches your practice unprepared.

Security and compliance are the same project: MFA and segmentation keep attackers out, while policies and backups prove you can protect and produce patient data when asked.

Sources & further reading:

The “Recovery” Firm Was Secretly Paying the Ransom: Why an Immutable, Air-Gapped Backup Is the Only Exit Your Dental Practice Controls

Raymond — Thu, 08 Oct 2026 12:02:20 +0000

When ransomware encrypts a dental practice, the owner is suddenly confronted with a decision no one wants to make: pay the attackers for a promise, or try to recover another way. A criminal case filed in early October 2026 shows just how murky that first option really is. According to a BleepingComputer report, the owner of a prominent ransomware-remediation company, MonsterCloud, has been charged with defrauding victims — allegedly by quietly paying the attackers for decryptors while telling clients the firm used its own proprietary technology to recover the data.

Read that again, because it reframes the whole problem. A business that victims hired specifically to avoid paying a ransom was, prosecutors allege, paying it anyway and marking up the bill. If you cannot even be sure the “recovery” you are buying is anything more than the ransom with a service fee attached, then the uncomfortable truth is that almost nothing about a ransomware incident is under your control — except one thing you build long before the attack.

The exit you control: a copy of your data that is written once, physically disconnected, and cannot be encrypted or deleted — even by an attacker inside your network.

Why paying is the worst door to be standing in front of

Setting aside the fraud case for a moment, paying a ransom is a bad position on its own merits. You are trusting criminals to hand over a working decryptor; many are slow, buggy, or never materialize. You are funding the next attack, including the next one against a practice like yours. And increasingly, you may not legally be allowed to pay at all: if the gang behind the attack is on a sanctions list, sending them money can expose your practice to penalties regardless of intent. Modern ransomware also steals the data before encrypting it, so paying does nothing to undo the exposure — the records are already gone.

We have written before about how a ransomware claim lands on a practice when its name appears on a leak site, and how the FBI keeps refreshing its warnings about ransomware aimed at healthcare. The throughline is always the same: the practices that recover cleanly are the ones that did not have to negotiate at all, because they could simply restore.

The one exit you own: a backup the ransomware cannot touch

A restore is only an exit if the attacker cannot reach the backup. This is the part practices most often get wrong. Modern ransomware operators do not just encrypt your live data — they specifically hunt for backups first, because a victim with good backups does not pay. A backup drive left plugged into the server, or a backup account reachable with the same domain password the attacker already stole, gets encrypted right alongside everything else. The backup existed; it just did not survive.

Two properties turn a backup from a liability into a genuine exit:

Immutable — the backup is written once and cannot be altered or deleted for a set retention period, even by an administrator account. In storage terms this is often called WORM (write once, read many) or object lock. If ransomware — or a stolen admin login — tries to encrypt or wipe it, the storage simply refuses.
Air-gapped — at least one copy is kept physically or logically disconnected from the live network, so there is no path for malware to travel to it. That can be removable media rotated offsite, or a cloud copy that is isolated behind separate credentials and multi-factor authentication the attacker never obtained.

A backup that is both immutable and air-gapped is the thing MonsterCloud’s clients were allegedly paying for and not reliably getting: a clean, intact copy of your data that you can restore on your own terms, on your own timeline, without a single dollar going to a criminal.

Paying is a gamble with legal strings attached. Restoring from a clean backup is a procedure you own end to end.

Start with 3-2-1 — and be able to prove it

The time-tested baseline is the 3-2-1 rule: keep three copies of your data, on two different types of media, with at least one copy offsite. For a dental practice, “your data” is not just the practice-management database — it is the imaging too: the intraoral sensor captures, the CBCT volumes, the photography. Those files are large, and a backup plan that quietly excludes the imaging server to save space is a backup plan that fails on the day you need it most.

The modern refinement adds immutability and air-gapping to that third copy, which is where the real ransomware protection lives. The question to be able to answer is not “do we have backups?” — almost everyone says yes — but “can we prove we have three copies, including one offline and immutable, covering every system that holds patient data?”

A backup you have never restored is only a hope

The MonsterCloud case is, at its heart, a story about the gap between what people believed they were getting and what they actually had. Backups have the same failure mode. A backup job that reports “success” every night can still be quietly backing up a corrupted database, skipping the imaging share, or writing to media that cannot actually be read back. You only find out at the worst possible moment.

The fix is to perform real test restores on a schedule — not just confirm the job ran, but actually pull the data back and open it. Restore the practice-management database into a test environment and log in. Open a CBCT volume and a set of sensor images and confirm they render. A recovery you have rehearsed is a procedure; a recovery you have only assumed is a gamble.

Three copies, on two kinds of media, with at least one kept offsite and offline — the baseline every practice should be able to prove it meets.

Protect the tools that protect your data

One more lesson from the past year deserves a place here: your backup software is itself a target. We covered the actively-exploited flaw that turned a popular backup tool into an attack vector, a reminder that the system guarding your last line of defense needs the same patching discipline, strong unique credentials, and multi-factor authentication as everything else. An immutable, air-gapped copy is your insurance even here: if the backup console itself is compromised, the locked offline copy is what you fall back to.

Tie it all into a written recovery plan

Backups are the foundation, but recovering a dental practice is more than copying files back. Who declares the incident? In what order do systems come back — domain, server, practice-management, imaging, workstations? How does the front desk keep seeing patients while the restore runs? Those answers belong in a written downtime and business-continuity plan, rehearsed before you need it. The immutable backup gives you something to restore; the plan is what turns it into a practice that is seeing patients again by the afternoon instead of the following week.

A backup you have never restored is a hope, not a plan. The test restore is where you learn whether the exit actually opens.

The takeaway for your practice

The charges against a ransomware-recovery firm for secretly paying ransoms are a warning that the “easy button” after an attack may be neither easy, honest, nor legal. The only exit a dental practice fully controls is the one it builds in advance: three copies of every system that holds patient data, at least one of them immutable and air-gapped, restored and verified on a regular schedule, and wrapped in a recovery plan the team has actually practised. Get that right, and a ransom demand stops being a crisis and becomes a line you can decline.

No single safeguard is enough. Immutability, an air gap, verified restores, and a written plan work together as layers.

How Compudent Systems can help

At Compudent Systems, we design and manage ransomware-resilient backup for dental practices across the GTA and Ontario — including immutable, air-gapped copies that attackers cannot encrypt, coverage that spans your imaging as well as your practice-management data, and scheduled test restores so you know your recovery works before you need it. We also build the downtime and business-continuity plans that turn a clean backup into a practice back at the chair the same day. Contact Compudent Systems for a backup and ransomware-recovery assessment — so the day someone demands a ransom, your answer is already a confident “no.”

Sources & further reading:

Ransomware recovery CEO charged over secret ransom payments — BleepingComputer

No Malware Required: How an “IDOR” Flaw in Dental Software Exposed Patient Records — and the Questions to Ask Your Vendor

Raymond — Wed, 07 Oct 2026 09:40:18 +0000

Most of the breaches a dental practice reads about involve something dramatic: ransomware locking the schedule, a phishing email that stole a password, a server encrypted overnight. A disclosure at the start of October 2026 is a useful reminder that some of the worst exposures involve none of that. According to a report on OffSeq’s Threat Radar, a European dental-software vendor had patient and staff records exposed through a flaw that required no malware, no stolen credentials, and no clever social engineering. The attacker simply changed a number in a web request.

The flaw has an unglamorous name — IDOR, or insecure direct object reference — and it is one of the most common serious weaknesses in web and mobile software. It is worth ten minutes of a practice owner’s attention, not because you can patch it yourself, but because understanding it changes the questions you ask the companies that hold your patients’ data.

The entire attack: change one number in the request, and the next patient’s record opens — no password, no malware, no warning.

What actually happened

The vendor, FELG Software, makes a practice application used by dental offices. Per the report, an attacker calling themselves “Horus” found that the application’s API — the behind-the-scenes interface the software uses to fetch records — would hand back a patient’s data based purely on an identifying number in the request, without first checking whether the person making the request was allowed to see that record. By incrementing the number — 1, 2, 3, and so on — the attacker could walk straight through the database, pulling patient and staff information one record at a time, and then issued a ransom demand.

That is the entire attack. No encryption, no exploit kit, no password cracking. A legitimate-looking request, repeated with a different number each time.

Why IDOR is so easy to miss

Every modern application refers to things by identifiers: patient #4471, image #9052, invoice #11388. Those numbers routinely appear in web addresses and API calls — that part is normal and fine. The flaw is not the visible number; it is the missing check behind it. Secure software, every single time a record is requested, asks a second question: “is the person asking actually entitled to this particular record?” IDOR is what happens when the software skips that question and trusts the number alone.

This is why security professionals file it under broken access control — currently the number-one category on the industry’s OWASP Top 10 list of web application risks. It is insidious precisely because the feature works perfectly for honest users. Nothing crashes, nothing looks wrong, and ordinary testing rarely catches it, because ordinary testing checks that you can see your data — not that you are stopped from seeing someone else’s.

The flaw is an absence, not a presence: the software never stops to ask whether the record you requested is actually yours to see.

How it differs from the flaws we usually discuss

We recently explained how SQL injection can expose data inside practice-management software, and the two are worth telling apart, because the defenses differ. SQL injection tricks a database into running commands it was never meant to run — the attacker injects something foreign. IDOR injects nothing. It uses the application exactly as designed and simply asks for records that should have been off-limits. One is a break-in; the other is an unlocked door. A practice does not need to know how to fix either, but knowing they are different helps you recognize that “our vendor said they protect against hackers” is not a complete answer.

Why this is a dental-practice problem, not just a software problem

It is tempting to read “vendor flaw” and conclude there is nothing to do. But the records exposed in a breach like this are your patients’ records, and under PHIPA and HIPAA the obligation to safeguard that information does not fully transfer to a vendor just because the data lives on their servers. When you entrust patient data to a cloud practice-management system, an imaging platform, a patient-communication tool, or an online booking service, you are trusting that each of those vendors wrote their access checks correctly — something you cannot see and did not test.

This is the same uncomfortable lesson behind a vendor freezing its own development to deal with security bugs: your practice inherits the security maturity of every supplier it relies on. And the consequences land on you. A single exposed database can become a reportable breach affecting thousands of people, exactly as it did when one compromised account exposed 45,853 patients at another practice. The cause differs; the aftermath — notification letters, regulatory scrutiny, lost trust — looks the same.

When the software lives on the vendor’s servers, the flaw is on their side of the line — but the exposed records are still your patients’.

The questions to put to your software vendors

You cannot read your vendors’ source code, but you can ask questions whose answers reveal whether they take access control seriously. Vague or defensive responses are themselves an answer.

“Do you perform independent security testing, and how often?” A mature vendor commissions regular third-party penetration tests and application security assessments. IDOR is a flaw a competent tester looks for specifically; a vendor that tests will usually have found and fixed its own before an attacker did.
“How does your system verify that a logged-in user can only access their own practice’s and patients’ records?” You want to hear that authorization is checked on every request, server-side — not that access is controlled only by what the user interface shows.
“Do you keep access logs, and would you be able to tell us which records were accessed if there were an incident?” If a breach happens, the ability to scope it precisely is the difference between notifying the handful of affected patients and having to notify everyone.
“What is your breach-notification commitment to us, in writing?” Your regulatory clock starts when you learn of an exposure. A vendor contract should obligate prompt notification, not a quiet mention weeks later.
“Who else can see our data, and where is it hosted?” Sub-processors and data residency matter for both compliance and your own understanding of the risk surface.

You cannot audit your vendor’s code — but you can ask the questions that reveal whether they take access control seriously.

What you can control on your own side

Vendor diligence is the main lever here, but a few practice-side habits reduce the blast radius of any exposure. Grant staff only the access they genuinely need inside each system, so a single account — or a single flaw — reaches less. Remove logins the moment someone leaves. Keep an inventory of every third-party service that touches patient data, so that when a breach notice arrives you already know whether you are affected. And treat a vendor’s security answers as part of the buying decision, not an afterthought once the contract is signed.

No single control is enough. Ownership checks, access logging, least privilege, and vendor accountability work as layers.

The pattern behind the headline

The enduring lesson of an IDOR breach is that a catastrophic data exposure does not require a sophisticated attacker — only a missing check and someone patient enough to count upward. For a dental practice, the defensible position is not to become web-security experts, but to choose and hold accountable the vendors who are. The practices that come through incidents like this best are the ones that asked the hard questions before they signed, kept a clear picture of who holds their data, and had a plan for the day a supplier calls with bad news.

How Compudent Systems can help

At Compudent Systems, we help dental practices across the GTA and Ontario manage the risk that comes with every piece of software and every vendor that touches patient data. We can help you inventory the systems and third parties holding your PHI, put the right security and breach-notification questions to your vendors, tighten access and account hygiene inside your practice, and build an incident-response plan so a vendor’s bad day does not become your compliance crisis. Contact Compudent Systems for a security and vendor-risk assessment — and turn “our software company had a breach” from a scramble into a procedure you have already rehearsed.

Sources & further reading:

Polish dental software vendor FELG reports patient data breach and ransom demand — OffSeq Threat Radar

A Spreadsheet That Runs Code the Moment You Open It: The LibreOffice and OpenOffice Flaws Dental Offices Should Patch Now

Raymond — Tue, 06 Oct 2026 12:36:10 +0000

Most dental teams have been trained to fear one thing when a document lands in their inbox: the macro warning. Open an attachment, see the yellow bar asking whether to enable macros, and you know to stop and think. A disclosure published on October 6, 2026 by The Hacker News describes something more unsettling — a booby-trapped spreadsheet that makes LibreOffice or Apache OpenOffice run an attacker’s code the instant the file is opened, with no macro warning at all. The safeguard your staff rely on never appears.

If your practice uses either of these free office suites — and a great many do, on reception machines and back-office PCs, precisely because they are free — this is worth ten minutes of attention today.

The danger of this flaw is what is missing: the file runs code on open, with none of the warnings users are trained to expect.

What researchers actually found

Security researchers demonstrated that a specially crafted spreadsheet can achieve remote code execution: opening the file is enough to run commands of the attacker’s choosing on the computer, at the privilege level of whoever opened it. There is no “enable content” prompt, no macro bar, no second chance to say no. The flaw is tracked as CVE-2026-63277 in LibreOffice and as the matching CVE-2026-59265 in Apache OpenOffice.

One important qualifier: as reported, the attack has only been shown as a proof of concept, and there are no reports yet of it being used in real-world attacks. That is the good news — and the reason to patch now, before a working exploit circulates, rather than after.

Why there is no warning — the clever part

What makes this flaw instructive is that it does not rely on a single broken feature. It chains together capabilities that each work exactly as designed. A Calc spreadsheet can contain a database range: a block of cells that pulls in data from an outside source and refreshes itself automatically. That external source can be made to deliver far more than numbers. Combined with the program’s Java support, the refreshing data range can be steered into executing code rather than simply importing it.

Because each ingredient is a legitimate feature, none of them trips the macro-security prompt. The attack lives in the gap between two trusted behaviours — which is exactly the kind of blind spot that bypasses user training. A critical detail for mitigation: the attack only works when the program’s Java support is enabled.

A macro prompt (left) gives the user a choice. This attack (right) removes that choice.

What is fixed and what is not

The two projects are in very different places, and this is the part practice owners need to get right:

LibreOffice has already fixed it. The patch shipped in updates released on October 5, 2026. LibreOffice recommends moving to version 26.2.5 or 26.8.0; every version before those is affected.
Apache OpenOffice has not fixed it yet. Every version up to and including the current release, 4.1.16, is affected. The project says a fix is expected in version 4.1.17, which is still being tested. Until that arrives, OpenOffice users are exposed unless they take a manual step.

The attack abuses ordinary features — a self-refreshing external data range plus Java — that each behave as designed on their own.

Why this matters more in a dental office than you might think

A dental practice is a near-perfect target for a document-borne attack, for reasons that have nothing to do with how careful your team is. The front desk opens unfamiliar attachments all day: insurance remittances, patient intake forms, supplier invoices, referral letters from other offices. A malicious spreadsheet does not need to look exotic — it needs to look like a Tuesday.

And the machine that opens it is rarely isolated. On a typical practice network it can see the practice-management database, the imaging share, and whatever cloud sessions are logged in. Code running as the front-desk user is code running with the front desk’s reach into patient data — which, under PHIPA and HIPAA, turns a “someone opened a bad file” moment into a potential reportable breach. The same uncomfortable logic applies to any workstation flaw that executes with the user’s own permissions, which is why we treat seemingly minor desktop CVEs as practice-wide events, not just one person’s problem.

What to do this week

None of the fixes here are difficult. They just have to actually happen on every machine, not only the one you remember.

Inventory first. Find every computer in the practice running LibreOffice or Apache OpenOffice — including the quiet back-office PC nobody logs into much. You cannot patch what you have forgotten about.
Update LibreOffice now to 26.2.5 or 26.8.0. If your office is on a much older release, this is also a good moment to get current rather than inch forward.
On Apache OpenOffice, disable Java until 4.1.17 ships. Because the attack requires Java support, turning it off in the program’s settings blocks this flaw outright. Most practices never use OpenOffice’s Java features anyway. When 4.1.17 is released, update to it.
Reinforce the oldest rule: do not open spreadsheets you do not trust. A referral or invoice you were not expecting deserves a phone call to confirm before it is opened, especially while OpenOffice remains unpatched.
Consider consolidating. If free office suites are scattered across the practice without anyone tracking versions, that sprawl is the real vulnerability. Knowing what software runs where, and keeping it current, is the whole game.

In a practice, the opening move is almost always an emailed attachment — an invoice, a form, a referral — landing at the front desk.

The pattern behind the headline

It is tempting to file this under “another CVE” and move on. The more useful takeaway is the mechanism: attackers increasingly string together ordinary, approved features to slip past the warnings users are trained to heed. You cannot train your way out of a threat that shows no prompt. What protects a practice is the unglamorous discipline underneath — knowing every piece of software on every machine, keeping it patched, and removing features (like unused Java support) that only widen the attack surface.

Two clean fixes: install the patched version, and — especially on OpenOffice — turn off Java support until a fix ships.

How Compudent Systems can help

At Compudent Systems, we manage the desktops and networks behind dental practices across the GTA and Ontario, which means keeping an inventory of what runs where and patching flaws like CVE-2026-63277 before they become incidents. We can audit your practice for vulnerable LibreOffice and OpenOffice installs, apply the fixes, disable unnecessary high-risk features, and put a patch-management routine in place so the next document-borne flaw is handled quietly in the background. Contact Compudent Systems for a security assessment and proactive patch management — and turn “someone opened a bad file” from a crisis into a non-event.

Sources & further reading:

LibreOffice and OpenOffice Flaws Let Malicious Spreadsheets Run Code Without Macro Warnings — The Hacker News

When Your Domain Controller Won’t Boot: KB5122876, the Server 2019 BSOD, and What Dental Practices Should Do

Raymond — Mon, 05 Oct 2026 17:01:50 +0000

In the last week of September 2026, a familiar kind of story started spreading through the forums where system administrators compare notes: install Microsoft’s latest Windows Server updates, reboot, and watch the server die. On Reddit’s r/sysadmin and Microsoft’s own community forums, administrators reported the same thing with unsettling consistency — every Windows Server 2019 domain controller in their environment fails to boot after the August and September 2026 cumulative updates, including the September rollup KB5122876. One admin called the behaviour “100% reproducible” across both writable domain controllers and read-only ones.

For a large enterprise with a dozen domain controllers, that is a bad week. For a dental practice running a single server in a closet behind the front desk, it is the whole office going dark. If that server is your practice’s domain controller, this is a story worth understanding before Windows Update decides the timing for you.

When the one server that runs the whole office refuses to boot, every workstation goes dark with it.

The symptom: the server installs the update, then never comes back

The pattern administrators describe is specific. The update installs successfully. The server reboots to finish applying it, reaches roughly 30 percent, restarts again — and then crashes during start-up with a CRITICAL_SERVICE_FAILED blue screen. From there the machine enters a boot loop and never finishes starting. What makes it stranger is how selective it is: in the reported environments, every Server 2019 machine acting as a domain controller failed, while ordinary member servers on the exact same build took the same updates without a hiccup. Something about the domain-controller role is the trigger.

The updates named in these reports are the August 2026 cumulative update (KB5120238) and the September 2026 cumulative update (KB5122876), along with their companion .NET Framework updates. KB5122876 is the September 8, 2026 security rollup for Windows Server 2019 and Windows 10 version 1809 — the kind of patch most practices install automatically, exactly as they should for security, which is what makes a boot-breaking regression so painful.

What the crash actually is

The administrators who dug into the crash dumps landed on a consistent answer. The bugcheck is 0x0000005A (CRITICAL_SERVICE_FAILED), and a key parameter resolves to status code 0xC0000428 — which Windows spells out as “Windows cannot verify the digital signature for this file.” The crash happens deep in start-up, while Windows is loading its drivers. In plain terms: during boot the server tries to load a driver, decides it cannot trust that driver’s signature, and because the failure happens at a critical early stage, the only thing it can do is stop.

The working theory from the field is a boot-time driver signature validation problem introduced by the cumulative update chain that, for reasons not yet pinned down publicly, only bites on Server 2019 domain controllers. As of those reports it was being actively investigated rather than formally resolved — which is the honest status of a great deal of patch trouble in its first days. You do not need to understand the kernel internals to act on it; you need to know the symptom, the recovery, and how to avoid walking into it.

The update installs, reboots, crashes during driver loading, and loops — Windows reporting it cannot verify a digital signature.

Why a dead domain controller is a whole-practice emergency

In most small and mid-sized dental practices, the “server” is not just file storage. It is the domain controller — the machine that handles staff logins, hands out network addresses through DHCP, and answers name lookups through DNS. When it is healthy, nobody thinks about it. When it will not boot, the symptoms cascade: staff cannot log in, workstations lose their network settings, the practice-management software cannot reach its database, and imaging stations lose the share they save to. The front desk is not slow — it is stopped.

That is why this particular bug deserves more attention than its obscure bugcheck code suggests. A flaw that merely slows things down is an annoyance. A flaw that keeps the one central server from starting is a same-day closure unless you are prepared. If you have ever thought through what your office does when the computers are down, this is precisely the scenario those plans exist for — the kind we walked through in building a downtime and business-continuity plan for a dental practice.

In most practices the domain controller also quietly handles logins, DNS and DHCP — when it stops, almost everything stops.

If your domain controller is already in a boot loop

If this has already happened to you, do not keep forcing reboots and hoping — a domain controller stuck at CRITICAL_SERVICE_FAILED will not fix itself, and repeated hard power-offs risk corrupting the Active Directory database. The recovery that administrators report actually works is to boot the server into the Windows Recovery Environment (WinRE) and reverse the half-applied update:

Get into recovery. Interrupt the boot a few times to trigger WinRE, or boot from Windows Server installation media and choose Repair your computer, then open a command prompt.
Revert the pending update. The command that resolved it in the field is dism /image:C:\ /cleanup-image /revertpendingactions (adjust the drive letter if your Windows volume is not C: inside recovery). This rolls back the update that was mid-installation.
Reboot. After reverting, the server starts normally on the previous, working state.
Then pause, do not re-apply. Once you are back up, keep that specific update from reinstalling until there is a confirmed fix — and check Microsoft’s Windows release health dashboard, because Microsoft issued out-of-band fixes for other September 2026 Server update problems, and a formal resolution for this one may follow the same path.

If your only domain controller is down and you are not comfortable working inside the recovery environment on the server that holds your entire directory, this is the moment to call your IT support rather than experiment. The cost of a mistake on a lone domain controller is high.

The working recovery is to boot into the repair environment and revert the pending update so the server starts normally.

How to keep it from happening in the first place

The uncomfortable truth is that “install security updates promptly” and “never let a bad patch take you down” are in tension, and the answer is not to stop patching — unpatched servers are how practices get breached. The answer is a little discipline around how you patch the one server you cannot live without:

Do not let the critical server auto-install on day one. Give cumulative updates a short soak — even a few days — so that widely-reported regressions like this one surface before they reach your production domain controller.
Keep a tested backup and know your DSRM password. A recent, verified backup of the domain controller, plus the Directory Services Restore Mode password, is your safety net if a rollback is not enough.
Avoid single points of failure where you can. A second domain controller — even a modest virtual one — means a bad patch on one does not take the whole practice offline.
Watch the patch-trouble pattern, not just one bulletin. This is the third September 2026 Windows Server update to cause real-world outages, after the one that broke Remote Desktop and locked staff out of the front desk and the one that broke Always On VPN for remote access. A rough patch month is itself a signal to slow down and verify before deploying.

None of this means fearing updates. It means treating the server that runs your practice with a bit more care than the laptop at the front desk — because when it falls over, everything does.

Staging updates and keeping a tested backup turn a bad patch from a disaster into a non-event.

How Compudent Systems can help

At Compudent Systems, we manage Windows Server environments for dental practices across the GTA and Ontario — which means we watch the patch-trouble reports so you do not have to. We stage and test updates before they reach your domain controller, keep verified backups and your DSRM recovery details on hand, and can add a second domain controller so a single bad patch never closes your office. And if your server is blue-screening right now, we can get you recovered. Contact Compudent Systems for proactive server patch management and a resilience review, and turn the next bad update from an emergency into a non-event.

Sources & further reading:

Compudent Systems

AI Just Helped Turn a Linux Bug Into a Root Exploit — and It Shrinks the Window Your Practice Has to Patch

The quiet metric: time from flaw to working exploit

Keep this in proportion — but take the trend seriously

Why “we’ll patch it next month” is now a risk, not a routine

The practical defence: shrink your own exposure faster than they shrink the window

Detection and segmentation: for the flaw you did not patch in time

What this means for your practice

How Compudent Systems can help

Related Reading

Ten Months Inside: The O2 Dental Breach and the Security Metric Your Practice Is Ignoring

The breach you see is the end of the story, not the start

Why dwell time is the metric that matters

Shrinking the gap: detection, not just defence

Limiting how far a quiet intruder can travel

What this means for your practice

How Compudent Systems can help

Related Reading

A Consumer Router Is Not a Firewall: Why Your Dental Practice Needs Business-Grade Network Security

A router forwards traffic. A firewall defends it.

What business-grade actually buys you

Segmentation: your X-ray sensor does not belong on the front-desk network

End-of-life is the silent killer

What this means for a dental practice

How Compudent Systems can help

Related Reading

Sending a 3D Scan for a Second Opinion: How to Share CBCT Data Without Putting a Patient’s Record at Risk

Why the easy methods are the risky ones

Export the right data: DICOM, not screenshots

Consent and the law: this is health information, wherever you practise

A five-step secure sharing workflow

Choose the channel deliberately

Build it once, use it every day

How Compudent helps

Related Reading

The Breach Almost Always Starts With a Click: How to Run Security-Awareness Training and Phishing Tests in a Dental Practice

The common thread in 2026’s dental breaches is a person

What security-awareness training actually is (and is not)

Phishing simulation: testing, not punishing

Building a program that fits a small practice

It is also a compliance and insurance requirement

A layer, not a replacement

How Compudent Systems can help

Related Reading

October 2026 Patch Tuesday: Microsoft Fixes a Record 1,400+ Flaws and an Exploited Windows Zero-Day — What Dental Practices Must Patch Now

A record month — but counts are not the story

The one that cannot wait: CVE-2026-96951

What “Mark of the Web” is, and why a dentist should care

The other two zero-days

Quietly important: some Windows versions just got their last update

What to do this week

The habit behind a calm Patch Tuesday

How Compudent Systems can help

Related Reading

Dental MRI Is Arriving in Practices — and It Is an IT Project Before It Is a Clinical One

What the new modality actually is

The clinical leap comes with a data leap

It has to move, land, and be found

Backup and retention are not optional extras

A scanner is also a networked computer

The questions to ask before the purchase order

The takeaway

How Compudent Systems can help

Related Reading

The ADA Now Says Scan Less — So Your Records Have to Say Why: What the 2026 Imaging Guidelines Mean for Your Practice Software

What actually changed in the 2026 guidance

Why this is a documentation problem, not just a clinical one

Build the justification into the software, not the memory

Retention and retrieval become clinical tools

A practical checklist for your practice

The takeaway

How Compudent Systems can help

Related Reading

One Logged-In Account Could Read the Whole Office’s Email: The Exchange Server Emergency Patch (CVE-2026-96940) Dental Practices Must Apply

What the flaw actually does

Why this is a dental-practice problem

On-premises servers only — and why that distinction matters

What to do this week

The habit that makes the next one easier

How Compudent Systems can help