Microsoft issued a fix for this vulnerability in its Configuration Manager product, better known as SCCM, back on July 14, 2026. For a month it stayed a theoretical concern. That changed this week: a security researcher published a working proof-of-concept exploit that demonstrates the full attack from start to finish. A patched, quietly-known flaw and a patched flaw with public exploit code circulating are two very different risk levels, and defenders are now on the clock.

First, does this even apply to your practice?

Let us be honest and specific, because vague alarm helps no one. SCCM, now formally Microsoft Configuration Manager, is enterprise fleet-management software. A single dentist running four computers and a server almost certainly does not have it. It is the kind of tool you find where dozens or hundreds of Windows machines need to be managed centrally: patched, imaged, inventoried, and issued software from one console.

In the dental world, that means this alert is aimed squarely at three groups. First, multi-location dental groups and DSOs with enough scale to justify centralized endpoint management. Second, the managed IT providers and MSPs that run fleets of practice computers on their clients’ behalf. Third, larger clinics and imaging centres whose IT was built out on a Microsoft-managed backbone. If none of that describes your setup, you can read this as background. If any of it does, or if you are not sure whether your IT provider uses SCCM, this is a question worth asking today.

What the flaw actually is, in plain terms

CVE-2026-47301 is not a single mistake but an exploit chain: several smaller weaknesses linked together so that each one hands off to the next. On its own, no single link is a catastrophe. Chained, they let an ordinary authenticated domain user, an account with no special privileges, climb all the way to SYSTEM-level code execution on the SCCM Primary Site Server. SYSTEM is the highest level of control a Windows machine has. On the server that manages your fleet, it is effectively the keys to everything.

The researcher’s chain strings together a broken-authorization flaw that lets a normal user reach an endpoint they should not, a file-upload path-traversal that writes a file where it does not belong, a certificate-verification bypass, and finally a DLL hijack that runs the attacker’s code. You do not need to follow the mechanics to grasp the shape of it: a low-privilege foothold becomes total control of the one server that talks to every managed computer.

This is the same pattern we have flagged before in a different Microsoft component, when an ordinary account could be leveraged into full takeover of a Windows domain through a certificate-services weakness. The lesson repeats: in a Windows environment, the distance between a modest user account and complete control is often shorter than it looks, and attackers are experts at closing it.

Why the management server is the worst place to be compromised

Here is what makes this class of flaw genuinely serious for a healthcare network. The entire purpose of a tool like SCCM is to push software and commands to every machine it manages. That is its job on a good day. An attacker who owns that server inherits that same capability. Instead of ransoming one computer, they can potentially distribute their payload to every endpoint in the fleet through the trusted management channel, the one your own systems are built to obey without question.

For a single practice that would be devastating. For a group or an MSP managing many practices from shared infrastructure, one compromised management server could reach across multiple clinics at once. The convenience of central management and the blast radius of a central compromise are, unavoidably, the same wire. That is not an argument against central management, which is genuinely good practice; it is an argument for defending the center of it as if everything depended on it, because it does.

It is the same reason a breach of a remote-management platform is so damaging. We saw exactly this dynamic when a widely used remote monitoring and management tool used by MSPs was breached: the tools that give IT its leverage give an intruder the same leverage if they are turned.

What to do about it, in order

1. Confirm whether SCCM is in your environment at all. If you run your own IT, check whether Microsoft Configuration Manager is deployed. If a provider manages your computers, send them one direct question: “Do we use SCCM or Microsoft Configuration Manager, and if so, are we patched against CVE-2026-47301?” A competent provider will answer quickly and specifically.

2. Apply the July fix immediately if you have not. Microsoft’s update from July 14, 2026 closes the initial authorization flaw that the whole chain depends on. If your Configuration Manager is current, you have already broken the chain at its root. If it is not, this is the priority patch, not a next-maintenance-window item, now that exploit code is public.

3. Restrict who can even reach the server. The exploit needs an authenticated user to start. Tightening which accounts can talk to the management server, enforcing least privilege, and putting it behind proper network segmentation all raise the bar even against future flaws. A management server should not be casually reachable from every workstation on the network.

4. Make sure you could recover. Any whole-fleet threat is ultimately a test of your backups. This is a good moment to confirm that your recovery plan is real and that your backups have been tested with an actual restore, not merely assumed to work. A management-server compromise is precisely the scenario where a proven backup is the difference between a bad week and a closed practice.

The compliance angle you cannot skip

Under both HIPAA and Ontario’s PHIPA, you are responsible for safeguarding patient information with reasonable, current measures, and that responsibility does not evaporate because your computers are managed by someone else. If a management server your practice relies on is compromised and patient data is exposed, “our IT provider handles that” is not a defence; due diligence over your vendors is part of the obligation. A public exploit for a known, patchable flaw is exactly the kind of thing a regulator would expect a diligent practice, and its IT partner, to have addressed promptly.

The bottom line for your practice

CVE-2026-47301 is a critical flaw in the software some dental groups and their IT providers use to manage entire fleets of Windows computers, and as of this week there is public exploit code that turns it from theory into a usable attack. Microsoft’s fix has been available since July. The action is simple to state: find out whether SCCM is anywhere in your environment, confirm it is patched, tighten access to the management server, and make sure your backups would actually bring you back. If your practice is part of a group, or your machines are managed by an outside provider, the single most useful thing you can do today is ask them, directly, whether you are covered.

If you would like an independent set of eyes on how your practice’s computers are managed and whether flaws like this one are being patched on your behalf, contact Compudent Systems. We help dental practices and groups across Ontario understand what is running their networks, confirm the important updates are actually applied, and reduce the blast radius before a known flaw becomes an incident.

Sources & further reading:

• Public Exploit Code Released for Microsoft SCCM Remote Code Execution Vulnerability (CVE-2026-47301)
• XM Cyber: Potential for Remote Code Execution in Microsoft SCCM via Newly-Discovered Exploit Chain

Related Reading

• When the Tool That Manages Your Network Gets Hacked: The N-able N-central Breach and What It Means for Dental Practices
• One Ordinary Login Can Now Own Your Whole Network: What the ‘Certighost’ Windows Domain Exploit Means for Dental Practices
• A Forged Login Walks Straight Into SharePoint: What the Actively Exploited CVE-2026-55040 Auth Bypass Means for Dental Practices

The post Public Exploit Code Is Now Out for a Critical SCCM Flaw: What CVE-2026-47301 Means If Anyone Manages Your Practice’s Windows Fleet appeared first on Compudent Systems.

There are now two deadlines stacked on top of each other, and both have already passed. Microsoft ended support for Windows 10 on October 14, 2025. And Henry Schein One, the company behind Dentrix, set June 30, 2026 as the date after which it will no longer support new Dentrix installations on Windows 10. If your practice is still running Dentrix on a Windows 10 machine today, you are no longer running a merely aging setup. You are running an unsupported, end-of-life configuration that neither the operating system vendor nor the software vendor stands behind.

What actually changed, in plain terms

The two deadlines are related but separate, and it helps to keep them straight.

The first is the operating system itself. When Microsoft ends support for a version of Windows, it stops shipping the monthly security updates that close newly discovered vulnerabilities. The machine keeps working, but every flaw found after that date stays open on it, permanently. We covered that shift and why an unsupported operating system is already a HIPAA and PHIPA problem in detail. That risk applies to any Windows 10 machine, in any industry.

The second deadline is new, and it is specific to your practice management software. Henry Schein One has now drawn its own line: Dentrix is no longer supported on Windows 10. In practice, that means if you call for help with a Dentrix problem on a Windows 10 workstation, or need to reinstall or set up a new machine, the supported answer is to be on Windows 11. A vendor that will not support your configuration is a vendor that cannot reliably help you when something breaks, and in a busy practice, something always eventually breaks.

Why a software vendor’s deadline matters as much as Microsoft’s

It would be easy to treat the Dentrix cutoff as a formality. It is not. Dentrix is not a peripheral app. It is the system of record for your schedule, your clinical notes, your billing, and, for many practices, the hub your imaging connects into. When the vendor of that system says it will not support a given operating system, three things follow.

First, troubleshooting gets harder and slower. Support teams are trained and resourced around supported configurations. On an unsupported one, you may be told the fix is simply to upgrade before they can proceed, which is the worst possible moment to discover you are behind.

Second, future updates and integrations are not guaranteed to work. As Dentrix ships new versions and as third-party tools that plug into it evolve, they are built and tested against supported platforms. An unsupported OS is where subtle, hard-to-diagnose failures accumulate.

Third, and most importantly for a healthcare practice, it compounds your compliance exposure. You now have patient health information flowing through software the vendor will not support, running on an operating system the vendor will not patch. Under both HIPAA and Ontario’s PHIPA, you are expected to protect that information with reasonable, current safeguards. Two overlapping end-of-life declarations on the same machine is a difficult thing to defend as reasonable.

The risk is invisible until the day it is not

The trap with all of this is that nothing looks wrong. The Windows 10 machine at the front desk boots up, Dentrix opens, the day runs. There is no lockout, no red screen, no alarm the morning support ended. Meanwhile, attackers actively scan for exactly this profile: a widely deployed, internet-connected, unpatched system holding valuable data.

And it is not just the one machine. In a typical practice network, that Windows 10 workstation shares a LAN with your server, your imaging sensors, and every other PC. Ransomware and intruders rarely need to land on the most important machine. They need to land on the weakest one, and then move.

Step one: find every machine still on Windows 10

You cannot fix what you have not counted. The first task is a complete inventory of every computer that touches the practice: reception, each operatory, the office manager’s PC, any laptop used for remote access, and the imaging capture stations. For each one, record the Windows version and, if it is on Windows 10, whether the hardware is eligible to upgrade to Windows 11 in place.

Windows 11 has real hardware requirements, notably a TPM 2.0 security chip and a supported processor. Some practice machines will upgrade cleanly. Others, especially older imaging-capture PCs chosen years ago for compatibility with a specific sensor, will not, and will need to be replaced. Knowing which is which turns a vague worry into a concrete, budgetable plan.

Step two: protect the data before you touch anything

Migrations are exactly when data gets lost, and a practice’s Dentrix database is not something you want to gamble with. Before any machine is upgraded or replaced, confirm you have a current, verified backup that you have actually test-restored. A backup you have never restored is a hope, not a safeguard. Confirm the backup includes the Dentrix database and any imaging data, and that you know how to bring it back if a migration goes sideways.

This is also the moment to check your Dentrix version itself. Windows 11 support and current Dentrix releases go together; an ancient Dentrix build on a shiny new operating system can create its own compatibility surprises. Plan the OS move and the software version together, not separately.

Step three: migrate in a controlled, phased way

You do not have to do everything in one weekend, and you should not. A sensible sequence is to move the lowest-risk machines first, such as an administrative PC that does not capture images, confirm Dentrix and any peripherals behave, and then work toward the imaging and operatory stations where sensor drivers and integrations need careful testing. Schedule the disruptive steps for evenings or a closed day, and keep the tested backup within reach at every stage.

Throughout, treat this as a security project as much as an IT one. A migration is a natural time to also confirm the basics that protect patient information more broadly, from how staff handle records to how the practice communicates with patients under PHIPA and HIPAA. Doing the OS move without revisiting those habits leaves value on the table.

The bottom line for your practice

Two deadlines have quietly converged. Microsoft has stopped patching Windows 10, and Henry Schein One has stopped supporting Dentrix on it. A practice still running that combination is operating the core of its clinical and administrative work on a configuration that is unsupported on both sides, and that is a cybersecurity and compliance gap that will not announce itself before it is exploited. The fix is well understood: inventory, back up and verify, then migrate to Windows 11 in a phased, tested way.

If you are not certain which of your machines are still on Windows 10, whether they can move to Windows 11, or how to migrate your Dentrix environment without downtime or data loss, that is precisely the kind of assessment Compudent Systems handles for dental practices every day. Contact Compudent Systems for a straightforward review of your workstations and a clear, budgeted plan to get your practice back onto a fully supported footing before the gap costs you.

Sources & further reading:

• Microsoft: Windows 10 end of support
• Dentrix System Requirements: What Changed in 2026 (Henry Schein One June 30, 2026 deadline)

Related Reading

• Still Running Windows 10 at the Front Desk? Why an Unsupported OS Is Now a HIPAA Problem
• February 2026 Patch Tuesday: Six Zero-Day Vulnerabilities Mean Your Dental Office Needs to Update Windows Now
• February 2026 Patch Tuesday: Microsoft Fixes 6 Actively Exploited Zero-Day Vulnerabilities — What Dental Practices Need to Do Now

The post Dentrix Just Stopped Supporting Windows 10: What Every Practice Still Running It Needs to Do Now appeared first on Compudent Systems.

On August 16, 2026, researchers detailed a new macOS information-stealer called AmnesiaStealer. What makes it notable is not that it grabs saved passwords and crypto wallets, plenty of malware does that. It is that AmnesiaStealer copies the victim’s browser profile, including its live authentication state, into a hidden browser the attacker controls, and then lets that attacker drive the already-logged-in session in real time, watching a low-frame-rate screencast and typing and clicking as if they were sitting at the victim’s desk. Because they are riding the victim’s authenticated session, there is no password to guess and no MFA prompt to satisfy. The login already happened.

Why MFA does not stop this

To see why, it helps to understand what MFA actually protects. Multi-factor authentication is a control on the authentication event, the single moment when a user proves who they are with a password plus a code, an app approval, or a fingerprint. Once that check succeeds, the service issues a session token, a small credential (usually stored as a browser cookie) that says “this browser is already logged in, do not ask again.” That token is what lets you move between your email, your calendar, and your files without re-entering a code every few minutes.

The problem is simple and unforgiving: whoever holds that token is the logged-in user, as far as the service is concerned. If an attacker copies the token and loads it into their own browser, they inherit the authenticated state completely. No password. No new MFA challenge, because the authentication event they would need to trigger already came and went. This is session hijacking, and infostealer malware is the engine driving it. In 2025, infostealers are estimated to have harvested more than 94 billion browser cookies, and research found that a majority of ransomware victims had their credentials or session tokens circulating on criminal markets before the attack landed. As one security firm put it, hackers increasingly do not need your password anymore, a lesson we also drew out when we covered the Kratos kit that industrialized Microsoft 365 session theft.

Why a dental practice is squarely in scope

It is tempting to file “macOS malware” under someone else’s problem, since most practice front desks run Windows. That would be a mistake. AmnesiaStealer happens to target Macs, but the technique is not Mac-specific, and Windows infostealers have been stealing session cookies the same way for years. The valuable thing, the authenticated browser session, exists on every platform.

Think about what your front-desk and operatory computers are logged into on any given day: Microsoft 365 email and files, your practice-management portal, insurance and electronic-claims sites, imaging or backup dashboards in the cloud. Every one of those is a browser session an attacker would love to inherit, and several of them touch protected health information directly. A single compromised workstation with a stealer on it can hand over all of those sessions at once, quietly, without ever tripping a failed-login alert.

How the malware gets in

The delivery method matters, because it is where the practice has the most leverage to stop the whole chain. AmnesiaStealer spreads through ClickFix-style campaigns: a fake download or a bogus “verify you are human” or “fix this error” page instructs the user to copy and paste a command, or to download and open a password-protected archive. The victim, trying to be helpful or to get software they wanted, runs the attacker’s code themselves, neatly sidestepping many automated defences.

We have seen this pattern before and flagged it for practices when we wrote about ClickFix and browser-built malware slipping past antivirus. The through-line is that modern attacks increasingly recruit the user as the delivery mechanism, whether that is a paste-this-command trick or a convincing phone call to your front desk. Staff awareness is not a soft add-on here; it is a frontline control.

What actually defends against session theft

Because no single setting closes this gap, the defence is layered, and the good news is that most of these layers are practical and within reach of a well-supported practice.

Stop the delivery. The cheapest win is preventing the stealer from ever running. Train staff never to paste commands they were told to copy from a website, and to be suspicious of any “download to fix this” prompt. Pair that with modern endpoint protection (EDR) and, where possible, application allowlisting so unapproved programs cannot execute on clinical machines.

Move to phishing-resistant sign-in. Passkeys and hardware-backed authentication are far harder to relay or replay than a code sent to a phone, and they pair naturally with device-bound sessions. We covered the shift in our piece on passkeys becoming the default; this attack is a strong reason to accelerate it.

Bind sessions to trusted devices and shorten their life. Conditional-access and device-compliance policies can require that a session only work from a managed, healthy practice computer, so a cookie lifted onto an attacker’s unknown machine is dead on arrival. Shorter session lifetimes and periodic re-authentication shrink the window in which a stolen token is useful.

Be ready to revoke, not just reset. This is the one most people get wrong. If you suspect a session was stolen, resetting the password is not enough, an active session can survive it. You must explicitly revoke the sessions (“sign out everywhere” / revoke refresh tokens) to kill the attacker’s copy along with the legitimate one.

Watch for the tell-tales. A session suddenly active from an implausible location, at an odd hour, or from an unrecognized device is exactly the signal that a token has been lifted. Make sure someone, your IT provider, is positioned to see and act on those alerts.

The compliance angle

Under PHIPA and HIPAA, an account that can reach patient information is part of your risk surface, and a credible session-theft incident affecting such an account is a security event you must be able to assess, contain, and, where warranted, report. “We had MFA on” is not, by itself, a defence if a session was hijacked around it. Your risk assessment and incident-response plan should name session theft explicitly, and your revocation procedure should be written down before you need it, not improvised at 4 p.m. on a Friday.

The takeaway

MFA is still essential, keep it on, and keep improving it. But it is a lock on the front door, and infostealers have learned to copy the key after you have already turned it. The practices that stay safe are the ones that add the next layers: stopping the malware from running, binding sessions to trusted devices, shortening how long a stolen token lasts, and knowing how to revoke every session the moment something looks wrong.

Compudent Systems helps dental practices across the GTA and Ontario build exactly that defence in depth: hardening endpoints against ClickFix-style delivery, deploying phishing-resistant passkeys and conditional-access policies that tie sessions to trusted practice devices, tuning session lifetimes, and putting a tested session-revocation and incident-response procedure in place so a stolen cookie does not become a breach. If you are relying on multi-factor authentication alone to protect the accounts that touch patient data, that is the gap to close, contact Compudent Systems for a session-security and endpoint review.

Sources & further reading:

• New AmnesiaStealer macOS malware hijacks browser sessions via remote control – BleepingComputer
• From Cookies to Keys: The Threat of Session Hijacking – Huntress
• Session Hijacking in 2026: How Stolen Cookies Bypass MFA – Whiteintel

Related Reading

• A Forged Login Walks Straight Into SharePoint: What the Actively Exploited CVE-2026-55040 Auth Bypass Means for Dental Practices
• A Fake Job Offer, a Windows Kernel Rootkit: The Lazarus Zero-Day (CVE-2026-68820) and What It Means for Your Dental Practice
• Security Alert: ‘ClickFix’ and Browser-Built Malware Are Slipping Past Antivirus – What Dental Offices Need to Know

The post Your Staff Passed MFA, and the Attacker Was Already In: Infostealers, Stolen Session Cookies, and Your Dental Practice appeared first on Compudent Systems.

In early 2025, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the Food and Drug Administration warned that a widely used patient monitor, the Contec CMS8000, contained a hidden backdoor in its firmware. According to CISA’s analysis, affected versions would silently transmit patient data in plaintext to a hard-coded external IP address and could allow remote control of the device – tracked as CVE-2025-0626, CVE-2025-0683, and CVE-2025-1204. This was not a stolen password or a misconfiguration. It was behavior baked into the device before it ever reached a clinic.

The response has been spreading ever since. By March 2026, the state of Texas had directed its agencies and state-owned medical facilities to inventory and review the cybersecurity risk of Chinese-manufactured networked medical devices, reporting their findings to a central cyber command. Whatever you make of the geopolitics, the underlying question it forces is a good one for every healthcare organization – dental practices included: do you actually know what your connected devices are, and what they are talking to?

Your practice is full of connected devices too

It is easy to read “medical device backdoor” and assume it is a hospital problem. It is not. A modern dental practice is quietly full of networked hardware running embedded firmware from a global supply chain: intraoral sensors and their interface bridges, panoramic and CBCT imaging units, intraoral scanners, sometimes networked sterilizers, monitoring gear, and the little boxes that connect them all to your practice-management software.

Each of those is a small computer. Each has firmware written by someone, assembled from components sourced from somewhere, and each – once you plug it into your network – is trusted. That trust is the whole point of the Contec story. A firewall is very good at stopping threats coming in; it is far less suspicious of a device already inside the practice quietly sending data out to an address it was programmed to reach.

This is the same lesson, from a different angle, as the imaging-file and software risks we have covered before. When we looked at a booby-trapped X-ray file exploiting a flaw in DICOM viewing software, the danger was trusted imaging software. When we looked at malicious code slipped into a software supply chain, the danger was trusted software components. Device provenance is the hardware version of the same problem: the thing you trusted was compromised before you ever received it.

Provenance is a real question, not paranoia

To be clear, the point here is not to panic about any single country of origin, or to rip trusted equipment out of your operatories. Plenty of excellent imaging hardware is manufactured overseas, and country of manufacture alone does not make a device dangerous. The point is narrower and more useful: provenance and behavior are now legitimate things to know and monitor. Who made this device? What firmware is it running? What does it connect to, and does it reach anything outside your practice? Has the manufacturer committed to patching it?

Those were once questions nobody asked when buying a sensor. After a hard-coded backdoor in a mainstream patient monitor and a state-level order to catalog networked medical devices, they are exactly the questions a diligent practice – and its regulators – will increasingly expect answered.

What to actually do about it

The reassuring part is that the defenses are practical, and most of them are good hygiene regardless of any single advisory.

Build a device inventory. You cannot secure what you have not listed. Create a living register of every networked device in the practice: make, model, firmware version, what it connects to, and whether it needs internet access at all. This single unglamorous document is the foundation for everything else, and it is exactly what the Texas directive asked its agencies to produce.

Segment your imaging and connected devices. Put imaging units and other connected medical devices on their own isolated network segment (a VLAN), separated from front-desk computers and your practice-management server, with tightly controlled rules about what they may talk to. If a device only needs to reach your imaging server, it should not be able to reach the open internet at all. Segmentation is what turns “a compromised sensor” into a contained event rather than a practice-wide one.

Watch what your devices send outward. Egress monitoring – keeping an eye on outbound connections from your network – is how a device “phoning home” to an address it has no business contacting gets noticed. Your IT support can flag and block unexpected outbound traffic from devices that should be silent.

Keep firmware patched, through the vendor. Backdoors and bugs get fixed in firmware updates. Establish who is responsible for checking for and applying firmware updates on each device, and confirm the manufacturer still supports the model. A device the vendor has abandoned is a device that will never be fixed.

Make provenance a purchasing criterion. Before buying connected equipment, ask the vendor the awkward questions: where does this device send data, can you provide a software bill of materials (a list of the components inside it), and how long do you commit to security updates? Vendors who answer clearly are the ones you want. This is the same third-party diligence we laid out in our IoMT and vendor-breach checklist – applied at the moment of purchase, when you have the most leverage.

Fold devices into your risk assessment. Under PHIPA and HIPAA, connected devices that touch patient data belong in your written risk assessment and incident-response plan – not as an afterthought, but as the small computers holding and moving PHI that they actually are.

The takeaway

A patient monitor that quietly mailed patient data overseas, and a state government ordering a full inventory of its networked medical devices, are two halves of the same wake-up call. The devices we plug in and forget about are computers, made by people, somewhere, running code we usually never see. That does not mean fear every sensor – it means know your equipment, contain it, and watch it.

Compudent Systems helps dental practices across the GTA and Ontario answer these questions in practice: building a complete inventory of connected and imaging devices, segmenting them onto isolated networks with controlled egress, monitoring for the outbound traffic a compromised device would generate, and folding all of it into a defensible PHIPA and HIPAA risk assessment. If you could not, right now, list every networked device in your practice and say what each one connects to, that is the place to start – contact Compudent Systems for a connected-device and network review.

Sources & further reading:

• Contec CMS8000 Contains a Backdoor – CISA fact sheet
• Contec Health CMS8000 Patient Monitor (Update A) – CISA ICS Medical Advisory ICSMA-25-030-01
• Governor Abbott Directs State Health Agencies to Address Potential CCP-Connected Cybersecurity Risks – Office of the Texas Governor

Related Reading

• When Your Device Vendor Gets Breached: An IoMT and Third-Party Security Checklist for Dental Practices
• The Other Computers in Your Operatory: Why Connected Dental Devices Are the Attack Surface Nobody Audits
• A Booby-Trapped X-ray File: What the RadiAnt DICOM Advisory (CVE-2026-17264) Means for Dental Practices

The post Where Was Your Imaging Sensor Made, and What Is It Talking To? Device Provenance Is Now a Dental Practice Security Question appeared first on Compudent Systems.

What the flaw actually does

SharePoint services trust each other using signed identity tokens – the digital equivalent of a sealed, stamped credential that says “this request really is from an authorized user.” CVE-2026-55040 is a chain of four separate weaknesses in the way older on-premises SharePoint validates those tokens. Stitched together, they let an unauthenticated, remote attacker hand the server a forged token that it accepts as genuine, then act as whatever user – or administrator – they claimed to be.

The uncomfortable part is how ordinary the request looks. There is no brute-force, no malware dropped at the door, no locked-out account to tip you off. The server simply believes the forged credential. Microsoft’s own advisory summarized the impact plainly: an attacker could “disclose files and modify data,” though the flaw does not let them knock the system offline. In a practice context, “disclose files and modify data” is not a minor caveat – that is exactly the patient records, imaging, and internal documents you are obligated to protect.

This kind of silent identity forgery is the same category of threat we covered when a single forged certificate could quietly take over an entire Windows domain: when the mechanism that proves who you are breaks, every permission built on top of it is suddenly worthless.

Why it is dangerous right now

Vulnerabilities become urgent not when they are discovered, but when they are easy. CVE-2026-55040 was patched quietly in July. What changed this week is that Rapid7 released a detailed analysis and working proof-of-concept, and threat actors immediately picked it up. Exploitation tracking services logged attempts within days of the code going public.

That pattern is the whole story of modern patching: the gap between a public exploit and mass scanning is now measured in days, sometimes hours. It is why an internet-facing server that is even a few weeks behind on updates is a genuine liability – the same lesson behind the SonicWall VPN appliances that ransomware crews walked straight through. CVE-2026-55040 is now the fifth SharePoint vulnerability to be actively exploited this year, so this is a product firmly in attackers’ sights.

Does this affect your dental practice?

Here is the reassuring distinction. If your practice uses SharePoint Online – the version bundled with Microsoft 365 in the cloud – Microsoft manages and patches those servers for you, and this specific exposure is not yours to fix. Most smaller practices are in exactly that position.

The real risk sits with on-premises SharePoint Server: a SharePoint installation running on a server in your own office or data centre, typically used as an internal document library, intranet, or records hub. Some practices run one directly; others inherit one through a managed IT provider or a larger group’s shared infrastructure. If any server you control – or that your IT vendor controls on your behalf – runs on-premises SharePoint, you are in scope, and it needs attention today. If you genuinely do not know which you have, that uncertainty is itself the first thing to resolve.

What to do now

1. Confirm what you are running. Ask your IT provider a direct question: do we operate any on-premises SharePoint Server, and has it received the July 2026 cumulative update? Cloud-only SharePoint Online tenants can breathe easier; on-prem installs cannot.

2. Apply the July update immediately. The fix already exists – the danger is purely in unpatched servers. If yours has lagged, patching is the single highest-value action, and it should not wait for the next maintenance window.

3. Get it off the open internet. An internal document server has no business being directly reachable from the public internet. Place it behind a VPN or reverse proxy, require multi-factor authentication to reach it, and restrict access to the addresses that actually need it. That containment blunts this flaw and the next one.

4. Assume nothing and check the logs. Because a forged-token attack looks like a normal, successful login, you cannot rely on failed-login alarms. Have your provider review SharePoint and server logs for unexpected administrative activity, unfamiliar access to document libraries, and any newly planted files or web shells that would let an attacker return later.

5. Rotate secrets if you were exposed. If the server was internet-facing and unpatched for any length of time, treat associated credentials and service secrets as potentially compromised and rotate them.

6. Confirm your recovery path. An attacker who can modify data is a reminder that clean, tested backups are your safety net. As we have said before, a backup you have never test-restored is only a hope – verify yours actually restores.

The bigger pattern

CVE-2026-55040 is not an exotic, once-in-a-decade event. It is the routine rhythm of enterprise software: a serious flaw is found, quietly patched, then rapidly weaponized the moment exploit code goes public. The practices that stay safe are not the ones with the fanciest tools – they are the ones that know exactly what they run, patch it promptly, keep internal servers off the open internet, and can prove their backups work. The same discipline that closes this SharePoint hole closes the next one, whatever product it lands in.

Compudent Systems helps dental practices across the GTA and Ontario answer these questions before an attacker does – inventorying what you actually run, applying critical patches on a reliable cadence, moving exposed servers behind VPN and multi-factor authentication, reviewing logs for signs of compromise, and confirming that backups genuinely restore. If you are not certain whether your practice runs on-premises SharePoint, or whether it is patched against CVE-2026-55040, contact Compudent Systems for a rapid exposure check. Finding out you were fine is a good afternoon; finding out too late is not.

Sources & further reading:

• Attackers Exploit SharePoint Authentication Bypass After Public PoC Release – The Hacker News
• CVE-2026-55040: Microsoft SharePoint JWT Token Authentication Bypass (FIXED) – Rapid7
• Microsoft SharePoint JWT Token Authentication Bypass Technical Analysis (CVE-2026-55040) – Rapid7

Related Reading

• When the Tool That Manages Your Network Gets Hacked: The N-able N-central Breach and What It Means for Dental Practices
• One Ordinary Login Can Now Own Your Whole Network: What the ‘Certighost’ Windows Domain Exploit Means for Dental Practices
• Ransomware Gangs Are Now Through the Front Door: What the SonicWall SMA1000 VPN Attacks Mean for Dental Practices

The post A Forged Login Walks Straight Into SharePoint: What the Actively Exploited CVE-2026-55040 Auth Bypass Means for Dental Practices appeared first on Compudent Systems.

So is texting or emailing your patients actually against the rules? The short answer is reassuring: no law bans it. The longer answer is where practices get into trouble – because “allowed” is not the same as “done safely.”

What the rules actually say

Neither PHIPA nor HIPAA prohibits electronic communication with patients. Both are technology-neutral: they require a custodian of health information to protect it with reasonable safeguards and to respect the patient’s wishes. Ontario’s Information and Privacy Commissioner has been explicit that email is permitted, provided you assess the risk and put appropriate protections in place. HIPAA takes the same posture – email and texting are allowed, but the practice remains responsible for the confidentiality, integrity, and availability of any protected health information (PHI) it transmits.

In practice, that responsibility comes down to three questions for every channel you use: is the message protected in transit, does it reach only the intended person, and did the patient agree to be contacted this way? Ordinary SMS and standard consumer email struggle with all three.

Why plain texts and ordinary email are the weak link

A text message or a normal email does not travel in a straight, private line from your front desk to your patient. It hops through carrier and provider servers, gets stored along the way, and lands on a personal phone or inbox that may be shared, unlocked, or backed up to someone else’s cloud. Standard SMS is not encrypted end to end. Consumer email is frequently unencrypted in transit and sits on servers outside your control.

Then there is the most common breach of all: misdirection. A wrong digit in a phone number, an autocomplete that fills in the wrong “John,” a reply-all that copies the whole family – these are how most everyday privacy incidents happen, and they have nothing to do with hackers. The convenience that makes texting fast is exactly what makes a slip irreversible.

The appointment-reminder rule: minimum necessary

The good news is that the most common message a practice sends – the appointment reminder – is also the easiest to do safely. Both frameworks lean on a minimum-necessary principle: share only what the purpose requires. A reminder can safely contain the date, the time, and the practice name. It should not contain the procedure, a diagnosis, a treatment detail, or anything that reveals why the patient is coming in.

“Reminder: your appointment with our office is Tuesday at 2:00 PM” is fine. “Reminder: your root canal and crown prep is Tuesday” is a disclosure of clinical information to whoever happens to see that screen. Keep reminders bland on purpose.

The patient-requested exception – and its limits

HIPAA includes a sensible provision that trips practices up when they over-read it. If a patient specifically asks to be communicated with by ordinary email or text, and you have made them reasonably aware of the risks, you may honor that request. The key is to document it – note that the patient requested unencrypted communication and was informed of the risk.

But that permission is narrow. It covers communicating with that patient, at their request. It does not license routine, practice-initiated disclosures by insecure channels, and it does not cover sending PHI to other providers, insurers, or labs over plain email. Do not stretch a single patient’s convenience preference into a general practice policy.

Sending records and X-rays: use a real channel

Emailing a patient their X-rays or a treatment plan as an attachment on a free consumer mail account is where practices take on the most risk for the least reason. Imaging and records are exactly the high-value, high-sensitivity data an attacker or a nosy recipient wants.

The right tools already exist: a secure patient portal where the patient signs in to retrieve documents, encrypted email, or a secure file-transfer link that expires. Each keeps the data inside an authenticated, protected channel instead of scattering copies across inboxes. If you are weighing which new tools are safe to bring into the practice at all, the same compliance logic we walked through for whether a dental practice can use ChatGPT without breaking HIPAA and PHIPA applies here: assess where the data goes before you send it.

Your texting and email vendors are part of your compliance

Here is the piece practices most often miss. The moment a third-party service – an appointment-reminder platform, a texting service, a hosted email provider – handles PHI on your behalf, it becomes a business associate under HIPAA and an agent under PHIPA. That relationship must be governed by a Business Associate Agreement (or an equivalent written contract in Canada) that binds the vendor to protect the data.

Free consumer Gmail and consumer messaging apps like WhatsApp, iMessage, or Facebook Messenger generally will not sign such an agreement for a standard account, and they route data through their own systems for their own purposes. That does not make Google or Apple insecure companies – it makes their free consumer products the wrong tool for transmitting patient health information. Use a business-tier service that will contractually stand behind PHI, and get the paperwork signed before you send the first message.

A practical checklist for the front desk

Pick approved channels and stick to them. Decide, as a practice, which tools are allowed for patient communication – a secure portal, an encrypted email service, a compliant reminder platform – and train staff to use nothing else for anything involving a patient.

Keep reminders content-light. Date, time, practice name. No clinical detail. Ever.

Capture consent and preferences. Record how each patient has agreed to be contacted, honor opt-outs, and note any patient-requested use of unencrypted channels.

Double-check the recipient. Most breaches are fat-finger misdirection. Confirm the number or address before sending anything with PHI, and disable reply-all by default for patient mail.

Lock down the mail system itself. Multi-factor authentication and encryption on your email accounts, and current, supported software on every machine that touches patient data – the same front-desk hygiene that makes running an unsupported operating system a HIPAA problem applies to the inbox those messages come from.

Sign the vendor contracts. Every service that handles PHI needs a business associate agreement or equivalent on file. If a vendor will not sign one, it is not the right vendor.

These habits also keep you aligned with the direction regulators are already moving, from the tightened expectations in the recent HIPAA Privacy Rule updates to Ontario’s steady guidance on electronic PHI.

The takeaway

Texting and emailing patients is not forbidden – it is expected. What PHIPA and HIPAA ask is that you do it deliberately: protect the message in transit, make sure it reaches only the right person, keep reminders free of clinical detail, and put the paperwork in place with any vendor that touches patient data. Get those right and modern, convenient communication becomes a strength rather than a liability.

Compudent Systems helps dental practices across the GTA and Ontario set up communication the compliant way – deploying secure patient portals and encrypted email, hardening mail systems with MFA, reviewing reminder and texting platforms and their business associate agreements, and training front-desk staff to avoid the misdirection mistakes behind most privacy breaches. If you are not sure whether the way your practice texts and emails patients would survive a privacy audit, contact Compudent Systems for a patient-communication and compliance review. The safest message is the one that only your patient ever sees.

Sources & further reading:

• Is Texting in Violation of HIPAA? 2026 Update – The HIPAA Journal
• Is Gmail HIPAA Compliant? Updated for 2026 – The HIPAA Journal
• Communicating Personal Health Information by Email – Information and Privacy Commissioner of Ontario (IPC)

Related Reading

• Can Your Dental Practice Use ChatGPT Without Breaking HIPAA and PHIPA? A 2026 Compliance Guide
• The First Hours After a Data Breach: What an Ontario Dental Practice Must Do Under PHIPA
• When Your Device Vendor Gets Breached: An IoMT and Third-Party Security Checklist for Dental Practices

The post Is Texting or Emailing Your Patients a PHIPA and HIPAA Violation? Secure Patient Communication for Dental Practices appeared first on Compudent Systems.

Security researchers Alejandro Hernando and Borja Martinez presented “Plug and Pwn” at DEF CON 34, and it was detailed by BleepingComputer on August 12, 2026. The technique abuses Windows Plug and Play – the feature that makes hardware “just work” – to make Windows install a vulnerable driver and hand an attacker SYSTEM privileges, the highest level of control a Windows computer has. The most unsettling part: some versions of the attack need no clicks, no logged-in user, and work on a fully patched Windows 11 machine in about five minutes.

How a plug becomes total control

When you connect a new device, Windows identifies it by a hardware ID, finds a matching driver package, and installs it. For a lot of hardware, that package is a signed vendor bundle – and Windows runs its installer, services, and helper programs as NT AUTHORITY\SYSTEM, with no User Account Control prompt. The operating system trusts the package because it is signed; it does not scrutinize whether that trusted package contains an exploitable weakness.

The researchers used USB-emulation hardware to make a computer believe a specific device had been plugged in. Windows dutifully fetched and installed that device’s vendor driver package – and then they abused a vulnerable component inside it to climb to SYSTEM. In one demonstration they impersonated one manufacturer’s hardware to quietly change the machine’s DNS settings, then a second manufacturer’s to pull down files over an unencrypted connection. The point is not any single vendor’s bug; it is that the automatic install path itself hands trusted, SYSTEM-level execution to whatever device shows up.

This is not entirely new territory. Back in 2021, plugging in a Razer mouse could make a standard user an administrator, because Windows auto-launched the mouse’s installer as SYSTEM. Plug and Pwn generalizes that idea from one vendor’s installer to the device-installation machinery every Windows PC uses.

You do not even need to touch the computer

Here is the detail that should make any practice using remote desktop sit up. One of the demonstrated chains runs entirely over RDP, with no physical hardware at all. If a remote-desktop session has USB device redirection enabled, an attacker can make a phantom device appear to the server, triggering the same automatic driver install – and the same escalation to SYSTEM – from across a network.

In other words, this is both a physical-access attack and, in the right conditions, a remote one. That combination is what makes it a class of problem rather than a one-off bug.

Why patching and standard user accounts are not enough here

Two of our usual, reliable defenses do not fully close this door, and it is important to understand why.

Patching Windows does not remove it. The researchers ran their attack against a fully updated Windows 11 machine. The behavior being abused – Windows automatically installing signed vendor drivers as SYSTEM – is a feature, not a single flaw to be patched. Individual vulnerable vendor packages get fixed over time, but the install path remains.

Running staff as standard users does not stop it either. Normally, denying local-administrator rights is one of the best moves a practice can make – it is a core defense we recommend against nearly every kind of malware, and it was central to why a job-offer lure needed a separate zero-day to escalate from an ordinary user to SYSTEM. But Plug and Pwn does its escalation through the driver installer, which Windows runs as SYSTEM no matter who is logged in – or whether anyone is logged in at all. Least privilege still matters enormously for everything else; it just is not the whole answer to this particular trick.

Why a dental practice is a realistic target

Lazarus-grade nation-state tools are not what a small practice needs to fear. The realistic threat is far more mundane: physical exposure. Think about where your computers actually live. A front-desk PC faces the waiting room. Operatory workstations sit in rooms where patients are, at times, briefly alone. USB ports are open and inviting. Staff plug in phones, cameras, and patients’ own USB sticks full of outside imaging.

A booby-trapped “charging cable,” a rigged USB stick left behind, or a malicious device slipped into a port during a thirty-second gap is all this attack needs. And once a machine is at SYSTEM, the attacker effectively owns it – which on a practice computer means the practice-management database, imaging files, saved passwords, patient records, and possibly the route to your backups. It is the same escalation logic we walked through when a single ordinary login proved enough to take over an entire Windows network: get control of one machine at a deep enough level, and the rest can follow.

What to do now

The good news is that the countermeasures are concrete, and most are things a practice’s IT support can configure once.

Control physical access to USB ports. This is the front line. Position front-desk and operatory computers so ports are not reachable by patients, use port blockers or lockable cases where practical, and set a firm policy that unknown USB devices and cables never go into a practice machine. Patient media with outside X-rays should be handled on a designated, isolated computer.

Disable driver co-installers. Setting the DisableCoInstallers value in the Windows registry (under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Installer) prevents driver packages from running co-installer components during device setup. It disrupts several of the demonstrated chains – though the researchers are clear it does not eliminate the entire attack surface, so treat it as one layer, not a cure.

Restrict which devices can install at all. Windows Group Policy can limit device installation to an approved list of hardware IDs and block everything else. For practice computers that only ever need a known set of peripherals, an allow-list is a powerful, appropriate control.

Turn off USB redirection on remote sessions that do not need it. If you use RDP to reach a practice-management server, disable Plug and Play device redirection (the fDisablePNPRedir setting) on hosts that have no reason to accept redirected devices. This closes the no-hardware-needed remote variant.

Deploy and monitor endpoint protection. Modern endpoint detection and response can flag the unusual driver installs and behavior an attack like this produces – but only if it is current and someone actually watches the alerts.

Keep machines updated and segmented anyway. Prompt patching still retires the specific vulnerable vendor packages, and network segmentation with tested, offline backups is what decides whether a single compromised operatory PC stays contained or becomes a practice-wide incident – the same containment logic behind keeping every front-desk machine on a supported, patchable operating system.

The takeaway

Plug and Pwn is a reminder that not every threat arrives by email. Sometimes it is a device slipped into an open port, exploiting the very convenience that makes Windows pleasant to use. The defenses are unglamorous but effective: guard your ports, tell Windows to be pickier about what it installs, lock down remote redirection, and watch your endpoints.

Compudent Systems helps dental practices across the GTA and Ontario put these controls in place – configuring device installation restrictions and USB policy, hardening remote-desktop access to practice-management servers, deploying and monitoring endpoint protection, and segmenting networks so one compromised workstation cannot reach your patient records. If you are not certain what would happen if an unknown USB device were plugged into your front-desk PC, contact Compudent Systems for a device-control and endpoint review. The easiest attacks are often the ones that just walk in the door and plug in.

Sources & further reading:

• Plug and Pwn attack uses fake USB devices for Windows SYSTEM access – BleepingComputer
• Researchers Turn USB Auto-Install Into a Full SYSTEM Takeover on Windows 11 – The Hacker News
• Plug and Pwn – research site

Related Reading

• A Fake Job Offer, a Windows Kernel Rootkit: The Lazarus Zero-Day (CVE-2026-68820) and What It Means for Your Dental Practice
• The Other Computers in Your Operatory: Why Connected Dental Devices Are the Attack Surface Nobody Audits
• Ransomware Gangs Are Now Through the Front Door: What the SonicWall SMA1000 VPN Attacks Mean for Dental Practices

The post Plug and Pwn: How a Fake USB Device Can Seize a Dental Practice Computer in Minutes appeared first on Compudent Systems.

On August 11, 2026, Microsoft’s monthly Patch Tuesday fixed roughly 400 security flaws, and among them was one being actively exploited in the wild: CVE-2026-68820, a zero-day in Windows itself. Researchers at Check Point traced its real-world use to the North Korean state-linked Lazarus group, which chained it to a fake job offer to plant a stealthy kernel rootkit on a target’s machine. The specific victim was not a dental office – but the pattern is one every practice should understand, because it is built from ingredients any small business is exposed to.

What the flaw actually is

CVE-2026-68820 is a use-after-free vulnerability in the Windows Ancillary Function Driver for WinSock – AFD.sys – a low-level networking component that ships with every copy of Windows. In plain terms: by triggering a precise timing bug (a “race condition”), a program already running on the machine can escalate its own privileges all the way up to SYSTEM, the highest level of access on a Windows computer. Microsoft notes that no user interaction is required for this step, and the elevation happens locally, on the machine the attacker already has a foothold on.

That word “already” is the important one, and it is where a lot of people underestimate a flaw like this.

Why “it needs local access first” is not reassuring

A privilege-escalation bug is sometimes waved away because, on paper, the attacker has to be running code on the machine before they can use it. But getting that initial foothold is the cheap part of a modern attack – it is what social engineering is for. In the Lazarus campaign, Check Point’s researchers describe an intrusion that began with a job-offer lure: the target was courted with a fake opportunity and persuaded to run a file. That file ran with ordinary user permissions – limited, sandboxed, not yet dangerous.

Then the zero-day did its job. CVE-2026-68820 vaulted that limited, ordinary-user foothold straight up to SYSTEM. This is the same two-stage logic behind so many serious breaches: a human is tricked into opening the door a crack, and a technical flaw kicks it the rest of the way open. We have seen the human half of this play out against healthcare directly, when a convincing phone call talked its way past a healthcare organization’s Microsoft login – no exotic exploit required, just a persuasive story. Pair a persuasive story with a zero-day and you get exactly this attack.

The part that should worry you most: the rootkit

Once Lazarus reached SYSTEM, they used it to deploy a new version of FudModule, their kernel-mode rootkit. A rootkit that runs in the kernel operates beneath the applications, beneath the operating system’s own protections, and beneath your antivirus. From there it can switch off or blind the very security tools meant to detect it, hide the attacker’s activity, and make the compromise extraordinarily hard to see or remove.

This is why the humble-sounding phrase “local privilege escalation” deserves respect. SYSTEM-level, kernel-level control is not one more step in an attack – it is effectively the end of the defensive game on that machine. And on a dental practice’s computer, SYSTEM access means access to whatever that machine can reach: the practice-management database, imaging files, patient records, saved credentials, and potentially the path to your backups. It is the same escalation nightmare we walked through when one ordinary login proved enough to take over an entire Windows network – total control, quietly obtained.

“We’re a dental office, not a defense contractor”

True – Lazarus’s headline targets are governments, banks, and cryptocurrency firms, not a three-chair practice in the GTA. But two things make this relevant anyway.

First, the vulnerability is in Windows, not in some rarefied enterprise system. Every unpatched Windows machine at your front desk and in your operatories carries CVE-2026-68820 until it is updated. State-sponsored groups pioneer these techniques; ordinary ransomware crews adopt them within weeks. The exploit does not care who owns the computer.

Second, the lure fits a dental practice perfectly. Practices hire. Owners and office managers routinely receive resumes, recruiter messages, and “candidate” attachments – and dental staff, like everyone, get job offers on email and LinkedIn. An unsolicited CV for a hygienist position, or a too-good recruiting pitch to an associate, is a completely natural thing to open. That is precisely the psychology this attack weaponizes.

What to do now

The response is practical, and most of it defends against the whole class of two-stage attack, not just this one CVE.

Apply the August 2026 Patch Tuesday updates – promptly. Microsoft’s update fixes CVE-2026-68820. Because it is under active exploitation, this is not a “next maintenance window” item; it is an update-this-week item across every practice computer. If any of your machines are still on an unsupported version of Windows, they will never receive this fix at all – which is the standing danger we detailed in why running an out-of-support operating system at the front desk is now a compliance problem.

Do not let staff run as local administrators. Day-to-day accounts should be standard users. It will not stop this particular kernel flaw, but least privilege limits what stage one of an attack can do before any escalation, and it blocks a huge range of simpler malware outright.

Run – and monitor – modern endpoint protection. A rootkit’s goal is to blind your defenses, so those defenses need to be current, tamper-resistant, and actually watched. Endpoint detection and response (EDR) that alerts a human, rather than antivirus nobody checks, is what catches the unusual behavior around an escalation attempt.

Allow only approved software to run. Application allow-listing means an unexpected executable delivered by a “recruiter” simply cannot launch in the first place – it stops stage one before it starts.

Treat job offers and candidate files as phishing. Train the team: unsolicited recruitment messages, resume attachments, and links to “job details” get the same scrutiny as any suspicious email. Verify senders independently. When in doubt, do not open it on a practice computer.

Segment the network and keep offline backups. If one machine is compromised, segmentation and least privilege decide whether the damage stops there or spreads to your server and records. And offline, tested backups are what turn a worst-case compromise from a catastrophe into a recovery.

The takeaway

CVE-2026-68820 is a single Windows flaw, now patched – but the attack around it is a template that will be reused endlessly: charm a human into running something small, exploit a flaw to escalate to total control, then hide beneath the defenses. The good news is that the countermeasures are the same durable fundamentals that defend against nearly everything else – patch quickly, limit privilege, watch your endpoints, and teach people that a great job offer can be bait.

Compudent Systems helps dental practices across the GTA and Ontario put exactly these fundamentals in place – keeping every practice computer patched against actively exploited flaws like this one, removing unnecessary administrator rights, deploying and monitoring real endpoint protection, and segmenting the network so a single tricked click cannot become a practice-wide breach. If you are not certain your workstations are current on this month’s Windows updates, or that a compromised front-desk PC could not reach your patient records, contact Compudent Systems for an endpoint and patch-management review. The attackers are counting on a friendly-looking message and a machine nobody remembered to update.

Sources & further reading:

• Microsoft August 2026 Patch Tuesday fixes 400 flaws, 3 zero-days – BleepingComputer
• Shattering the Dream: When a Job Offer Becomes a Zero-Day Attack – Check Point Research
• CISA Known Exploited Vulnerabilities Catalog

Related Reading

• Ransomware Gangs Are Now Through the Front Door: What the SonicWall SMA1000 VPN Attacks Mean for Dental Practices
• The Other Computers in Your Operatory: Why Connected Dental Devices Are the Attack Surface Nobody Audits
• One Ordinary Login Can Now Own Your Whole Network: What the ‘Certighost’ Windows Domain Exploit Means for Dental Practices

The post A Fake Job Offer, a Windows Kernel Rootkit: The Lazarus Zero-Day (CVE-2026-68820) and What It Means for Your Dental Practice appeared first on Compudent Systems.

On August 11, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) confirmed that ransomware gangs are now actively exploiting two vulnerabilities in SonicWall’s SMA1000 series – secure remote-access (SSL VPN) appliances that let staff reach an internal network from outside it – and added both flaws to its Known Exploited Vulnerabilities catalog. The appliances were first attacked as zero-days to plant custom malware; now criminal crews have industrialized it. Here is what happened, why an edge appliance is such a dangerous thing to lose, and what a dental practice should do about it – even one that has never heard of an SMA1000.

What the attackers are exploiting

Two flaws, and it is the combination that hurts. The first, CVE-2026-15409, carries the maximum severity score possible – CVSS 10.0 – and it is pre-authentication, meaning an attacker needs no valid login to use it. It is a server-side request forgery (SSRF) flaw in the appliance’s public-facing interface that lets a remote attacker force the device to open a hidden tunnel to internal services it should never expose. The second, CVE-2026-15410 (CVSS 7.2), is a command-injection weakness reachable through the appliance’s management console that lets the attacker run commands and escalate to root – total control of the box.

Chained together, they turn an internet-facing security appliance into an attacker-owned foothold with root privileges, positioned at the exact boundary between the open internet and the trusted network. That is the whole game. The device whose job is to be the guarded door becomes the open door. Researchers tracking the campaign name INC Ransomware as the dominant group weaponizing the flaws – the pattern that reliably follows: initial access through the appliance, then lateral movement, data theft, and encryption.

Why losing the edge appliance is worse than losing a PC

An internet-facing remote-access appliance is a uniquely valuable target for three reasons at once. It is reachable by the entire internet, so attackers can hammer it continuously from anywhere. It is trusted to reach inside – its whole purpose is to bridge outside users to internal systems, so whoever controls it inherits that bridge. And it is easy to forget: it sits in a closet, it “just works,” and its firmware quietly falls behind because updating it means scheduling downtime that nobody wants to schedule.

Compare that to a single infected workstation, which an attacker still has to escalate and pivot from. Owning the VPN appliance skips several steps – it is already at the perimeter, already privileged, already connected to what matters. It is the same lesson behind the recent advisories on practice routers, where we explained why an internet-facing network device can quietly become a backdoor into the whole office, and behind the compromise of remote management tools, where the very software trusted to manage a network became the way into it. Edge and remote-access infrastructure is where modern intrusions begin.

“But we don’t run an SMA1000”

Fair – and worth being honest about. The SMA1000 is an enterprise-grade appliance that skews toward larger, multi-location dental groups, DSOs, and specialist practices with remote and satellite access, rather than a single-operatory office. If you are a small practice, you may well not have this specific box.

That does not let anyone off the hook, because the category is nearly universal. Almost every practice that supports remote work, multiple sites, or outside IT support runs some internet-facing remote-access gear: a VPN concentrator, a firewall with a VPN client, a remote-desktop gateway, or an appliance from SonicWall or another vendor. The specific CVE numbers change month to month; the exposure does not. This advisory is a prompt to look hard at your own edge, whatever brand is on it. If a maximum-severity, no-password-required flaw can turn one vendor’s appliance into a ransomware on-ramp, the question for every practice is simply: what is my equivalent device, and is it patched?

What to do now

The response is disciplined, not dramatic – and most of it applies to any remote-access appliance, not just SonicWall’s.

Patch immediately – or pull it offline. SonicWall has released fixed firmware for the affected SMA1000 appliances. If you run one, update it to the patched version now; these flaws are under active ransomware exploitation, which is as urgent as advisories get. If for some reason it cannot be patched right away, take it offline until it can be – an appliance you cannot patch today should not be facing the internet today.

Inventory your internet-facing devices. Most practices cannot immediately name every device exposed to the internet and the firmware each one runs. Build that list: firewalls, VPN and remote-access appliances, remote-desktop gateways, anything reachable from outside. Then confirm each is on current, supported firmware. Pay special attention to end-of-life gear – an unsupported appliance still facing the internet is a standing invitation, because it will never get the next fix.

Require multi-factor authentication on all remote access. MFA will not stop a pre-auth appliance flaw by itself, but it blunts the credential-theft attacks that ride in alongside these campaigns and closes off the reused-password path that so many intrusions still use.

Get the management interface off the public internet. The administrative console of a firewall or VPN appliance should never be reachable from the open internet – restrict it to the internal network or a controlled management path. A great many appliance compromises begin with a management interface that simply should not have been exposed.

Segment and least-privilege what remote access can reach. If the worst happens, the difference between “one appliance was compromised” and “the whole practice was encrypted” is segmentation. Limit what a remote-access appliance and its users can touch, so a foothold at the edge cannot casually reach your practice-management server and patient records. This is the same containment logic that keeps a single stolen login from becoming a full domain takeover, a scenario we walked through when one ordinary login was enough to own an entire Windows network.

Watch for signs of compromise, and keep offline backups. Review appliance logs and network activity for anomalies, and make sure you have offline, tested backups of your systems and records. Ransomware is not an abstract IT inconvenience – as we have written, it is now measured as a patient-safety issue, and recoverability is what determines whether an incident is a bad week or an existential one.

The takeaway

The SonicWall SMA1000 attacks are a specific event, but the lesson is general and durable: the perimeter device you installed to keep people out is, when it falls behind on patches, the most direct way in. Ransomware crews know this, which is why internet-facing appliances – not phishing emails – are increasingly where their intrusions start. You do not need to run this particular appliance to inherit the risk; you only need to have something facing the internet that you have not looked at in a while.

Compudent Systems helps dental practices across the GTA and Ontario find and close exactly this gap – inventorying every internet-facing appliance and its firmware, confirming remote-access gear is patched against active threats like the SonicWall SMA1000 flaws, enforcing MFA, pulling management interfaces off the public internet, and segmenting the network so a compromised edge device has nowhere to go. If you cannot say today which of your devices faces the internet, or whether its firmware is current, contact Compudent Systems for a remote-access and network-edge security assessment. The door you forgot to check is the one attackers are counting on.

Sources & further reading:

• CISA: SonicWall SMA1000 flaws now exploited by ransomware gangs – BleepingComputer
• INC Ransomware Emerges as Dominant Actor Exploiting SonicWall SMA1000 Flaws – The Hacker News
• Recent SonicWall Vulnerabilities Exploited in Ransomware Attacks – SecurityWeek
• CISA Known Exploited Vulnerabilities Catalog

Related Reading

• A Fake Job Offer, a Windows Kernel Rootkit: The Lazarus Zero-Day (CVE-2026-68820) and What It Means for Your Dental Practice
• When the Tool That Manages Your Network Gets Hacked: The N-able N-central Breach and What It Means for Dental Practices
• A Forged Login Walks Straight Into SharePoint: What the Actively Exploited CVE-2026-55040 Auth Bypass Means for Dental Practices

The post Ransomware Gangs Are Now Through the Front Door: What the SonicWall SMA1000 VPN Attacks Mean for Dental Practices appeared first on Compudent Systems.

On August 6, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) published a medical advisory, ICSMA-26-218-01, for a flaw in the RadiAnt DICOM Viewer – one of the most widely used standalone viewers for opening CT, MRI, CBCT and radiograph studies, common in dental and medical offices alike. Tracked as CVE-2026-17264, the flaw lets a specially crafted DICOM file crash the viewer and, in the worst case, potentially run an attacker’s code on the machine that opened it. Here is what that actually means for a dental practice, and the short list of what to do.

What the flaw is – in plain terms

Every DICOM file carries the image itself as compressed pixel data. To show you the X-ray, the viewer has to decompress that data into memory. CVE-2026-17264 is what happens when an attacker deliberately malforms the JPEG-compressed pixel data inside a DICOM file so that, as RadiAnt decompresses it, the program writes past the edge of the memory it set aside – a classic out-of-bounds write. At minimum, that corruption crashes the viewer. Because the attacker has some control over what gets written and where, this class of bug is also the raw material for something worse: getting the program to execute code the attacker chose.

To be precise about the severity, because it matters: CISA rates this Medium (CVSS 4.3 to 5.3, depending on the scoring version). The reliably demonstrated impact is a crash; remote code execution is a documented possibility of the underlying memory bug, not a proven, packaged exploit. Two other facts round out the honest picture – the attack requires user interaction (the malicious file has to be opened), and CISA says there is no known public exploitation to date. This is not a five-alarm, patch-tonight-or-else emergency. It is exactly the kind of quiet, routine-maintenance item that practices skip – which is why it is worth thirty minutes of attention now rather than none.

Why the dental angle is real, not theoretical

The reason this advisory deserves a dental practice’s attention is the delivery path. The flaw needs someone to open a hostile file – and opening imaging files from outside the practice is not an edge case, it is a daily task. Patient CDs and USB sticks from prior providers, DICOM studies from specialist referrals, images pulled from an imaging-exchange portal, scans sent as email attachments: all of it lands on a practice computer and gets opened in a viewer, often by front-desk or clinical staff who have every reason to trust it.

That is the uncomfortable fit. “Requires the user to open a file” sounds like a safeguard until you remember that opening outside files is the job. A malicious DICOM does not need to breach your firewall or crack a password; it just needs to look like a legitimate scan and reach the person whose role is to review scans.

And even the mild outcome carries a clinical cost. An imaging viewer that crashes when you open a study is a workstation down in the middle of a patient appointment – lost time, a delayed read, a scramble to view the image somewhere else. If the bug were ever weaponized past a crash, the machine at risk is one that routinely holds patient images, which raises the stakes from nuisance to a potential PHIPA problem.

What to do about it

The response here is refreshingly ordinary – the same disciplines that handle any software flaw, applied to a category practices often forget to include: their imaging tools.

Update RadiAnt now. Medixant has already released a fixed version – the current download explicitly notes the fix for CVE-2026-17264 – and versions 2025.2 and earlier are the vulnerable ones. Update RadiAnt to the latest release on every machine that has it, not just the main imaging PC. If a workstation is on an old version because “it still works,” that is precisely the one to fix.

Find out where it even lives. Most practices cannot immediately say which computers have a DICOM viewer installed, or which versions. Standalone viewers get installed quietly – to open one referral disc two years ago – and then linger, unpatched and unmanaged. A quick inventory of which machines run RadiAnt (or any imaging viewer) and what version they are on turns an unknown into a managed list.

Treat outside DICOM files like any other untrusted attachment. The same instinct staff apply to an unexpected email attachment applies here: be wary of imaging discs, drives and links that arrive unsolicited or from an unverified sender, and confirm the source before opening. This is not about refusing legitimate referrals; it is about not blindly opening a random file because it claims to be a scan.

Wall off the imaging workstations. This is the step that turns a worst case into a contained one. If the machines that open outside imaging are segmented from the rest of the network and run under least privilege, then even a viewer that gets compromised cannot casually reach your practice-management server, your other workstations, or the bulk of your patient records. Segmentation is the difference between “one PC had a bad day” and “the whole office is encrypted.”

Keep imaging software on a patch cadence – and keep backups. Clinical imaging tools deserve the same routine updating as Windows and your practice-management system, not a set-it-and-forget-it exception. And as always, confirm you have offline, tested backups of your imaging and records, so any bad outcome is recoverable.

The takeaway

CVE-2026-17264 is not a crisis, and treating it like one would be its own mistake. What it is, is a clean example of a blind spot: practices patch their operating systems and their practice-management software diligently, then run a separate imaging viewer for years without a thought – the one program whose entire purpose is to open files from strangers. The fix is already available. The only real risk is the one that comes from not knowing the viewer is there.

Compudent Systems helps dental practices across the GTA and Ontario close exactly this kind of gap – inventorying which machines run imaging software and which versions, confirming RadiAnt and your other viewers are updated against CVE-2026-17264, and segmenting and hardening the workstations that open outside imaging so a booby-trapped file has nowhere to go. If you cannot say today which of your computers has a DICOM viewer installed, or whether it is current, contact Compudent Systems for an imaging-workstation and patch assessment. It is a small, quiet thing to get right – which is exactly why it gets missed.

Sources & further reading:

• Medixant RadiAnt DICOM (ICSMA-26-218-01) – CISA Medical Advisory
• CVE-2026-17264 – CVE Record
• RadiAnt DICOM Viewer – Version History / Download (Medixant)

Related: Medtronic Data Breach by ShinyHunters: Critical Warning for Medical Device Security in Dental Practices

Related Reading

• Where Was Your Imaging Sensor Made, and What Is It Talking To? Device Provenance Is Now a Dental Practice Security Question
• From Roentgen’s Lab to Your Practice Server: How Dental X-ray Imaging Became an IT Discipline
• A Fake Job Offer, a Windows Kernel Rootkit: The Lazarus Zero-Day (CVE-2026-68820) and What It Means for Your Dental Practice

The post A Booby-Trapped X-ray File: What the RadiAnt DICOM Advisory (CVE-2026-17264) Means for Dental Practices appeared first on Compudent Systems.

Microsoft has already patched the underlying flaw, tracked as CVE-2026-54121, as part of its July 2026 Patch Tuesday – a record batch of 622 fixes. But in late July, security researchers released a working proof-of-concept exploit, which moves this from a theoretical advisory to a tool anyone can run. For any practice that has not yet applied that update, the window between “patch available” and “exploit public” has now closed. Here is what changed, and the short list of what to do about it.

What Certighost actually does

The flaw lives in Active Directory Certificate Services (AD CS) – the part of Windows Server that issues the digital certificates a network uses to prove identity. In a normal setup, AD CS is meant to hand out modest certificates to ordinary users and machines. Certighost lets an attacker abuse that process so that an everyday domain account requests a certificate that lets it authenticate as something it is emphatically not: a Domain Controller, the machine that governs the entire network.

Once an attacker can pose as a domain controller, the game is effectively over. Domain-controller accounts carry directory-replication rights, which the attacker uses to copy the domain’s most sensitive secret – the master credential every Windows account is derived from. With that in hand, they can mint access to any account they like, including full administrator, and move through the network at will. The researchers who found it, Aniq Fakhrul and Muhammad Ali, demonstrated the whole chain starting from a plain, unprivileged user. That is what makes it dangerous: the starting point is not a stolen admin password. It is any login at all.

Why “any authenticated user” is a low bar

It is tempting to read “the attacker needs an authenticated account” as reassuring. It is not. In a dental practice, an authenticated account is simply any staff member’s Windows login – and there are several ways an attacker gets one. A single phishing email that captures a hygienist’s or receptionist’s password is enough. So is a weak or reused password sprayed against your remote-access portal, or a former employee’s account that was never disabled. None of these give an attacker anything special on their own; that is exactly why they are common and often overlooked. Certighost turns one of those ordinary footholds – the kind that used to mean limited damage – into a straight path to owning the entire network.

What full domain takeover means in a clinical setting

Abstract exploits deserve concrete stakes. When an attacker controls your domain controller, they control every computer joined to it: the front-desk workstations, the operatory PCs, the imaging server, and the file shares where radiographs and patient records live. In practice, that is the launch position for the worst days a practice can have.

From there, an attacker can deploy ransomware to every machine simultaneously rather than one at a time, encrypting your entire practice in minutes. They can exfiltrate protected health information wholesale, creating a reportable PHIPA breach with all the notification duties that follow. And they routinely go looking for your backups first – because backups reachable from the network can be deleted or encrypted along with everything else, turning a recoverable incident into an existential one. A domain compromise is not one problem; it is the master key to all of them.

What to do now

The good news is that the response is well-defined and does not require an enterprise budget – it requires acting deliberately on a handful of items.

Apply the updates. The single most important step is installing Microsoft’s July 2026 (and all subsequent) security updates on every Windows Server, especially any acting as a domain controller. If you are not certain your server is current, that uncertainty is itself the finding – resolve it this week.

Find out whether AD CS is even running, and whether you need it. Many small practices have Active Directory Certificate Services enabled without ever having deliberately turned it on or using it for anything. A service you do not use is attack surface you do not need. Have your IT provider confirm whether AD CS is present, whether it is required, and if so, whether its certificate templates and enrollment settings are configured safely – the specific misconfigurations this class of attack relies on are exactly what a review is meant to catch and lock down.

Shrink who can log in at all. Because the attack begins with an ordinary authenticated account, everything that reduces the odds of an attacker holding one helps: enforce multi-factor authentication on remote access and email, retire dormant and former-staff accounts, insist on strong unique passwords, and follow least privilege so no account carries more rights than the job needs.

Watch, and keep a way back. Ask whether your systems can flag the abnormal certificate requests and directory-replication activity this attack produces, so an attempt is noticed rather than silent. And confirm you have offline, tested backups – copies an attacker who owns the domain cannot reach and destroy. If containment ever fails, that disconnected, verified backup is the difference between a bad week and a closed practice.

The takeaway

Certighost is a clean illustration of a modern truth: the gap between a low-value foothold and total compromise keeps shrinking, and the features that close it are often ones you did not know were running. The flaw is patched – which means the practices that get hurt will overwhelmingly be the ones that simply never applied the update or never checked their configuration. Neither is a technology problem. Both are a follow-through problem.

Compudent Systems helps dental practices across the GTA and Ontario close exactly these gaps – confirming your servers are patched against Certighost and the rest of July’s fixes, determining whether Active Directory Certificate Services is running and hardening or removing it, tightening account privileges and MFA so a single stolen login goes nowhere, and verifying you have offline backups that survive a worst case. If you cannot say today whether your practice server has this month’s updates, or whether AD CS is quietly enabled on it, contact Compudent Systems for a domain and patch assessment. It is a far better thing to learn on your own schedule than on an attacker’s.

Sources & further reading:

• New Certighost PoC exploit lets attackers hijack Windows domains (BleepingComputer)
• Certighost Exploit Lets Low-Privileged Active Directory Users Impersonate a Domain Controller (The Hacker News)
• ‘Certighost’ Flaw Haunts Microsoft Active Directory Certificates (Dark Reading)

Related: Medtronic Data Breach by ShinyHunters: Critical Warning for Medical Device Security in Dental Practices

Related Reading

• A Forged Login Walks Straight Into SharePoint: What the Actively Exploited CVE-2026-55040 Auth Bypass Means for Dental Practices
• Public Exploit Code Is Now Out for a Critical SCCM Flaw: What CVE-2026-47301 Means If Anyone Manages Your Practice’s Windows Fleet
• A Fake Job Offer, a Windows Kernel Rootkit: The Lazarus Zero-Day (CVE-2026-68820) and What It Means for Your Dental Practice

The post One Ordinary Login Can Now Own Your Whole Network: What the ‘Certighost’ Windows Domain Exploit Means for Dental Practices appeared first on Compudent Systems.

The finding: ransomware raises in-hospital mortality

The study, published in the American Economic Journal: Economic Policy, did not rely on a model or a survey. It linked Medicare claims data to confirmed ransomware incidents and found that in-hospital mortality for patients already admitted when an attack begins rises by roughly 34 to 38 percent. Separately, the Halcyon Ransomware Research Center, drawing on University of Minnesota data, estimated 42 to 67 preventable deaths over a five-year period, with mortality among hospitalized Medicare patients climbing from about three in 100 to four in 100 under attack conditions.

The reason is grimly practical. When systems go dark, clinicians work blind. Medication histories vanish, imaging systems go offline, allergy records become inaccessible, emergency departments divert incoming ambulances elsewhere, pharmacies revert to paper, and procedures are postponed. Every one of those is a clinical decision made without the data that would normally inform it. The harm is not caused by the encryption itself – it is caused by the sudden absence of the information that modern care depends on.

Why this matters for a dental practice

A dental office will never appear in a hospital mortality statistic, and it would be alarmist to suggest otherwise. But the finding is a warning about a mechanism, not just a body count – and that mechanism is present in every practice that has gone digital. Your practice runs on a chain of dependence: the practice-management database that holds every schedule and chart, digital radiography and imaging that inform diagnosis, and the medication and allergy histories you check before administering anesthetic or prescribing. Sever that chain in the middle of a clinical day and you are not merely inconvenienced – you are practicing without the information you rely on to practice safely.

Consider the ordinary morning that turns bad: a hygienist cannot pull a patient’s radiographs to compare against today’s exam, the front desk cannot confirm a medical-history flag before an extraction, and a sedation appointment has to be postponed because the chart documenting the patient’s conditions is encrypted and unreadable. None of that makes the evening news, but each is a patient-safety event in miniature. The hospital research simply makes visible, at scale, what a small practice experiences one anxious appointment at a time. Cybersecurity, in other words, is now inseparable from continuity of care.

Why the industry is treating this as an emergency

The mortality research did not land in a vacuum. It arrived after a run of attacks large enough to reshape the entire sector’s thinking. The February 2024 Change Healthcare ransomware attack – carried out by the ALPHV/BlackCat group, which exfiltrated more than six terabytes of billing and protected health information – ultimately affected approximately 192.7 million individuals, close to two-thirds of the US population, with total costs estimated between $2.5 and $3 billion. Ascension Health, hit separately in May 2024, exposed data for 5.6 million patients and reported a $1.1 billion net loss for the year, citing the attack as a material factor. In the UK, the Synnovis pathology attack in June 2024 exposed the data of nearly a million NHS patients and forced hospitals to cancel operations and appointments for weeks.

That pattern is why, for the first time in its 29-year history, Black Hat USA 2026 hosted a dedicated Healthcare Cybersecurity Summit – built in formal partnership with HIMSS, the Healthcare Information and Management Systems Society, in the first-ever collaboration between the two organizations. The full-day program, held August 4, 2026 in Las Vegas, brought hospital CISOs, healthcare IT professionals, and clinical leaders together around a single theme: resilience and clinical-disruption response. When the offensive-security community and the healthcare-IT establishment convene their first joint summit, the signal is clear – this is being treated as one of the most urgent problems in the sector.

Small providers are not too small to be a target

A common and dangerous assumption in small practices is that attackers only chase the big fish. The opposite is increasingly true. Modern ransomware campaigns are largely automated and opportunistic; they scan for exposed remote-access ports, unpatched systems, and reused credentials, and they do not check the size of your business before striking. Worse, small healthcare providers are frequently connected to the same shared vendors, billing platforms, imaging clouds, and managed-service tools as much larger organizations – which means a practice can be swept up in an attack aimed elsewhere, or targeted precisely because it is seen as a softer path into a larger network. Being small is not camouflage. It is often the reason you are chosen.

The rules are about to change: the HIPAA Security Rule update

Regulators have reached the same conclusion the researchers did, and the compliance landscape is shifting to match. In January 2025, the US Department of Health and Human Services published a Notice of Proposed Rulemaking – the first proposed update to the HIPAA Security Rule in more than a decade. It would convert several long-recommended safeguards from voluntary “addressable” guidance into enforceable requirements, including multi-factor authentication, encryption of patient data at rest and in transit, annual penetration testing, and network segmentation. As of August 2026 the final rule has not been issued, with the Office of Management and Budget now targeting July 2027 for finalization.

For Canadian practices, HIPAA is not the governing law – PHIPA is – but the direction of travel is identical, and the technical controls are simply modern security hygiene regardless of jurisdiction. The practices that treat this proposed rule as a preview rather than a distant American formality will be the ones that are ready, not scrambling, when their own regulators, insurers, and cyber-insurance underwriters ask the same questions. Cyber-insurance renewals, in particular, already demand MFA and tested backups as a condition of coverage.

What a dental practice should do now

The good news is that the safeguards that protect patients are the same ones that protect the business, and none of them require a hospital budget. Turn on multi-factor authentication everywhere it is available – email, remote access, practice-management logins, and cloud imaging – because it is the single most effective barrier against the stolen-credential attacks that start most incidents. Segment the network so that imaging devices, the front-desk workstations, guest Wi-Fi, and the server are not all sitting on one flat network where malware can move freely from a compromised laptop to your database. Keep backups offline or immutable and test that they actually restore, so an attack becomes a bad afternoon rather than a closed practice. Patch promptly, especially anything exposed to the internet. And build a simple downtime plan – a printed emergency protocol for how the office keeps patients safe if the systems are unavailable, so that being offline is a rehearsed contingency, not a crisis.

The reframing at the heart of this year’s research is the part worth keeping: in healthcare, cybersecurity is no longer just about protecting data. It is about protecting the continuity of care that patients depend on. A dental practice sits squarely inside that reality.

Compudent Systems helps dental practices across the GTA and Ontario get ahead of exactly these requirements – deploying multi-factor authentication, segmenting practice networks so imaging and workstations are properly isolated, hardening remote access, and building tested backup and downtime plans that keep a practice running through an incident. If you are not confident your office could keep patients safe and its records intact through an attack, contact Compudent Systems for a security and resilience assessment measured against the standards healthcare is now adopting. It is far better to prepare for this on your own schedule than on an attacker’s.

Sources & further reading:

• Hospital Ransomware Raises Patient Mortality 38%: Black Hat and HIMSS Launch Healthcare Summit
• American Economic Journal: Economic Policy – ransomware and in-hospital mortality (Feb 2026)
• Black Hat and HIMSS Partner to Launch Inaugural Healthcare Cybersecurity Summit at Black Hat USA 2026

Related: Medtronic Data Breach by ShinyHunters: Critical Warning for Medical Device Security in Dental Practices

Related Reading

• Dental Practice Cybersecurity Alert: Major Breaches and 58% Surge in Healthcare Ransomware
• Dental Practices Under Siege: The Rising Threat of Ransomware Targeting Healthcare Data
• Ransomware Attacks on Healthcare Surged 58% in 2025: What Dental Practices Need to Know in 2026

The post Ransomware Is Now a Patient-Safety Issue: What a 38% Hospital Mortality Study Means for Your Dental Practice appeared first on Compudent Systems.

The green light lies

Backup software is built to reassure you. The job runs overnight, an email says “completed successfully,” a status light stays green, and everyone moves on. None of that tells you whether the data can come back. It tells you the copy operation finished – nothing more.

Untested backups fail silently in three ways, and each one hides comfortably behind that green light. The first is incomplete scope. A backup set that was configured years ago may faithfully copy one folder while quietly missing the imaging database, the scanned-document store, or a drive that was added later. It succeeds every night – at protecting the wrong things. The second is corruption. Files can rot, a database can be captured mid-write in an inconsistent state, and media degrades. The backup exists; it simply will not open. Nobody notices until the day it has to. The third, and the one doing the most damage right now, is that the backup was online when the ransomware arrived.

Why ransomware makes this urgent

Modern ransomware does not politely encrypt one computer and stop. It spreads across the network hunting for exactly the things you would use to recover – and connected backup drives and network shares are at the top of that list. If your backup is a USB drive that stays plugged into the server, or a network folder the server can write to at any time, then the attacker can write to it too. Your live data and your safety net get encrypted in the same stroke.

This is why “we have backups” and “we can recover from ransomware” are not the same sentence. Practices that thought they were covered have watched their nightly backup encrypt right alongside production, because the two were never truly separated. The lesson is blunt: a backup you can reach from an infected machine is a backup an attacker can destroy.

The 3-2-1 rule, and the copy that saves you

The durable answer is a discipline, not a product. The classic framing is the 3-2-1 rule: keep three copies of your data, on two different types of media, with one copy offsite. Three copies means a single failure never leaves you at zero. Two media types means one flaw – a bad drive model, a single storage technology – cannot take them all at once. One offsite copy means a fire, flood, or theft at the office does not erase your patient records along with the building.

For the ransomware era, add one word to that offsite copy: immutable, or air-gapped. An immutable backup cannot be altered or deleted for a set retention window, even by an administrator account – so encryption malware and stolen credentials both hit a wall. An air-gapped copy is simply one that is physically or logically disconnected when it is not actively being written, so there is nothing for an attacker on the network to reach. Reputable cloud backup with immutability, or a rotation of offline drives kept disconnected, both get you there. The principle is the same: at least one copy of your practice’s data must live somewhere that a compromised server cannot touch.

RPO and RTO, in plain terms

Two numbers decide what “good enough” means for your practice, and you do not need a data-center vocabulary to set them. RPO – Recovery Point Objective – is how much data you can afford to lose, measured in time. If you back up once a night and the server dies at 4 p.m., every appointment, chart note, X-ray, and payment entered that day is gone. That is a 24-hour RPO. If losing a full day of clinical work is unacceptable – and for most practices it is – you need backups running far more often than once a day.

RTO – Recovery Time Objective – is how long you can afford to be down while you restore. A practice that can rebuild and reload in two hours has a very different day than one that needs three days to reinstall software, re-import a database, and reconnect imaging. Every hour of RTO is cancelled appointments, idle staff, and patients who may not come back. Deciding these two numbers ahead of time is what turns a vague “we have backups” into a plan you can actually stand behind – and it is the yardstick every test restore measures against.

A quarterly test restore, step by step

Here is the practice that separates a real backup from a hopeful one. At least once a quarter – and after any major software change – perform a deliberate test restore. Do it on purpose, on the calendar, not in a panic.

1. Restore to isolated hardware. Never test by overwriting production. Use a spare machine or an isolated virtual environment so a failed test cannot harm live data. 2. Restore from the copy you would actually use in a disaster – including the offsite or immutable copy, not just the convenient local one. The offsite path is the one most likely to hide a surprise. 3. Open the data, do not just copy it. A restore is not finished when files land on disk; it is finished when the practice-management software launches against the restored database and real records appear. 4. Spot-check real records. Pull up specific patients, confirm their charts, images, and documents are present and correct, and that recent entries are actually there. 5. Time it. Measure how long the full restore took and compare it against your RTO. If it took a day and your target was two hours, you have found a problem in a drill instead of a disaster. 6. Write down what broke – a missing folder, a wrong credential, an out-of-date recovery note – and fix the backup configuration so the next test is cleaner. A test that surfaces a flaw is a success, not a failure.

What a dental office must verify, specifically

Generic backup advice misses what makes a dental restore complicated: your patient record is not one file in one place. A convincing test restore has to prove that all of it comes back, and comes back together.

The practice-management database. This is the heart – Dentrix, Eaglesoft, Open Dental, or whatever you run. Databases must be backed up in a consistent state, and the only proof is launching the application against the restored copy and confirming schedules, charts, ledgers, and treatment plans open cleanly. Digital imaging and sensor data. Radiographs, intraoral photos, CBCT volumes, and pano images are frequently stored separately from the database and linked by reference. A restore that recovers the database but not the image store – or breaks the link between them – leaves you with charts pointing at pictures that no longer exist. Verify that images open and are correctly associated with their patients. Scanned documents. Signed consent forms, insurance correspondence, referral letters, and IDs are often a separate document repository. Confirm it is in scope and that files open. System configuration. Bridge and integration settings, imaging-device drivers and calibration, user accounts and permissions, and the licensing that lets the software run at all. Recovering the data but not the configuration that makes it usable can still cost you days. Verify the practice is not just restored, but actually operational.

Prove it before you need it

The difference between a minor incident and a practice-threatening one is almost never whether backups existed. It is whether anyone had proven they work. A tested restore turns your backup from a hopeful checkbox into a genuine guarantee – and it is far cheaper to discover a gap in a scheduled drill than in the middle of a ransomware negotiation with a waiting room full of patients.

Compudent Systems helps dental practices across the GTA and Ontario design a backup strategy built for this reality – proper 3-2-1 coverage, an offsite and immutable copy ransomware cannot reach, RPO and RTO targets matched to how your practice actually runs, and scheduled test restores that verify your database, imaging, documents, and configuration all come back. If you cannot say with confidence when your backups were last successfully restored, contact Compudent Systems for a backup and recovery assessment. Let us prove it works before the day you need it to.

Related: Medtronic Data Breach by ShinyHunters: Critical Warning for Medical Device Security in Dental Practices

Related Reading

• Ransomware Is Now a Patient-Safety Issue: What a 38% Hospital Mortality Study Means for Your Dental Practice
• Dental Practice Cybersecurity Alert: Major Breaches and 58% Surge in Healthcare Ransomware
• Dental Practices Under Siege: The Rising Threat of Ransomware Targeting Healthcare Data

The post Your Backups Are Only as Good as Your Last Test Restore: A Dental Practice Reality Check appeared first on Compudent Systems.

That machine in your operatory today only looks like its ancestor. Underneath, it has quietly become one of the most demanding computing systems in your entire practice.

From a darkroom to a data pipeline

The shift happened in stages, and each one added a layer of technology that someone now has to manage. Film gave way to phosphor plates and then to solid-state digital sensors that plug straight into a computer. The standalone panoramic unit grew a network port. Cone beam CT arrived and started producing not a single image but a three-dimensional volume made of hundreds of slices. Somewhere in that progression, the question stopped being “is the picture sharp?” and became “where does the picture go, who can see it, and what happens if the server holding it dies?”

In other words, imaging stopped being a clinical device you operate and became an IT system you run. Most practices crossed that line years ago without ever deciding to. The equipment vendor sold a sensor; the sensor needed a workstation; the workstation needed a server; the server needed a network, a backup, and a security posture. Nobody framed it as an infrastructure project, but that is exactly what it is.

DICOM: the language your images speak

The thing that makes modern imaging hang together is a standard called DICOM, short for Digital Imaging and Communications in Medicine. It is the reason an intraoral sensor from one manufacturer, a panoramic unit from another, and a CBCT scanner from a third can all write files that your imaging software can open, measure, and store. A DICOM file is not just a picture. It carries a wrapper of metadata around the pixels: the patient identifier, the study date, the device, the exposure settings, and more.

That is enormously powerful, and it is also a quiet responsibility. Because a DICOM file embeds patient-identifying information alongside the image, every one of those files is a small package of protected health information. Standardization made imaging interoperable, but it also means the identity of your patient travels with the picture wherever it goes. When you understand that, the reason imaging needs to be treated as an IT discipline stops being abstract.

PACS and the imaging server: where your radiographs actually live

Ask most practice owners where their X-rays are kept and the honest answer is a shrug in the direction of the back office. The technical answer is a PACS, a Picture Archiving and Communication System, or its smaller cousin, a dedicated imaging server running inside your practice management ecosystem. This is the machine that receives every image the moment it is captured, stores it, and serves it back to every operatory that asks for it.

It is also, in most practices, a single point of failure that nobody has stress-tested. If that server’s drive fails on a Tuesday morning, you have not lost a file. You have potentially lost every radiograph you have ever taken, along with the ability to work up new patients until it is restored. The imaging server deserves the same seriousness you would give the machine that runs payroll, because clinically and legally it is doing something far more consequential.

The backup math nobody does until it is too late

Here is where imaging quietly breaks the casual backup plans that practices lean on. Radiographic data does not grow gently. A busy office generates intraoral series constantly, and a single CBCT scan can be tens or even hundreds of megabytes. Multiply that across years of patients and the imaging archive becomes, by a wide margin, the largest and fastest-growing pile of data you own.

The discipline that answers this is old and boring and works: the 3-2-1 rule. Keep three copies of your data, on two different types of media, with at least one copy stored offsite. In practice that means your live imaging server, a separate local backup, and an encrypted offsite or cloud copy that leaves the building. The failure mode we see again and again is a practice that technically has a backup, but it is a single external drive sitting on the same shelf as the server, unencrypted and untested. A fire, a flood, a theft, or a ransomware event takes both at once. A backup you have never restored from is a hope, not a plan.

Your images are protected health information

It is tempting to think of PHI as the stuff in the chart, the names and treatment notes and billing. A radiograph feels different, more like a photograph than a record. Legally and practically, it is not different at all. In Ontario, patient images fall squarely under the Personal Health Information Protection Act, and the obligations that come with PHIPA apply to that imaging archive just as firmly as they apply to your clinical notes.

Concretely, that means imaging data should be encrypted both where it sits and when it moves, especially if any of it is synced to the cloud. It means access should be controlled, so that the front desk, the hygienist, and the associate each see only what their role requires, rather than everyone sharing one login to an open folder. And it means you should be able to answer the question every regulator eventually asks after an incident: who accessed this patient’s images, and when? An audit trail is not bureaucracy. It is the difference between a contained event and a reportable breach.

Uptime is now a clinical issue

When X-rays lived in a filing cabinet, the imaging system never went down. The cabinet did not crash, get encrypted, or lose network connectivity. The tradeoff of digital imaging is speed and diagnostic power in exchange for dependence on systems that can fail. When the imaging server is unreachable, you cannot pull prior films, you cannot capture new ones into the record, and the schedule backs up behind a problem that has nothing to do with dentistry.

Treating imaging as an IT discipline means planning for that day before it arrives: redundancy so a single component failure does not stop the practice, monitoring so problems are caught before they become outages, and a recovery plan that has actually been tested against the clock. Hardware will eventually fail. The real question is how long your practice is down when it does, and whether you decided that number in advance or found it out the hard way.

One long thread, from 1895 to your server room

The story of the dental X-ray is one continuous thread: a glowing discovery in a Wurzburg laboratory, a century of film and chemistry, and a present in which every image is a data object that must be captured, standardized, stored, secured, backed up, and served without interruption. Roentgen gave us the picture. What we have built around it since is, unmistakably, information technology, and the practices that thrive with modern imaging are the ones that recognized this and resourced it accordingly.

Compudent Systems designs, secures, and supports the imaging and IT infrastructure that GTA and Ontario dental practices depend on every day, from DICOM-aware imaging servers and 3-2-1 backup strategies to PHIPA-aligned security, monitoring, and tested recovery plans. If you are not certain how your radiographs are stored, how quickly you could recover them, or who can see them, that is the conversation worth having now rather than after an outage. Contact Compudent Systems for an assessment of your practice’s imaging infrastructure and data protection.

Sources & further reading:

• DICOM – Digital Imaging and Communications in Medicine (official standard site)
• Personal Health Information Protection Act, 2004 (PHIPA), Ontario

The Story of the X-Ray, Across Our Network

How dental X-ray imaging became an IT discipline — the fuller history behind it:

• How Marie Curie drove X-ray trucks into the First World War
• What your dentist actually sees on an X-ray, 130 years on
• The equipment history from gas tubes to digital sensors

Related Reading

• A Booby-Trapped X-ray File: What the RadiAnt DICOM Advisory (CVE-2026-17264) Means for Dental Practices
• Where Was Your Imaging Sensor Made, and What Is It Talking To? Device Provenance Is Now a Dental Practice Security Question
• The Evolution of X-ray Technology in Dentistry: What Dental IT Professionals Need to Know

The post From Roentgen’s Lab to Your Practice Server: How Dental X-ray Imaging Became an IT Discipline appeared first on Compudent Systems.

On August 1, 2026, the vendor N-able confirmed that attackers were actively exploiting a flaw in N-central, its flagship Remote Monitoring and Management platform. Two days later, on August 3, the United States Cybersecurity and Infrastructure Security Agency added the vulnerability, tracked as CVE-2026-18577, to its Known Exploited Vulnerabilities catalog. That catalog is not a list of theoretical bugs. It is CISA’s list of flaws that criminals are provably using right now. N-able has shipped an emergency hotfix, but the reason this belongs in a dental publication has nothing to do with whether you run N-central yourself.

What actually happened

CVE-2026-18577 is an authentication bypass. In plain terms, it lets an attacker get past the login screen of an N-central server using an alternate path the developers did not intend, and take over the account. What makes it worse is the backstory: the flaw is an incomplete fix for an earlier vulnerability (CVE-2026-18556). The first patch did not fully close the door, and attackers walked back through the gap. N-able released hotfix version 2026.3.1.7 and urged every customer to install it immediately. Cloud-hosted servers were updated automatically; on-premises servers have to be patched by hand, which means some are still exposed while their owners catch up.

Investigators reported that attackers used the bypass to take over N-central servers, reach the endpoints those servers manage, and quietly maintain their access afterward. This is not a smash-and-grab. It is the kind of foothold that lets an intruder sit inside a network and wait.

Why a management tool is the ultimate skeleton key

To understand why security professionals treat RMM compromises as a worst case, picture what the tool is built to do. An RMM platform exists so that one technician can manage hundreds or thousands of computers across many different businesses from a single dashboard. It has permission to install software, change settings, run scripts, and connect remotely to any machine under its control. That is enormously convenient on a normal day. It is catastrophic on a bad one.

When an attacker takes over the management platform, they inherit all of that power at once. They do not have to break into each computer individually. They log into the tool that was already trusted to reach everything, and they use it exactly as intended, only now on behalf of a criminal. This is why the flaw is best understood as a master key rather than a single broken lock. One bypassed login can translate into control over every endpoint the platform touches.

“But my practice does not use N-central”

Here is the part that surprises most practice owners. You probably are not an N-able customer, at least not directly. RMM platforms like N-central are used by managed service providers and IT companies to run their clients’ networks. If your practice outsources its IT, or even if you have one internal IT person who uses management software to keep the office patched and monitored, there is a strong chance an RMM tool of some kind is installed on your computers right now.

That is what makes these supply-chain attacks so effective. The criminals do not need to find and target your specific dental office. They compromise the provider in the middle, and every practice that provider manages is suddenly within reach through a single breach. It is the same pattern the industry has watched play out again and again with other management platforms, from Kaseya and ConnectWise ScreenConnect to SimpleHelp and the infamous SolarWinds Orion incident. The management layer is a high-value target precisely because so many downstream businesses trust it implicitly.

What a compromise would mean for your patients

For a dental practice, the endpoints an RMM tool can reach are not abstract. They are the workstation at the front desk, the server running your practice-management software, and the computers connected to your imaging and radiography systems. All of it sits on the same network the management platform is trusted to administer. An attacker who reaches those systems can deploy ransomware that freezes your entire operation, or quietly copy patient records, appointment histories, and images out the door.

Under PHIPA in Ontario and privacy law across Canada, patient health information that is accessed or exfiltrated through a compromised vendor is still your responsibility to safeguard and, if breached, to report. “Our IT company got hacked” is an explanation, not a defense. Regulators and patients expect you to have chosen and overseen your providers with care, which is exactly why the next section is about oversight rather than technical wizardry.

Questions to ask your IT provider this week

You do not need to understand authentication bypasses to manage this risk. You need to make sure someone competent is on top of it, and a few direct questions will tell you a great deal.

Start with the obvious: Do we use N-able N-central, and if so, has it been updated to hotfix 2026.3.1.7 or later? If your provider uses a different RMM platform, ask the same question in general terms: what remote-management software has access to our systems, and how quickly is it patched when a flaw like this appears? Then go a step further. Ask whether access to that management tool is protected by multi-factor authentication, whether logins to it are monitored and alerted on, and whether your practice’s network is segmented so that a single compromised device cannot reach your imaging and patient records unimpeded. Finally, ask the accountability question: if your management platform were ever compromised, how and how quickly would we be told? A provider who answers these clearly and without defensiveness is one worth keeping. Vague or annoyed answers are themselves a finding.

The trust you cannot see

The uncomfortable truth of modern IT is that your practice’s security depends on tools you never see and vendors several steps removed from your reception desk. That is not a reason for alarm, but it is a reason for diligence. The businesses that weather incidents like this one are not the ones that got lucky. They are the ones whose IT was patched fast, monitored closely, and segmented sensibly, so that even a compromised management tool ran into walls instead of an open path to patient data.

Compudent manages the networks and endpoints of dental practices across the GTA and Ontario, and we treat the security of our own management tools as seriously as the systems they protect: prompt patching, multi-factor access, active monitoring, and segmentation that keeps imaging and patient records walled off from everything else. If you are not certain what remote-management software can reach into your practice right now, or how fast it gets patched when CISA raises an alarm, that is the conversation to have this week. Contact Compudent Systems for a review of your practice’s IT and vendor security before an unseen tool becomes a reportable breach.

Sources & further reading:

• CISA Adds One Known Exploited Vulnerability to Catalog (CVE-2026-18577, N-able N-central)
• N-able warns of N-central auth bypass flaw exploited in attacks – BleepingComputer

Related: Medtronic Data Breach by ShinyHunters: Critical Warning for Medical Device Security in Dental Practices

Related Reading

• Public Exploit Code Is Now Out for a Critical SCCM Flaw: What CVE-2026-47301 Means If Anyone Manages Your Practice’s Windows Fleet
• A Forged Login Walks Straight Into SharePoint: What the Actively Exploited CVE-2026-55040 Auth Bypass Means for Dental Practices
• Ransomware Gangs Are Now Through the Front Door: What the SonicWall SMA1000 VPN Attacks Mean for Dental Practices

The post When the Tool That Manages Your Network Gets Hacked: The N-able N-central Breach and What It Means for Dental Practices appeared first on Compudent Systems.