Hawaii Family Dental disclosed that on July 20, 2026 it detected suspicious activity and determined that an unauthorized individual had used a compromised account to access patient information over roughly a 24-hour window. The long-running ransomware group Qilin — known for stealing data and then threatening to leak it unless paid — has since claimed the attack and posted a sample of the stolen files. For a practice reading this in the GTA or anywhere in Ontario, that is the version of a breach that should keep you up at night, because it started at the one place you can actually do something about.

What was exposed

According to the practice’s notice and its report to regulators, the accessed information included patient names, dates of birth, phone numbers, email addresses, mailing addresses, dental insurance details, and some medical and dental treatment information. Notably, the group has said no Social Security numbers or financial account details were involved, which may limit the fallout.

But do not let the absence of a credit-card number lull you. A date of birth paired with an address, a phone number, an insurer, and a note about the care someone is receiving is exactly the raw material for convincing, targeted fraud — and under HIPAA and Ontario’s PHIPA, treatment information is protected health information whether or not a bank account rode along with it. Its exposure is what triggers notification duties, investigations, and the very real cost of making it right.

The detail that matters: it started with one login

Strip away the ransomware-gang branding and the story is mundane, which is precisely why it is instructive. An account — a legitimate username and password that belonged in the environment — ended up in the wrong hands, and that was enough to walk into the systems holding patient records. There was no dramatic breaking-down of a firewall. Someone knocked using a key that was supposed to be yours.

Accounts fall into attacker hands in a handful of ordinary ways: a password reused from a site that was itself breached, a convincing phishing page that harvests the login, or malware that quietly lifts credentials and even active session tokens off a machine. We have written before about how infostealers can grab a live session cookie and stroll past multi-factor authentication entirely — a reminder that “we have MFA” is a strong start, not a finished sentence.

Why a single account can equal the whole practice

The damage a compromised login can do is decided long before the theft, by one question: how many doors was that account allowed to open? In a lot of small practices, the honest answer is “most of them.” Everyone shares a handful of logins, the front desk account can reach the same data as the office manager, and old staff accounts are never switched off. In that setup, one stolen credential is a master key.

The principle that limits this is called least privilege: each account can reach only what that role genuinely needs, and nothing more. When privileges are tight, a compromised front-desk login is a contained problem instead of a practice-wide catastrophe. When they are loose, the attacker inherits everything the account can touch — which, for patient data, is the ballgame.

The uncomfortable part: you cannot outsource this one

When a breach happens at a supplier — like the McKesson incident that swept up practices through a vendor’s systems — there is a grim kind of comfort in it: the failure was someone else’s, and your options were mostly to react. An account compromise inside your own four walls offers no such alibi. The login was yours to protect, the privileges were yours to scope, and the monitoring that might have caught it sooner was yours to set up. That is uncomfortable — and it is also good news, because it means this is a risk you can materially reduce with decisions entirely within your control.

Exactly what to check this week

1. Turn on multi-factor authentication everywhere it will go. Practice-management software, email, remote access, the patient database, cloud backups — every account that can reach patient data. MFA is the single change that most reliably turns a stolen password into a failed login. It is not perfect, but it defeats the overwhelming majority of credential attacks.
2. Kill shared logins and enforce least privilege. Give each staff member their own account, scoped to what their role actually needs. Shared credentials make it impossible to know who did what — and hand an attacker one key that opens every door.
3. Deprovision the moment someone leaves. Dormant accounts of former employees and departed contractors are a favourite way in. Build “disable every login, same day” into your offboarding, and audit the current user list for names that no longer belong.
4. Make sure someone would actually notice. Hawaii Family Dental detected the intrusion the next day; many practices would not notice for months. Turn on login and access alerting where your systems support it — logins from unusual locations or at odd hours, and unexpected bursts of record access — so an anomaly reaches a human quickly.
5. Use unique passwords and a password manager. Reuse is what lets a breach at some unrelated website become a breach at your practice. A password manager makes long, unique passwords for every account the path of least resistance rather than a chore.
6. Have a plan for the bad day. Even a well-run practice can be hit. Knowing in advance how you would investigate, contain, notify, and keep seeing patients is the difference between a controlled response and a scramble — the same reasoning behind having a downtime and business-continuity plan ready before you need it.

The habit underneath all of it

Qilin, the group claiming this attack, does not hand-pick prestigious targets. Like most of today’s ransomware operators, it hunts for whatever is easy — smaller organizations, outdated systems, loose access — which quietly demolishes the old comfort that a modest practice is too small to bother with. You are not too small; you are, to an opportunist, potentially just easy. The practices that ride this out are not the ones with the biggest security budget. They are the ones where every login has an owner, MFA is on, privileges are tight, and someone is watching.

Where Compudent fits

Most dental offices do not have someone whose job is to audit who can log into what, confirm MFA is switched on across every system that touches patient data, and make sure a strange login at 2 a.m. actually reaches a person. That is the gap we close. Compudent Systems helps dental and medical practices across the GTA and Ontario lock down accounts and access — enforcing multi-factor authentication, scoping permissions to the principle of least privilege, cleaning up dormant and shared logins, and putting monitoring in place so an intrusion is caught in hours, not months. If you are not certain who has access to your patient data today, or whether MFA is truly on everywhere it should be, reach out to Compudent for a quick account-security assessment. It is a short conversation now, or a notification letter to 45,000 patients later.

Sources & further reading:

• Qilin claims 40k data breach at Hawaii Dental Group
• Hawaii Family Dental – Notice of Data Security Incident

Related Reading

• Critical ADT Data Breach Exposes 5.5 Million Customers: Essential Security Lessons for Dental Practices
• 9 Dental Data Breaches Already in 2026: What the DentaQuest and Absolute Dental Attacks Teach Every Practice
• California Dental Practice Suffers Major Data Breach: HIPAA Compliance Under Scrutiny

The post One Compromised Account, 45,853 Patients: The Hawaii Family Dental Breach and the Weak Link You Actually Control appeared first on Compudent Systems.

If your dental practice website was designed in WordPress — and a large share of small-practice sites are — there is a good chance Elementor is what your designer used to build it. That makes this your problem to confirm, not just an industry headline.

What the flaw actually does

The vulnerability is a cross-site request forgery, or CSRF. Unlike last week’s core flaw, which needed no interaction at all, this one has a single prerequisite: a logged-in administrator has to open a link the attacker controls. The attacker sends that link — in an email, a comment, a message, a page — and if an admin clicks it while still signed in to the site, their own authenticated browser session is quietly used to submit a request the admin never intended. In this case, that forged request tells the site to create a new administrator account under the attacker’s control.

The reason it works is that the vulnerable code accepted the action without properly verifying that the request genuinely came from the admin’s own click inside the dashboard. CSRF attacks abuse exactly this: the trust a site already extends to whoever is logged in. Once a second admin account exists, the attacker no longer needs the trick — they simply log in and own the site outright.

Why this is a dental-practice problem, not just a tech one

It is easy to dismiss the marketing website as “just the brochure.” But a website an attacker fully controls is a liability that reaches your patients and your compliance obligations:

• Harm aimed at your patients. A hijacked site can be rewired to serve malware, fake booking pages, or scam redirects to the very people who trust your name — patients checking your hours or requesting an appointment.
• Theft of the data your forms collect. Contact forms, appointment requests, and new-patient intake widgets routinely capture names, phone numbers, emails, and the reason someone is seeking care. Depending on what you gather, that can be protected health information — and its exposure can trigger notification duties under HIPAA and PHIPA.
• Reputation and search damage. Compromised sites are commonly stuffed with spam or malicious links, which search engines flag — turning your best marketing asset into a warning label.
• A foothold for more. Full control of your site’s server environment is a launch point for probing anything else that shares it.

The detail that makes this one different: it targets your people

Because the trigger is a click by a logged-in administrator, this flaw sits at the intersection of a software problem and a human one. The attacker’s real target is whoever administers your site: your web designer, your marketing agency, or the front-desk person who was handed the login. That is the same lesson we raised when malware started targeting the tablets and phones your team uses every day — the endpoint and the person operating it are part of your attack surface. A patched plugin protects you against this specific bug; a team that pauses before clicking protects you against the next one.

Exactly what to do this week

1. Update Elementor to 4.3.2 or later. This is the fix. If your site runs Elementor 4.3.0 or 4.3.1, treat it as urgent. If you are on an older 4.x release, update to the current version anyway. Sites with automatic plugin updates enabled may already be patched — verify it rather than assume it.
2. Review your administrator accounts. Log in and look at the list of users with the Administrator role. Delete any account you do not recognize, and confirm every legitimate admin still needs that level of access. Fewer admins means a smaller target.
3. Confirm who actually owns patching your site. Is it your web designer, an agency, your IT provider, or nobody? A site with an unclear owner is a site that does not get patched. Assign a named owner for updates and account reviews.
4. Reinforce click discipline for your site’s admins. Because this attack rides on a click, the handful of people with dashboard access should treat unexpected links with the same caution you would want for any account that touches patient data. When in doubt, do not click — and never stay logged in to the site admin in a browser you also use for casual email and links.

The bigger habit this should reinforce

Two critical website flaws in as many weeks is not a coincidence — it is the normal weather now. WordPress and its plugin ecosystem power an enormous share of small-business sites, which makes them a constant, automated target. The practices that ride this out are not the ones with the fanciest website; they are the ones that keep software current, know which plugins they run, limit who has admin access, and have a named owner for each of it. Those same habits are what keep a five-alarm advisory from becoming a downtime-and-recovery scramble later.

Where Compudent fits

Most dental offices do not have someone whose job is to notice an Elementor advisory on a Thursday and confirm the practice site was patched before attackers went looking. That is the gap we close. Compudent Systems helps dental and medical practices across the GTA and Ontario inventory the systems that touch patient data — websites and their plugins included — keep them patched, review who has access, and make sure someone actually owns each piece. If you are not certain whether your practice website runs Elementor, which version it is on, or who has an admin login, reach out to Compudent for a quick assessment. It is a short conversation now, or a breach-notification letter later.

Sources & further reading:

• Elementor CSRF Flaw Lets Attackers Take Over Sites After Admin Clicks Crafted Link
• CVE-2026-62062: Critical Elementor CSRF Flaw Enables WordPress Admin Takeover

Related Reading

• Hacked in Five Hours: The Critical WordPress Flaw (CVE-2026-87902) Your Practice Website Needs Patched Today
• Security Alert: “wp2shell” (CVE-2026-63030) Is a Critical WordPress Core Flaw — Patch Your Practice Website Now
• Your Practice Website Is Part of Your Attack Surface: Hackers Are Forging Logins Into WordPress Right Now

The post One Click and You Have a New Admin: The Elementor Flaw (CVE-2026-62062) Threatening Dental Practice Websites appeared first on Compudent Systems.

The alarming part isn’t just the severity. It’s the speed. Security firm Patchstack recorded the first malicious requests at 17:44 UTC the same day — less than five hours after the fix was published. Within a day, attack traffic had jumped roughly tenfold and moved from simply hunting for vulnerable sites to actively dropping code onto them. If your dental practice runs a WordPress website — and most do — this is a this-week problem, not a someday problem.

What the flaw actually does

The bug lives in how WordPress resolves page templates. In plain terms, a function that is supposed to load a template file from inside your theme can be tricked into loading a different, attacker-chosen .php file that already exists on the server. If the attacker can point that mechanism at the right file, they can turn “display a web page” into “execute a command.”

Discovered by security researcher Robert Ressl, the vulnerability doesn’t hit every single site automatically — remote code execution requires a specific combination: an active theme with a top-level folder whose name starts with page- (for example, page-templates), and a readable local PHP file the attacker can abuse. The official advisory points to pearcmd.php as the classic example when PHP’s register_argc_argv setting is switched on. That sounds obscure until you learn where those conditions are common.

Why ordinary practice websites are squarely in the blast radius

Here is the line that should get a practice owner’s attention: WordPress notes that the official PHP image for Docker is affected, and so is the default cPanel configuration when a PHP version older than 8.5 is used. cPanel is the control panel behind a huge share of small-business shared hosting — exactly the kind of budget hosting a dental office’s marketing site often sits on, frequently running a PHP version that is a release or two behind. In other words, the risky configuration isn’t exotic. For many practices, it’s the default they were handed and never touched.

This is the recurring lesson we keep coming back to: your website is not separate from your security posture. It is part of your attack surface. We made that case earlier this year when attackers were forging logins straight into WordPress, and again when a separate critical Core flaw, “wp2shell,” gave attackers code execution. CVE-2026-87902 is a new, distinct vulnerability — but the pattern is identical, and so is the fix discipline.

What a compromise would cost a dental practice

It is tempting to shrug off the marketing site as “just the brochure.” But once an attacker can run code on the server behind it, the damage is real and often reportable:

• Harm to your patients directly. A compromised site can be quietly rigged to serve malware or scam pages to the very people who trust your name — existing patients looking up your hours or booking an appointment.
• Theft of the data your forms collect. Contact forms, appointment-request forms, and new-patient intake widgets routinely capture names, phone numbers, email addresses, and the reason someone is seeking care. Depending on what you collect, that can be protected health information — and its exposure can trigger notification obligations under HIPAA and PHIPA.
• Reputation and search damage. Sites hijacked this way are commonly stuffed with spam or malicious redirects, which search engines flag — turning your top marketing asset into a warning label.
• A foothold. Code execution on your hosting is a launch point for attackers to probe further into anything else that shares that environment.

The observed attacks are already writing files with tell-tale names like wp-pear-rce-flag.php, poc87902.php, and randomized luci_ or zeta_ PHP files into locations such as /tmp and /var/tmp. Some payloads merely flag a host as exploitable; others plant a short snippet that runs a shell command whenever it is accessed.

Exactly what to do this week

The good news is that the remedy is straightforward and mostly a matter of confirming it happened.

1. Update WordPress to 7.1.2. That release fixes the flaw. Because the severity is critical, WordPress backported the fix down every branch to 4.7, so older-but-maintained sites have a patch too. (Anything before 4.6 will not get a fix — if that’s you, an upgrade is overdue for many reasons.) If your site has automatic core updates enabled, this may already be done; verify it rather than assume it.
2. Check your PHP version. If your host runs PHP older than 8.5 on a default cPanel setup, you are in the configuration WordPress specifically called out. Ask your host to move you to a current, supported PHP release — a good idea independent of this bug.
3. Confirm who actually owns patching your site. Is it your web designer, a marketing agency, your IT provider, or nobody? A site with an unclear owner is a site that doesn’t get patched. This is the same discipline behind knowing every piece of software you run — the theme we raised with the FastJson zero-day and building a real software inventory.
4. Look for signs of compromise. Ask whoever manages the site to check for unexpected PHP files in /tmp and /var/tmp and in the web root, and to review access logs for the exploitation pattern. If anything looks off, treat it as a potential breach of any data the site collected.

The bigger habit this should reinforce

CVE-2026-87902 is a textbook case of why speed matters now. The window between “a fix exists” and “criminals are weaponizing it” was under five hours — and the exploitation was fully automated, spraying the internet rather than hand-picking targets. A small dental practice doesn’t get overlooked in that model; it gets swept up in it.

That reality rewards two boring habits: keeping software current without waiting for a nudge, and knowing what you run and who is responsible for each piece of it. Auto-updates, a maintained hosting plan on a supported PHP version, and a named owner for the website are not luxuries — they are what turns a five-alarm headline into a non-event you patched before lunch.

Where Compudent fits

Most dental offices don’t have someone whose job is to watch for a WordPress advisory on a Tuesday afternoon and confirm the practice site got patched before attackers arrived. That’s the gap we close. Compudent Systems helps dental and medical practices across the GTA and Ontario inventory the systems that touch patient data — websites included — keep them patched, watch for exploitation of flaws like this one, and make sure someone actually owns each piece. If you’re not certain whether your practice website is running the fixed version of WordPress, or which PHP version your host serves, reach out to Compudent for a quick assessment. It’s a short conversation now, or a breach-notification letter later.

Sources & further reading:

• Hackers start exploiting critical WordPress flaw for code execution
• WordPress security advisory GHSA-7hp8-65ch-5whp (CVE-2026-87902)
• Patchstack: attackers started probing WordPress sites hours after the patch

Related Reading

• Security Alert: “wp2shell” (CVE-2026-63030) Is a Critical WordPress Core Flaw — Patch Your Practice Website Now
• One Click and You Have a New Admin: The Elementor Flaw (CVE-2026-62062) Threatening Dental Practice Websites
• Your Practice Website Is Part of Your Attack Surface: Hackers Are Forging Logins Into WordPress Right Now

The post Hacked in Five Hours: The Critical WordPress Flaw (CVE-2026-87902) Your Practice Website Needs Patched Today appeared first on Compudent Systems.

This is not a breach alert, and there is nothing to patch this morning. It is a shift in what an ordinary general practice can buy – and every time a new class of tool becomes mainstream, it quietly becomes an IT and data question long before anyone in the operatory notices. Here is what the launch actually means, and the handful of things worth settling before your scans start leaving the building.

What actually changed

Pearl is not new to this. Its two-dimensional analysis tool has been reading intraoral X-rays chairside for some time. What is new is that the company has extended that FDA 510(k)-cleared imaging AI into cone-beam scans and packaged it for general dentistry rather than only for radiologists and large groups. In the same window, industry watchers counted five separate FDA clearances for 3D dental AI – a sign that regulators and vendors alike now treat AI review of a CBCT as a normal clinical tool, not an experiment.

The practical effect is that the wait-list of practices thinking about AI is being converted into buyers. The ADA Health Policy Institute’s Q2 2026 read on the profession found that 43.3% of dentists reported using AI for at least one task, with another 26.4% saying they do not yet but plan to – and imaging and diagnostics sat near the top of both lists. Cone-beam review moving within reach of the general dentist is exactly the kind of step that turns a “planning to” into a purchase order.

Why a clinical tool lands on the IT desk

Because AI does not read a scan by magic. Modern diagnostic-assist tools are overwhelmingly cloud services: the imaging system hands the volume off across your network to the vendor’s servers, the model does its work there, and a result comes back. That is a sensible architecture – the compute is heavy and centralising the model keeps it current – but it means a full patient CBCT, one of the richest pieces of personal health information you hold, now travels off your premises as a matter of routine. The clinical question is what the AI finds. The IT question is where the scan goes to be read, and whether that path keeps the data under your control.

This is the same due diligence we applied when Medit’s AuraVue put Overjet’s AI onto one screen with your scans and X-rays, and it rests on the same foundation as keeping your imaging server and PACS off the open internet. A tool that reaches into your imaging pipeline is only as safe as the pipeline it joins.

The PHIPA question you have to answer first

For an Ontario practice, sending patient imaging to a third party for processing is not a grey area – it is a health-information custodian handing personal health information to a service provider, and PHIPA holds you responsible for what happens to it. That is workable and common, but it is conditional. Before the first scan is uploaded, you want three things pinned down in writing: where the data is stored and processed (a Canadian or U.S. data-residency answer matters to some patients and some contracts), whether your scans are used to train the vendor’s models and your ability to opt out, and a signed agreement – a written data-processing or business-associate arrangement that names the vendor’s obligations. These are the same instincts that apply whenever a free or consumer-grade cloud service creeps into clinical use, a trap we walked through with teledentistry over general-purpose video tools. “It just works in the browser” is not a compliance posture.

Four questions to ask before you switch it on

You do not need to become an AI expert to adopt one responsibly. Make these part of the evaluation and treat a vague answer as the answer:

1. “Where is our data processed and stored, and for how long?” Get data residency and a retention period in writing, not a shrug about “the cloud.”
2. “Are our patient scans used to train your models, and can we opt out?” Both answers are defensible – but you must know which one you are agreeing to.
3. “What is the FDA clearance, and what is the tool cleared to do?” A 510(k)-cleared diagnostic-assist is a second reader, not an autonomous diagnostician. Know the boundary so your team uses it inside its lane.
4. “How does this connect to our imaging system and network?” Cloud round-trip, on-prem appliance or a plug-in to your existing software – each has a different security and reliability profile, and your IT partner should size it up before go-live.

A second opinion, not a replacement

The name is honest about the role. A tool like this earns its keep by catching the thing a tired clinician glances past at the end of a long day, and by giving a general dentist more confidence in reading a volume that used to be shipped out for interpretation. But the clinician still owns the diagnosis. The most important workflow decision is a documentation one: when the AI flags something and the dentist agrees or overrides, the chart should reflect that a human made the call. That habit protects the patient, protects the practice, and keeps the tool firmly in the assist role the FDA cleared it for.

It also pairs with the buying discipline we have argued for all along – the same posture behind treating imaging-device cybersecurity as a purchasing checklist. New capability is worth having; it is worth having on your terms.

What to do this week

Nothing here is urgent, and that is the point – it is far cheaper to decide how AI enters your practice than to discover after the fact that patient scans have been leaving it under terms nobody read. If a diagnostic-assist tool is on your radar, add the four questions above to the evaluation. If one is already in use somewhere in the practice, take ten minutes to confirm the data path and the agreement behind it.

At Compudent Systems we help dental practices across the GTA and Ontario vet imaging and AI software before it is adopted, map how patient data moves on and off the network, and put the segmentation, agreements and safeguards in place to keep it compliant and secure. If you are weighing an AI imaging tool – or want to know exactly where your scans already go – contact Compudent Systems for an assessment. The best time to set the terms is before the first scan leaves the building.

Sources & further reading:

• Next Dental Lab – 2026 Dental Software News: AI Integration Trends
• Oral Health Group – Five FDA clearances for 3D dental AI as Pearl launches CBCT software for general dentists
• ADA Health Policy Institute – The State of the U.S. Dental Economy, Q2 2026

Related Reading

• One Screen for Scans and X-Rays: What Medit’s AuraVue With Overjet AI Means for Your Dental Practice
• How Dental AI Tools Connect to Your Imaging Software: TWAIN, DICOM, API, and PMS Bridges
• Can Your Dental Practice Use ChatGPT Without Breaking HIPAA and PHIPA? A 2026 Compliance Guide

The post AI That Reads Your CBCT Scans Just Arrived for General Dentists: What Pearl’s Second Opinion 3D Means for Your Practice appeared first on Compudent Systems.

It is federal legislation, not yet law, and its path through Congress is uncertain. But for a dental practice, the direction of travel matters more than the odds of any single bill. Regulators and lawmakers have concluded that asking nicely hasn’t worked, and the requirements being drafted are a preview of the standard every practice will eventually be held to. Here is what HISAA would demand, and what a small office should take from it right now.

Why lawmakers say voluntary standards failed

The argument behind the bill is a numbers story. When HISAA was first introduced in 2024, 394 large hacking-related breaches had been reported to the HHS Office for Civil Rights, exposing the protected health information of roughly 43 million Americans. Two years later, the year-to-date figures the senators cite are worse: 426 hacking-related breaches and about 73 million individuals affected — a jump of roughly 70% in people exposed.

In 2024, OCR published two tiers of voluntary cybersecurity performance goals (Essential and Enhanced) for the health sector, and predicted at the time that voluntary measures alone wouldn’t move the needle. The senators frame these attacks bluntly as “entirely preventable” results of “lax cybersecurity practices by health care providers and their business partners.” HISAA is their answer: make the floor mandatory. This is the same regulatory shift already visible elsewhere — the FDA, for example, has moved from suggesting to requiring imaging devices to be cyber-secure by design.

What HISAA would actually require

The 2026 bill is largely unchanged from the 2024 version, with the timeline shifted forward. Its core requirements would apply to covered entities and their business associates — language that reaches well beyond hospitals and into ordinary practices and the vendors they rely on:

• Mandatory minimum cybersecurity standards established, enforced, and updated by HHS at least every two years, with heightened requirements for “systemically important” entities.
• Continuity and recovery plans for technical failures, disruptive cyberattacks, and natural disasters — plus stress tests to prove you can actually recover essential functions, not just claim you can.
• Annual risk analyses, including a specific assessment of the risk you inherit through your business associates.
• Written annual attestations signed by the CEO and the chief information security officer, formally certifying the organization meets the applicable standards.
• Independent audits of security measures, plus annual HHS audits of at least 20 regulated entities, focused on those of systemic importance.
• Much larger penalties. The bill would lift the current caps, setting escalating minimums — from $500 for a no-knowledge violation up to $250,000 for uncorrected willful neglect.

To soften the blow for smaller and rural providers, HISAA pairs the mandates with money: a proposed $1.3 billion investment, including $800 million in up-front funding for hospitals in rural and underserved communities to adopt the essential goals, and $500 million in incentives for adopting the enhanced ones.

What this means for a dental practice

It is tempting to read “systemically important entities” and “annual HHS audits of at least 20 organizations” and conclude this is a big-hospital problem. That would be a mistake for two reasons.

First, the minimum standards and the business-associate language apply broadly — not only to the twenty organizations HHS audits each year. A dental practice is a covered entity, and your practice-management host, billing service, and imaging-software vendor are business associates. When a bill makes you responsible for assessing the risk your vendors carry, the collapse of an outsourced partner becomes your compliance problem, not just theirs. Practices learned that lesson the hard way when a billing vendor like eAssist landed on a ransomware leak site, dragging the patient data of the practices it served along with it.

Second, even if HISAA never passes in its current form, its requirements are a checklist of where the bar is heading. Annual risk analyses, tested recovery plans, vendor risk assessment, and leadership accountability are exactly what the delayed HIPAA Security Rule update also points toward. The specifics of the breach headlines change, but the lessons from this year’s dental data breaches keep repeating: the practices that get hurt are the ones treating security as a someday project.

The four things worth doing before any law forces you

You don’t need to wait for a final vote to be in a strong position. Everything HISAA would mandate is defensible, sensible practice today — and doing it now is far cheaper than doing it under an audit deadline:

1. Run a real annual risk analysis. Not a checkbox — an honest inventory of where protected health information lives, who can reach it, and where it is exposed. This is already a HIPAA expectation; HISAA would simply put teeth behind it.
2. Write down your vendors and their risk. List every business associate that touches patient data, confirm you have current agreements, and ask each one what happens to your data if they are breached. Their weakness is your liability.
3. Have a recovery plan you have actually tested. A downtime and business-continuity plan only counts if you’ve rehearsed it. HISAA’s “stress test” language is a reminder that an untested backup is a hope, not a plan.
4. Make one person accountable. The bill’s CEO/CISO attestation reflects a simple truth: security that is “everyone’s job” is usually no one’s. In a small practice, name an owner and give them a partner who does this for a living.

The trend line is the real story

Whether HISAA advances this session, stalls, or returns again in two years, the message from Washington is consistent and getting louder: voluntary is over. Between rising breach numbers, the FDA’s device mandates, the pending HIPAA Security Rule changes, and now a bill that would attach personal executive sign-off and six-figure penalties to healthcare security, the era of good intentions is closing. Practices that build the habits now — documented risk analyses, tested recovery, vendor oversight, clear accountability — won’t be scrambling when the floor becomes mandatory.

Where Compudent fits

Turning a dense piece of proposed legislation into a short list of things your practice should actually do is exactly the kind of translation we handle every day. Compudent Systems works with dental and medical practices across the GTA and Ontario to run genuine risk analyses, keep business-associate agreements current, build and test recovery plans, and put a steady hand on security so compliance isn’t a fire drill. If you’d like to know how your practice measures against where the standards are heading — before anyone requires you to — reach out to Compudent for an assessment. Getting ahead of the rules is always cheaper than catching up to them.

Sources & further reading:

• Democratic Senators Reintroduce the Health Infrastructure Security and Accountability Act
• Warner, Wyden Introduce Bill to Strengthen Cybersecurity Standards for American Health Care System

Related Reading

• 2026 HIPAA Security Rule Changes: What Dental Practices Need to Know
• New HIPAA Security Rule Requirements: Mandatory Vulnerability Scanning and Penetration Testing for Dental Practices
• New HIPAA Privacy Rule Update: What Dental Practices Must Do Before the February 16 Deadline

The post Congress Wants Mandatory Cybersecurity Standards for Healthcare: What HISAA Would Mean for Your Dental Practice appeared first on Compudent Systems.

This is the kind of problem that looks like a dozen small issues at once: charts won’t load, the practice management system times out, imaging can’t reach the server. Underneath, it’s one cause. Here’s what is happening and how to handle it without opening a hole in your defenses.

What Always On VPN actually does for your practice

Always On VPN is a Windows feature that automatically establishes a secure, encrypted tunnel between a remote computer and your practice network. Unlike an old-fashioned VPN client someone has to remember to launch, it connects on its own the moment the device has internet — which is exactly why it’s popular for remote administrators, a bookkeeper who works from home, or a second location sharing your central server.

That convenience is also why an outage is easy to miss at first. Nobody “forgot to connect.” The tunnel simply fails to form, and every service that depends on the office network fails with it. For a practice handling patient records, that tunnel is not a nicety — it is the encrypted boundary keeping protected health information off the open internet.

What the September updates break

Microsoft has acknowledged that the September cumulative updates for Windows can cause Always On VPN connections to fail after installation. Affected devices install the update normally, then can no longer bring up the VPN tunnel — often with a generic connection error rather than a clear “this update did it” message. Everything else on the machine works, which is what sends people chasing the wrong culprit.

This follows a familiar pattern. Earlier the same month, a separate Windows Server update was breaking Remote Desktop sessions for practices that rely on RDS. When a monthly patch collides with the very tools you use to reach the office remotely, the fix is rarely to stop patching — it’s to patch deliberately.

How to confirm this is your problem

Before you change anything, verify the pattern. A few quick checks separate an update-induced VPN failure from an unrelated network hiccup:

• Timing: Did the failures start right after the September updates installed? Check Windows Update history on an affected device and note the date it applied.
• Scope: Is it only remote or branch users on Always On VPN who are affected, while in-office computers work fine? That points squarely at the tunnel, not the server.
• Consistency: Does the tunnel fail to establish on every attempt, on multiple devices that all received the same update? One machine is a coincidence; several is a pattern.
• Everything-else-works test: Can the affected device browse the web and reach non-VPN resources normally? If yes, the problem is the tunnel, not connectivity.

Document what you find. Knowing which specific update is installed is what lets your IT provider match it to Microsoft’s guidance and choose the right remedy.

Restoring access — the safe way

The dangerous shortcut here is obvious and tempting: turn the VPN off and let people connect “just for today” some other way. Don’t. Exposing a practice-management server or opening remote access without the encrypted tunnel is exactly the kind of gap ransomware crews and credential thieves look for. A one-day workaround becomes a permanent liability.

Instead, work through the options in order of preference:

1. Apply Microsoft’s targeted fix. When Microsoft acknowledges an update-caused regression like this, it typically ships an out-of-band fix or a Known Issue Rollback that resolves it without removing your security patches. This is the cleanest path — you keep the protection and regain the tunnel.
2. Roll back only if you must, and briefly. Uninstalling the offending cumulative update can restore VPN connectivity, but it also strips out that month’s security fixes. Treat rollback as a short bridge, not a destination, and reapply patches as soon as the corrected update is available.
3. Use a secured alternate path in the meantime. If a user genuinely cannot work, route them through another already-hardened, encrypted method rather than a bare connection — and log it, so nothing is left open by accident.

Whatever route you take, this is a good moment to confirm your downtime and business-continuity plan actually covers “remote access is down.” A practice that can keep seeing patients on paper for a few hours is a practice that never has to make a risky security compromise under pressure.

The bigger lesson: patch on purpose, not on autopilot

Two remote-access-breaking updates in a single month is a reminder that fully automatic, immediate patching has a cost. The answer isn’t to delay security updates — unpatched systems are how most breaches start, and this same month’s Patch Tuesday closed hundreds of vulnerabilities, some already being exploited. The answer is a small buffer: let critical updates land on a test or pilot machine first, watch for exactly this kind of regression for a day or two, then roll out to the rest of the practice.

For a busy office, that discipline is hard to maintain in-house. It usually falls to whoever has a spare moment — which means it doesn’t happen consistently, and you find out about a broken tunnel from a frustrated staff member instead of a test bench.

Where Compudent fits

Managing Windows updates so they protect your practice without knocking out remote access is exactly the kind of routine that benefits from a steady hand. Compudent Systems works with dental and medical practices across the GTA and Ontario to keep patching deliberate, remote access secure, and downtime rare. If your Always On VPN has gone quiet this week — or you’d simply like update rollouts handled so surprises like this never reach your front desk — reach out to Compudent for an assessment. Secure remote access should be something you never have to think about.

Sources & further reading:

• Microsoft: September Windows updates break Always On VPN connections

Related Reading

• The Patch That Locks Out the Front Desk: September’s Windows Server Update Is Breaking Remote Desktop
• A Single Packet, No Password Required: The Actively Exploited Windows IKE Flaw (CVE-2026-33824) and Your Practice
• The Gateway That Lets Your Team In Can Let Attackers In Too: Critical Check Point VPN Flaws (CVE-2026-85102 / 85103) and Your Practice

The post September’s Windows Updates Are Breaking Always On VPN: What Practices With Remote Access Need to Check Now appeared first on Compudent Systems.

This is not a breach alert and there is nothing to patch this morning. It is something more useful: a durable rule you can turn into leverage at the exact moment you have the most of it – before you sign the purchase order.

What the law actually requires

In December 2022, Congress added Section 524B to the Food, Drug, and Cosmetic Act, and it took effect in March 2023. It applies to “cyber devices” – broadly, any device that includes software and can connect to the internet or a network, which covers essentially every modern digital imaging system in a dental office. To win FDA clearance, the maker must now do several things and document them in the premarket submission:

• Design, develop and maintain the device to be reasonably cyber-secure – so-called secure by design, rather than security added after the fact.
• Provide a plan to monitor, identify and address post-market vulnerabilities, including issuing patches on a reasonable cadence and out-of-cycle for critical flaws.
• Publish a coordinated vulnerability disclosure process, so researchers have a legitimate way to report problems.
• Provide a Software Bill of Materials (SBOM) – a machine-readable inventory of the software components inside the device, including the open-source libraries it depends on.

The FDA has been willing to refuse submissions that fail to include this material since late 2023. In 2026 the guidance was refreshed to line up with the agency’s new Quality Management System Regulation (QMSR), which folds these expectations into the manufacturer’s overall quality system. The headline for a buyer is unchanged and worth repeating: the SBOM and cybersecurity requirements did not loosen. They are the baseline now.

Why a dental practice should care about a manufacturing rule

Because the burden of a device’s flaws does not stay with the manufacturer. It lands on the practice that owns the device, holds the patient records it touches, and answers to patients and to PHIPA when something goes wrong. We have written before about how imaging hardware becomes a security question the moment it joins your network – from where a sensor was made and what it quietly talks to, to the awkward reality of keeping an older scanner or CBCT running safely after the vendor stops patching it.

Section 524B attacks that problem at the source. A device built to the standard is one whose maker has committed, on the record, to shipping patches and telling you about vulnerabilities for the life of the product. A device that predates or ignores the standard is one where you are on your own. The difference between those two purchases is invisible on the spec sheet and enormous over the eight-to-ten years the equipment will sit in your operatory.

The one document that changes your leverage: the SBOM

Of everything in the rule, the SBOM is the piece a practice can use directly. Think of it as an ingredients list for the device’s software. Modern imaging systems are assembled from dozens of third-party and open-source components you never chose and cannot see – and those components are where a growing share of critical vulnerabilities live. When one of them makes the news, the first question is always the same: do we run it?

Without an SBOM, answering that means waiting on the vendor’s goodwill and hoping they respond before an attacker does. With one, you – or the IT partner who manages your network – can check in minutes whether the flawed component is inside your scanner. That is the same discipline that turned a recent scramble over a buried software flaw into a five-minute lookup for practices that knew what they were running. The SBOM is what makes “know what you run” possible for a sealed medical device.

Turn the rule into three purchasing questions

You do not need to read an FDA submission or become a compliance expert. You need to make three requests part of every imaging-equipment evaluation, and treat a vague answer as the answer:

1. “Please provide the SBOM for this device.” A vendor building to the standard has one ready. Hesitation, confusion or a promise to “look into it” tells you where cybersecurity sits on their priority list.
2. “What is your patching commitment and your end-of-support date?” Get the cadence for routine and emergency updates, and the year support ends, in writing. This is the single most valuable fact for planning, because the device will outlive its support window and you need to know when.
3. “How do I report a security problem, and how will you notify me of one?” A real coordinated-disclosure process and a defined customer-notification path separate a serious manufacturer from one that will go quiet the day a flaw surfaces.

None of this slows a purchase you were going to make anyway. It simply ensures that when two units are close on price and image quality – the situation you are usually in – the tiebreaker is the one that will cost you the least grief three years from now. It also pairs naturally with the questions you should already be asking about how a new device connects to your network, the same due diligence we applied when the FDA cleared AI that reads 3D dental scans and when a widely used imaging server flaw showed why a PACS should never face the internet.

What to do this week

Nothing here is urgent, and that is the point – it is far cheaper to build this into how you buy than to retrofit it after an incident. If you have a device purchase on the horizon, add the three questions above to your evaluation. If your existing fleet is a mystery, start a simple inventory: what each connected imaging device is, what it runs, when its support ends, and whether the vendor can supply an SBOM. That list is the foundation of every good decision that follows.

At Compudent Systems we help dental practices across the GTA and Ontario vet imaging and IT equipment before it is purchased, inventory what is already on the network, and build the segmentation and monitoring that keep it all safe for its full service life. If you have a device on order – or a fleet you have never fully mapped – contact Compudent Systems for an assessment. The best time to ask these questions is before the invoice is paid.

Sources & further reading:

• FDA – Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions
• Interlynk – FDA SBOM Requirements for Medical Devices: The Complete 2026 Guide
• Censinet – FDA Cybersecurity Guidance: Medical Device Reporting Rules

Related Reading

• Where Was Your Imaging Sensor Made, and What Is It Talking To? Device Provenance Is Now a Dental Practice Security Question
• You Can’t Patch That Old Sensor or CBCT: How to Safely Keep Legacy Imaging Devices on Your Dental Network
• One Screen for Scans and X-Rays: What Medit’s AuraVue With Overjet AI Means for Your Dental Practice

The post The FDA Now Requires Imaging Devices to Be Cyber-Secure by Design. Here Is How to Make It Your Purchasing Checklist. appeared first on Compudent Systems.

What is actually happening

FastJson is an open-source Java library – a small, free building block that programs use to convert data to and from the JSON format. It is maintained by Alibaba and is embedded inside a great many applications, particularly enterprise and Chinese-origin software. On September 2026, an offensive-security firm published a technical write-up of a serious flaw, now tracked as CVE-2026-16723, affecting FastJson versions 1.2.68 through 1.2.83. Within days, security companies ThreatBook and Imperva reported it was being actively exploited in the wild against organizations across financial services, healthcare, computing and retail – almost entirely in the United States so far, with a handful of attacks already seen in Canada and Singapore, and expected to spread.

The flaw allows remote code execution with no user interaction and no need for elevated privileges. In plain terms: an attacker can send a specially crafted piece of data to a vulnerable, internet-facing application and make it run their code – no stolen password, no employee clicking a bad link, no warning. That combination is about as bad as a vulnerability gets. Worse, at the time of writing there was no patched release for the affected 1.x branch; the guidance is to move to the maintained successor library (fastjson2) and put network and web-application-firewall protections in front of anything exposed. A flaw that is unauthenticated, already exploited, and unpatched is the trifecta that gets defenders out of their chairs.

“So is this us?” – the honest answer

We would rather give you a straight answer than manufacture alarm. For a typical dental practice, the direct exposure to this specific flaw is low and, more importantly, uncertain. FastJson is a Java component, and the mainstream systems most Canadian practices run – Dentrix, Eaglesoft, Open Dental and their kin – are generally built on Microsoft’s .NET stack, not Java. So the odds that this exact library is sitting on your operatory PC are slim.

But notice the word “uncertain,” because that is the whole point. The reason nobody can hand you a confident “no” is that components like FastJson are buried invisibly inside other software – inside a vendor’s server product, an imaging or integration server, a web application your website runs on, or a system your IT or hosting provider operates on your behalf. The reflex “we don’t use Java, so this isn’t about us” is comforting and frequently wrong, because you did not choose these components and cannot see them from the login screen. We ran into the same theme when an open-source DICOM server flaw put imaging systems at risk: the vulnerable code was open-source plumbing tucked inside the imaging stack, not a product anyone consciously “installed.”

Why healthcare being on the list matters

Attackers do not spray these exploits at random; the industries researchers named are the industries being probed right now, and healthcare is on it. That is not a coincidence. Medical and dental organizations hold exactly the data extortion crews want – names, dates of birth, health and insurance details – and they have a low tolerance for downtime, which makes them more likely to pay to get running again. A no-click, no-password flaw in an internet-facing service is the kind of front door that lets an attacker skip the phishing email entirely. When a target list includes your sector, the right response is not panic but a quick, honest look at your own attack surface.

You cannot protect what you cannot see

Here is the lesson worth keeping long after CVE-2026-16723 is patched and forgotten. Modern software is assembled, not written – a single application can pull in dozens or hundreds of third-party open-source components, each with its own flaws surfacing on its own schedule. Your ability to respond to any given alert comes down to one unglamorous capability: knowing what you actually run. A practice that keeps even a basic inventory of its software and its internet-facing services can answer “is this us?” in an afternoon. A practice that does not is left guessing every single time the news breaks – and guessing, in security, usually means hoping. The same visibility gap shows up whenever practices bolt on new tools: every one of those integration bridges between imaging software and AI or practice-management systems quietly brings its own bundle of third-party code along with it.

What to do this week

None of this requires you to become a Java expert. It requires a few sensible questions and a little bookkeeping:

• Write down what you run. Keep a simple, current list of your key software and – especially – anything that is reachable from the internet: your website, any remote-access or portal, imaging or integration servers. This one list is what turns future alerts from a scramble into a lookup.
• Ask your vendors the direct question. Email your practice-management, imaging and integration vendors and ask plainly: do any of your products include FastJson 1.x, and if so, what is your fix or mitigation plan? A vendor who answers crisply has done the work; one who cannot has told you something too.
• Ask your website and IT/hosting provider the same thing. Your public website and the environments your provider runs are the most likely places a Java component like this would live. Whoever manages them should be able to confirm they have assessed it.
• Keep internet-facing services patched and, where possible, off the open internet. The services most exposed to a flaw like this are the ones facing the public web. Anything that does not need to be internet-reachable should not be, and the rest should be patched promptly and sit behind sensible protections. This is the same discipline we urged when a flaw turned up in backup software: treat every exposed service as software that will eventually have a bug.
• File this as a rehearsal. FastJson may or may not touch you. The next component-level zero-day is a certainty. The practices that stay calm are the ones that already know what they run and have a habit of asking their vendors sharp questions.

What this means for your practice

CVE-2026-16723 is a flaw in software most dental offices will never knowingly touch, being used in attacks that specifically include healthcare. Both halves of that sentence are true, and the tension between them is the takeaway: the threat you cannot name is the one you cannot rule out. The answer is not fear – it is visibility. Know your software estate, know which of your services face the internet, and know that your vendors are watching the components buried in their own products. That awareness is also the backbone of a real business-continuity and downtime plan, because you cannot recover cleanly from a compromise in a system you did not know you had. Compudent Systems helps dental practices across the GTA and Ontario build and maintain exactly this picture – a clear inventory of software and internet-facing services, a hardened and patched attack surface, and a straight line to the vendor answers that alerts like this one demand. If you cannot say with confidence which of your systems this week’s alert does or does not touch, contact Compudent for a software-inventory and vendor-risk assessment. Knowing what you run is the cheapest security control there is – and the one too many practices skip.

Sources & further reading:

• BleepingComputer – Hackers target US firms in FastJson RCE zero-day attacks
• Imperva – Customers protected against CVE-2026-16723 critical FastJson 1.x zero-day RCE
• FearsOff – FastJson 1.2.83 RCE technical write-up

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
• A Perfect 10, No Password Required: The N-central Zero-Day (CVE-2026-86218) Your IT Provider Must Have Patched
• When the Tool That Manages Your Network Gets Hacked: The N-able N-central Breach and What It Means for Dental Practices

The post A Zero-Day Is Hitting Healthcare in Software Nobody Names: The FastJson Flaw (CVE-2026-16723) and Why You Can’t Protect Code You Don’t Know You Run appeared first on Compudent Systems.

What happened

CVE-2026-87886 is a local privilege-escalation vulnerability caused by incorrect default file permissions in Acronis’s backup add-on for the cPanel and WHM web-hosting control panels. Acronis rated it 7.8 on the CVSS scale – high severity. What pushed it onto CISA’s radar was not the score but the activity: security researchers observed limited, targeted exploitation in cPanel and WHM environments, and CISA’s listing set a federal remediation deadline of September 19, 2026. When a flaw moves from “theoretically bad” to “actively being used,” the calculus changes from patch-when-convenient to patch-now.

“Do we even run this?”

For most dental practices, honestly, the answer to this exact CVE is no – and we would rather tell you that than manufacture alarm. cPanel and WHM are web-hosting control panels: the software that runs on the server hosting a website, not the practice-management PC or the imaging workstation in the operatory. Where it can reach a dental practice is at the edges you may not think of as “yours”: the server that hosts your public practice website, and the hosting or IT provider environments that run cPanel to manage many customers at once. If your website lives on shared or managed hosting – and most do – it is worth a one-line email to whoever runs it asking whether they use the Acronis cPanel plugin and whether it has been patched. This is the same fourth-party-tool exposure we saw when a dental billing vendor’s breach dragged its client practices onto a ransomware leak site: the flaw was in someone else’s software, but the consequences flowed downhill.

Why backup software is a target in the first place

Here is the part that matters no matter which backup product you run. Backup software is, by design, one of the most privileged pieces of software in any environment. To do its job it needs deep, sweeping access – to read every file it protects and to write those files back during a restore. That is exactly the kind of access an attacker covets. And there is a second, colder reason it draws fire: modern ransomware crews hunt for backups and destroy them first. They know a practice with clean, current backups can restore and walk away without paying, so before they detonate they go looking for backup servers, repositories, and cloud credentials to delete or encrypt them. We saw this pattern spelled out in the Medusa ransomware advisory for healthcare: knock out the recovery option, and the victim’s leverage disappears. A vulnerability in the backup tool itself is a shortcut to both goals at once – privileged access and control over the one thing standing between the practice and a ransom demand.

Why “only local” is not the reassurance it sounds like

You may notice CVE-2026-87886 is a local privilege-escalation flaw, meaning an attacker needs to already be on the server to use it. That sounds comforting – and it is a genuine mitigating factor – but it is not a reason to relax. Real intrusions are built in stages. An attacker rarely walks straight into full control; they get a modest foothold first – a phished credential, a hijacked session, a separate flaw in some other service – and then chain that foothold into a privilege-escalation bug like this one to climb from “limited user” to “owns the whole machine.” A local flaw in privileged backup software is a perfect final rung on that ladder. Treating “local only” as “safe” is how a manageable foothold becomes a full compromise.

What to do this week

Whether or not the Acronis cPanel plugin is anywhere in your world, this advisory is a useful prompt to shore up backup security generally:

• Find out where backup software actually runs. Inventory it honestly – the practice server, any cloud backup agent, and the hosting environment behind your website. If you use the Acronis cPanel/WHM plugin directly, apply the vendor’s patched release now; given the active exploitation and CISA deadline, this is not one to defer.
• Ask your website host and IT provider the direct question. Do you run the affected Acronis plugin, and is it patched? A provider who can answer crisply has already done the work; one who cannot has told you something too.
• Keep at least one copy offline or immutable. Follow the 3-2-1 rule – three copies, on two kinds of media, with one kept offline or air-gapped. A backup an attacker can reach and delete over the network is a backup you cannot count on when it matters.
• Run backup agents and consoles under least privilege. Backup software does not need to be logged in as a domain administrator to do its job, and the backup console has no business facing the public internet. Reducing what the tool can touch reduces what an attacker inherits if they seize it.
• Patch backup software like the exposed service it is. It is easy to treat backup and security tools as set-and-forget infrastructure. They are software, they have flaws, and – as this week shows – they get exploited. Fold them into the same patch discipline as everything else.
• Test your restores. None of the above matters if the backups do not actually come back. A backup you have never restored from is a hope, not a plan – which is the whole point of treating your last successful test restore as the real measure of protection.

What this means for your practice

CVE-2026-87886 is a narrow flaw with a wide moral: the tools you trust most – the ones with the deepest access and the most important job – are precisely the ones attackers most want to turn against you. A backup system is only protection if it is itself protected, patched, least-privileged, partly offline, and proven by a real restore. That belongs in your broader downtime and business-continuity plan, not in a folder marked “someone set that up once.” Compudent Systems designs and manages backup for dental practices across the GTA and Ontario with exactly this threat model in mind – immutable and offline copies, hardened and least-privileged agents, patched backup software, and restores we actually test so the safety net is there on the day it is needed. If you are not certain your backups would survive an attack that came looking for them – or you would like a second set of eyes on how your data is protected – contact Compudent for a backup and security assessment. The best time to find out your safety net has a hole in it is not the morning after.

Sources & further reading:

• The Hacker News – Acronis cPanel Backup Plugin Vulnerability Exploited in Targeted Attacks
• SecurityAffairs – U.S. CISA adds Acronis Backup, Cisco ISE, and Google Pixel flaws to its Known Exploited Vulnerabilities catalog
• SC Media – Acronis backup plugin vulnerability allows privilege escalation

Related Reading

• Ransomware Gangs Are Now Through the Front Door: What the SonicWall SMA1000 VPN Attacks Mean for Dental Practices
• Two Dental Groups on Leak Sites in One Week: What It Means When Your Practice’s Name Appears on a Ransomware Blog
• Your Backups Are Only as Good as Your Last Test Restore: A Dental Practice Reality Check

The post The Tool That Protects Your Data Is Now a Target: The Actively-Exploited Acronis Backup Flaw (CVE-2026-87886) and Why Backup Software Needs Guarding Too appeared first on Compudent Systems.

What happened

N-central is a remote monitoring and management (RMM) platform – the software many managed service providers (MSPs) use to keep an eye on, update, and remotely fix all of their clients’ computers from one console. CVE-2026-86218 is a pre-authentication remote code execution flaw in that platform. In plain terms: an attacker who can reach a vulnerable N-central server over the network can make it run their code without logging in and without any user doing anything. N-able rated it 10.0 on the CVSS scale – the maximum – and confirmed active exploitation. It affects on-premises N-central installations before version 2026.3.1.14, which is the fixed release. The Shadowserver Foundation counted roughly 1,500 internet-facing N-central servers, mostly across the US and Europe, when the flaw was disclosed – each one a high-value target.

Why an RMM flaw is a skeleton key into a clinic

An RMM console is not just another server. It is, by design, the one machine that can reach every device it manages – to push software, run scripts, and open remote sessions across many networks at once. That is enormously useful when a trusted technician is at the keyboard. It is catastrophic when an attacker is. Seize the console and you inherit its reach: potentially the workstations at the front desk, the imaging server in the back, and the practice-management database in between. This is the same lesson we drew from the N-central authentication-bypass flaw back in August – the difference is that the earlier bug still had to get past a login, while this one skips the login entirely. It is a worse version of the same skeleton key.

“But we don’t run N-central”

Almost no dental practice does – and that is precisely the trap. You very likely do not operate an N-central server yourself, so it is tempting to file this under “not our problem.” But the practices at risk are mostly exposed through their IT provider, not directly. If the company that manages your computers runs N-central to do it, then their console is a door into your network, and a flaw in their software becomes your exposure even though you did nothing wrong. Security people call this fourth-party risk: not your vendor, but your vendor’s tools. We have watched this pattern play out through a supplier before – it is exactly what happened when a dental billing company ended up on a ransomware leak site and the practices that used it were dragged along. The RMM version is more dangerous, because an RMM has hands-on control of your machines, not just a copy of your data.

Why this one earns the perfect 10

Not every “critical” advisory deserves the same alarm. This one does, for three compounding reasons. It is pre-authentication, so the usual last line of defence – a login the attacker has to defeat – is not even in the way. It is remote code execution, the most complete form of compromise, letting the attacker run whatever they want on the server. And it is already being exploited, which turns “patch when convenient” into “patch now.” N-able also has recent history here: earlier N-central flaws (CVE-2025-8875 and CVE-2025-8876) were exploited and later added to the US CISA Known Exploited Vulnerabilities catalog, the government’s list of bugs attackers are actively using. A platform that has been hit repeatedly, that sits at the centre of many networks, and that is reachable from the internet is exactly the kind of target that attracts sustained attention.

What to do this week

You cannot apply this patch yourself – it lives on your provider’s infrastructure. What you can do is verify, and verification is your right as the customer whose patient data is at stake. Ask your IT provider, plainly:

• Do you use N-able N-central to manage our systems? A straight yes/no. If yes, continue down the list.
• Is it on-premises, and has it been updated to 2026.3.1.14? The fix is that version or later. “We’re on it” is not an answer; a version number is.
• Was the console ever reachable from the public internet during the exposure window? A management console has no business facing the open internet. It belongs behind a firewall or VPN – the same principle we applied to hardening remote access appliances: if it does not need to be public, it should not be.
• If there was any exposure, what is your compromise-assumption plan? A mature provider will not just patch and move on; they will check for signs of intrusion, rotate credentials, and tell you what they found.
• Are our backups current, tested, and offline? If the worst happened through any vendor, clean backups you have actually restored from are what get the practice running again – which is the heart of having a real downtime and business-continuity plan rather than hoping.

Good providers will welcome these questions and answer them crisply, because they have already done the work. A provider who is evasive, or who cannot tell you what software they run in your environment, has told you something important too.

What this means for your practice

CVE-2026-86218 is a reminder that your security perimeter no longer ends at your own walls – it now includes the tools your suppliers use to reach inside them. That is not a reason for paranoia; it is a reason for a short, specific conversation with whoever holds the keys to your network. Compudent Systems manages dental practices across the GTA and Ontario with that fourth-party exposure in mind: we keep our management tooling patched and off the public internet, we design for the assumption that any vendor can have a bad day, and we make sure a practice’s backups and downtime plan would actually carry it through one. If you are not certain whether the software running your office has been patched against this flaw – or you would simply like a second set of eyes on who can reach your systems and how – contact Compudent for a security assessment. A perfect-10, no-password flaw in the wrong tool is the kind of thing you want to have already handled, not to be reading about after the fact.

Sources & further reading:

• The Hacker News – N-able N-central Pre-Auth RCE Flaw Exploited in the Wild
• Huntress – Critical N-able N-central Vulnerability and Active Exploitation
• Horizon3 – CVE-2026-86218: N-able N-central RCE

Related: A Zero-Day Is Hitting Healthcare in Software Nobody Names: The FastJson Flaw (CVE-2026-16723) and Why You Can’t Protect Code You Don’t Know You Run

Related Reading

• 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
• Ransomware Gangs Are Now Through the Front Door: What the SonicWall SMA1000 VPN Attacks Mean for Dental Practices

The post A Perfect 10, No Password Required: The N-central Zero-Day (CVE-2026-86218) Your IT Provider Must Have Patched appeared first on Compudent Systems.

What RatHat actually does

Security researchers (among them Zimperium) have flagged RatHat as a new Android malware family assessed to be operated by China-based threat actors. It does not arrive from the official app store. Instead it spreads the way most modern mobile threats do – through smishing (scam text messages) and malicious ads that push a user to a fake site and a sideloaded app. The moment of compromise is almost always the same: the app asks for Android’s Accessibility permission – the powerful setting meant to help people with disabilities operate their phone – and the user, expecting the app to work, taps “allow.”

From there RatHat abuses that permission to do something genuinely clever and genuinely nasty. It silently switches on Developer Options and Wireless Debugging, then uses a built-in copy of Android’s Debug Bridge (ADB) to pair with the device’s own debugging service – granting the attacker shell-level control without any computer plugged in by USB. That is the level of access engineers use to rebuild a phone from the command line. Worse, this ADB backdoor is designed to persist even after the visible malicious app is uninstalled. Deleting the dodgy app you were tricked into installing does not evict the intruder – the shell is still there.

The part that is new: an AI at the wheel

What sets RatHat apart from the last decade of Android trojans is how it navigates a device. Older malware was scripted and brittle – it only knew how to tap the exact buttons its authors had hard-coded. RatHat instead uses an AI-powered automation engine: it serializes the live Accessibility tree – essentially a machine-readable map of everything on the screen right now – and sends it to an AI model, which identifies the on-screen elements and generates the taps and swipes needed to accomplish a goal. In effect, the malware can operate the phone by itself, adapting to whatever app or layout it finds instead of breaking the moment a screen changes.

This is the same trend we described when AI began accelerating and rewriting attacks on the desktop side – automation that used to require a human is now handled by a model, at machine speed and scale. RatHat is that idea landing on the phone in your pocket.

Why a dental practice should care about a banking trojan

RatHat’s ultimate purpose is financial: it is built to steal banking credentials and intercept one-time passcodes (OTPs). At first glance that sounds like a consumer problem. It is not, for three reasons that land squarely on a clinic.

First, your practice devices are attractive targets, not neutral ones. A tablet used for patient check-in and imaging, or a front-desk phone tied to your payment and messaging systems, is a device an attacker would very much like shell-level control of. Anything that device can see or reach – patient details, appointment data, saved logins – is exposed the moment it is compromised, and patient information carries PHIPA and HIPAA obligations that a personal phone infection never does.

Second, RatHat specifically defeats SMS-based security. Because it can read the screen and intercept messages, an SMS one-time code is no longer a secret between you and your bank or your software vendor. Any multi-factor authentication that relies on a texted code is weakened against a device like this – a point worth remembering the next time you set up MFA on a practice account.

Third, the line between work and personal has blurred. If a hygienist checks a personal banking app on the same phone they use to text patients, or a manager installs practice software on a personal tablet, one careless “allow” can put a foot in both worlds at once.

The controls that actually shut it out

The good news is that RatHat, for all its cleverness, is stopped by ordinary, well-understood mobile-device hygiene. None of this is exotic; most practices simply have never applied it to their tablets and phones the way they do to their PCs.

• Manage the devices centrally. Enrol every practice tablet and phone in a mobile device management (MDM) platform. MDM lets you enforce policy, block risky settings, push updates, and – crucially – remotely wipe a device that is lost or suspected compromised. An unmanaged fleet is a blind spot.
• Block sideloading. Practice devices should install apps only from vetted, approved sources. RatHat depends on getting a user to install an app from outside the store; a device that cannot sideload cannot be infected this way.
• Guard the Accessibility permission. This is the single hinge of the whole attack. No app should be granted Accessibility access unless it genuinely needs it, and someone should periodically audit which apps hold it. Train the team that an unexpected request to “allow” accessibility or device control is a stop-and-ask moment, not a tap-through.
• Turn off developer and debugging modes. On a clinical device, Developer Options, USB debugging, and wireless debugging should be off and, under MDM, locked off. That removes the exact door RatHat pries open.
• Separate work from personal. Keep patient-facing and payment functions on managed, work-only devices, or at minimum a managed work profile – not on a staff member’s personal phone alongside their banking apps and family messages.
• Move off SMS codes. Prefer phishing-resistant MFA – an authenticator app or passkeys – over texted one-time codes for practice logins, since malware like this is built to intercept SMS. This is the same reasoning behind keeping remote access to the practice properly hardened: the way people log in is exactly where attackers concentrate.
• Keep protection on and patch. Leave Google Play Protect and any endpoint protection enabled, and keep devices updated. Train staff to recognise smishing – the scam text is the first domino.

The same discipline applies to how patient data travels off these devices, too – which is why we keep returning to the theme of using the right, compliant tools rather than convenient consumer apps for anything that touches patient information.

What this means for your practice

RatHat is not a reason to rip the tablets out of your operatories – they are too useful for that, and the threat is manageable. It is a reason to treat those tablets and phones with the same seriousness as the server they connect to. A modern practice’s mobile devices are a real part of its attack surface, and until now most clinics have secured the desktops and left the mobile fleet to chance. Compudent Systems helps dental practices across the GTA and Ontario inventory every device that touches patient data, deploy mobile device management, lock down debugging and sideloading, separate work from personal use, and move accounts onto phishing-resistant MFA. If you are not sure how many tablets and phones can currently reach your patient information – or what any one of them is allowed to do – contact Compudent for a mobile-device security assessment. The tablet in operatory 3 is a computer on your network. It deserves to be defended like one.

Sources & further reading:

• BleepingComputer – New RatHat Android malware uses AI to automate device control
• Infosecurity Magazine – New ‘RatHat’ Android Malware Leverages AI to Steal Financial Data

Related Reading

• When the Malware Rewrites Itself: AI-Accelerated Attacks and What They Mean for Your Practice
• The Other Computers in Your Operatory: Why Connected Dental Devices Are the Attack Surface Nobody Audits
• 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 The Tablet in Operatory 3 Is Now a Target: What AI-Powered ‘RatHat’ Android Malware Means for Your Practice appeared first on Compudent Systems.

Why every practice is now one outage away from a standstill

A generation ago, a power cut meant you reached for the paper daybook. Today, the schedule, the patient charts, the digital radiographs, the e-claims, the recall reminders, and often the phones all live on computers and networks. That efficiency is exactly why an outage hurts so much: there is no analogue fallback humming quietly in the background. When the system is dark, you cannot see who is booked, you cannot pull a history, you cannot capture or read an image, and you cannot submit a claim. The practice does not slow down – it stops.

Four ways the lights go out

Downtime almost always arrives by one of four doors, and recent months have shown every one of them in the wild:

• A bad patch or update. Security updates are essential, but they occasionally break things. September 2026’s Windows Server update did exactly that, knocking out Remote Desktop and locking staff out of the very server their software runs on.
• Ransomware or a security incident. An attacker who encrypts your files can freeze the schedule and charts in seconds, as the steady stream of firewall-borne ransomware campaigns aimed at small clinics keeps proving.
• A third-party vendor or cloud outage. When your billing company, cloud practice-management host, or imaging provider goes down, so do you – even though your own office is fine. The eAssist/Direwolf attack on an outsourced dental-billing provider was a reminder that your uptime depends on your vendors’ uptime.
• Ordinary hardware, power, or internet failure. The least dramatic and most common cause of all – a dead server drive, a failed switch, a cut internet line, or a power surge.

Notice that all four produce the same outcome: no access to the tools that run the practice. A good plan prepares for that outcome, not for one specific villain.

The two numbers that size your plan: RPO and RTO

Before you buy anything, answer two questions – they turn “we should be more prepared” into a concrete, buildable plan.

Recovery Point Objective (RPO): how much data can you afford to lose? If your backup runs once a night and the server dies at 4 p.m., you have lost a full day of charting, images, and payments. If losing an hour is the most you can stomach, you need backups every hour. RPO sets your backup frequency.

Recovery Time Objective (RTO): how long can you be down before it becomes a serious problem? A four-hour RTO and a three-day RTO call for completely different setups – the first may need standby hardware and near-instant restore; the second can tolerate rebuilding from an off-site copy. RTO sets your recovery method and spare capacity. Put a real number on each, and the rest of the plan almost designs itself.

Backups: the foundation, done properly

Every continuity plan rests on backups – but not all backups are equal. The durable standard is the 3-2-1 rule: keep three copies of your data, on two different types of media, with one copy off-site. In the ransomware era, add one more word to that off-site copy: immutable (or at least offline). Modern attackers deliberately hunt for and delete backups before they trigger the encryption, so a backup sitting on an always-connected drive can be destroyed alongside everything else. A copy they cannot reach or alter is what lets you say no to a ransom.

And the single most overlooked rule of all: an untested backup is not a backup – it is a hope. Backups fail silently more often than anyone expects. Schedule periodic test restores so that the first time you recover real data is not the day you are relying on it.

The cloud does not remove your responsibility

Many practices have moved to cloud practice-management software or outsourced billing, and assume continuity is now the vendor’s problem. It is not – it is shared. The servers may be off-site, but the duty to keep the practice running, and to safeguard patient information, stays with you. Practically, that means three things: know your vendor’s promised recovery time and read the service-level agreement; keep your own exportable copy of your data wherever the platform allows it, so you are never wholly locked inside someone else’s system; and have a paper fallback for the day the vendor is simply unreachable. This is the same vendor-and-data discipline we set out in our guide to PHIPA, HIPAA, data governance, and vendor risk – continuity is one more reason to know exactly who holds your data and how you get it back.

The downtime kit: keeping the chairs running when the screens are dark

Restoring the systems is the IT half of the job. The other half is keeping the practice moving during the outage, and that comes down to a simple, printed downtime kit and runbook the front desk can reach for without thinking:

• A printed daily schedule – generated automatically each morning and kept on paper, so you always know who is coming even when the software is down.
• Paper charting, medical-history, and consent forms to capture the day’s clinical notes and signatures for later entry.
• A manual card-payment fallback (a standalone terminal or phone-based option) so you can still take payment when the integrated terminal is offline.
• A one-page runbook: who to call first, in what order, and who does what – the step-by-step for the first thirty minutes, written before the stress of the moment.
• Key contacts and a communication plan: your IT provider, your PMS and billing vendors, plus ready messages for patients and staff so the practice communicates calmly instead of going silent.

Assign an owner and practise it

A plan filed away and forgotten fails at the worst moment. Name an incident owner – the person who takes charge, works the runbook, and coordinates the team – and make sure a backup person can step in if they are away. Then walk the staff through it at least once, so that when a monitor really does stay dark on a Monday morning, the front desk is executing a familiar routine rather than improvising in a panic.

What this means for your practice

Downtime is not a question of if but when – a patch, a vendor, an attacker, or a failed drive will eventually take a fully digital practice offline. What separates a bad hour from a lost week is entirely down to preparation: sized backups you have actually test-restored, an off-site copy ransomware cannot touch, a realistic RTO, and a printed runbook the team knows how to use. Compudent Systems builds and tests business-continuity plans for dental practices across the GTA and Ontario – assessing your backups, hardening them against ransomware, defining your RTO and RPO, assembling your downtime kit, and providing the rapid recovery that turns a potential catastrophe into a manageable interruption. If you cannot say with confidence how long you would be down after an outage – or whether your last backup would even restore – contact Compudent for a business-continuity and backup review. The best time to build the plan is on an ordinary Tuesday, long before you need it.

Sources & further reading:

• CISA – Cyber Resilience and Business Continuity guidance

Related Reading

• Ransomware Is Now a Patient-Safety Issue: What a 38% Hospital Mortality Study Means for Your Dental Practice
• Your Billing Company Is on a Leak Site: The eAssist/Direwolf Attack and Outsourced-RCM Risk
• The FBI Just Refreshed Its Medusa Ransomware Warning for Healthcare: The Real Lesson for Your Dental Practice

The post When the System Goes Down: Building a Downtime and Business-Continuity Plan for Your Dental Practice appeared first on Compudent Systems.

The short answer: yes, but only under specific conditions

Google Meet can support a compliant patient video visit. The industry consensus, reflected in the HIPAA Journal’s 2026 update on the question, is that it is compliant only when three things are all true at once: it’s used as part of a paid Google Workspace plan (Business or Enterprise) whose covered services include Meet; the practice has a signed Business Associate Agreement (BAA) with Google; and it’s configured and used correctly, with sound administrative practices around it. Miss any one of those and you don’t have a compliant setup – you have a video call that happens to look the same on screen.

The version most people actually reach for – a free consumer Google Meet run off a personal Gmail address – meets none of those conditions. There is no BAA available for free consumer accounts, which means Google isn’t contractually bound to protect the information that passes through, and the practice has no agreement to point to if something goes wrong. That’s the free-account trap: the tool works identically, so nothing warns you that you’ve stepped outside the rules.

Why the agreement matters more than the encryption

It’s tempting to assume that because a video call is encrypted, it must be safe to use. Encryption is necessary, but it isn’t sufficient. Under HIPAA, any outside company that creates, receives, stores, or transmits protected health information (PHI) on your behalf is a business associate, and you’re required to have a BAA with them. The BAA is the legal hinge: it’s the document in which the vendor commits to specific safeguards, to breach notification, and to using the data only for permitted purposes. Without it signed, the vendor handling your patients’ information simply isn’t bound to protect it – and your practice, not the vendor, carries the exposure. This is the same principle we’ve walked through for other everyday tools, from texting and emailing patients to whether a practice can use ChatGPT without breaking HIPAA and PHIPA. The tool is rarely the deciding factor; the agreement and the configuration behind it are.

PHIPA: the same duty, worded for Ontario

For a practice here in Ontario, HIPAA is only half the picture – the Personal Health Information Protection Act (PHIPA) is the law that actually governs you. PHIPA doesn’t publish a list of “approved” apps, but it places a parallel, unambiguous duty on health information custodians: take reasonable steps to safeguard personal health information, and put a written agreement in place with any service provider who handles that information on your behalf. In practice that means the same test as HIPAA – a paid plan, a signed agreement, real configuration – plus a few PHIPA-specific habits: obtain and document a patient’s informed consent for a virtual visit, be able to say where the data is stored, and make sure your workflow doesn’t quietly route patient information through a personal account. A free video link fails on all counts.

This isn’t just a Google question

Google Meet gets singled out because it’s so easy to launch, but the exact same logic applies to every mainstream platform. Zoom can be compliant – but through its healthcare offering with a signed BAA, not a free personal Zoom account. Microsoft Teams can be compliant – under a business/enterprise plan with the Microsoft BAA in place. The pattern never changes: a paid business tier, a signed agreement, correct settings, trained staff. We covered the practical security side of this when we looked at safety and security while video conferencing; the compliance layer sits on top of those same good habits. Choosing a platform is the easy part – operating it correctly is the work.

What a compliant teledentistry setup actually looks like

Turning “we do video visits” into “we do compliant video visits” is a short, concrete checklist:

• Stop using personal accounts. No teledentistry consult should ever run on a free, personal Gmail or a free meet.google.com link. This is the single most common gap.
• Move to a paid Workspace plan (Business or Enterprise) that includes Meet as a covered service, then sign the BAA with Google and keep a copy on file.
• Turn on the compliance-supporting settings in the admin console – the controls that restrict access, manage recordings, and limit external sharing – rather than assuming the defaults are enough.
• Treat the extras as PHI too. Meeting recordings, in-call chat, and even calendar invites that name a patient and their reason for visiting all count. Decide where they’re stored and who can see them.
• Document consent for virtual care, and train every staff member who books or hosts a visit so nobody defaults to the convenient-but-non-compliant link under time pressure.

None of this is exotic – it’s the same disciplined vendor-and-data governance we outlined in our guide to PHIPA, HIPAA, and vendor risk, applied to the camera instead of the software.

What this means for your practice

Google Meet is not “unsafe” and it’s not automatically “compliant” – it’s a tool that becomes one or the other depending on how you buy it, agree to it, and configure it. The danger for a dental practice isn’t the technology; it’s the frictionless free version that anyone can start in seconds, with no signed agreement and no record of where a patient’s information just went. Compudent Systems sets up virtual-care stacks for Ontario dental practices the right way: the correct paid plan, the signed business associate agreements, the admin settings actually switched on, and the staff workflows that keep patient information from leaking into personal accounts. If your team is doing video visits and you can’t say for certain that there’s a signed BAA and a properly configured platform behind them, contact Compudent for a teledentistry and PHIPA-compliance review. We’ll make sure the convenient way and the compliant way are the same way.

Sources & further reading:

• The HIPAA Journal – Is Google Meet HIPAA Compliant? (2026 Update)
• Information and Privacy Commissioner of Ontario – Privacy and virtual health care (PHIPA)

Related Reading

• Can Your Dental Practice Use ChatGPT Without Breaking HIPAA and PHIPA? A 2026 Compliance Guide
• Is Texting or Emailing Your Patients a PHIPA and HIPAA Violation? Secure Patient Communication for Dental Practices
• PHIPA, HIPAA, and Dental AI: PHI, Data Governance, and Vendor Risk

The post Is Google Meet Safe for a Patient Video Visit? Teledentistry, HIPAA/PHIPA, and the Free-Account Trap appeared first on Compudent Systems.

What AuraVue actually is

At its core, AuraVue is a visualization workspace. It combines Medit’s 3D intraoral scan data with a patient’s 2D radiographs so a clinician can see both in the same screen rather than in two separate applications. Layered on top of the X-rays is Overjet’s analysis: Overjet is a dental-AI company whose technology automatically reads radiographs to help detect decay and measure bone levels, highlighting areas of interest for the clinician’s review. Overjet is widely used across larger dental organizations and insurers, and its imaging analysis carries US FDA clearance for specific uses. The combination is meant to turn a pile of raw imaging data into a clearer, more visual story – one the dentist can interpret faster and, crucially, one the patient can actually understand.

The problem it’s trying to solve

Two real frustrations sit behind a product like this. The first is workflow friction: in many practices the intraoral scanner has its own software, the sensors and pan/CBCT feed a different imaging suite, and the practice-management system is a third world entirely. Clinicians switch windows, re-open studies, and mentally stitch the pieces together. The second is patient communication. A patient staring at a grayscale periapical radiograph rarely sees what the dentist sees. Put a recognizable 3D model of their own teeth next to that X-ray, with the area of concern visually flagged, and the conversation changes – which is why tools like this tend to be pitched as much for case acceptance as for diagnosis. Those are legitimate wins. The caution is simply that AI-flagged findings are decision support, not a diagnosis: the clinician remains responsible for the read, and a highlight is a prompt to look closely, not a verdict.

The questions that matter more than the demo

A slick unified screen is easy to show in a launch video. Whether it fits a working practice comes down to less glamorous details – and this is where the IT and compliance side earns its keep.

1. Will it actually connect to what you already run?

The single biggest reason imaging tools disappoint is integration. Does the platform work with your existing scanner, sensors and practice-management system, or does it assume you’re all-in on one vendor’s ecosystem? Dental software talks through a patchwork of standards and bridges – TWAIN, DICOM, direct APIs and PMS integrations – and how a new tool plugs in determines whether it saves clicks or adds another silo. We walked through this in detail in our look at how dental AI tools connect to your imaging software; the short version is that “it integrates” is a claim to test with your own setup, not to take on faith.

2. Where does the patient’s image go?

If the AI analysis runs in the cloud – as most modern dental-AI services do – then a patient’s diagnostic images are leaving your building and being processed by a third party. That is not automatically a problem, but it is automatically something you must govern. In Ontario, patient images are personal health information under PHIPA, and sending them to an external processor makes that vendor part of your compliance perimeter. You need to know where the data is stored, who can access it, how long it’s retained, and what happens if the vendor is breached. This is the same vendor-risk discipline we covered in PHIPA, HIPAA and dental AI: a written agreement and clear data-handling answers come before the first image is uploaded, not after.

3. Is it cleared for clinical use where you are?

Overjet’s clearances are US FDA clearances. That does not automatically translate to Canada. A practice north of the border should confirm the tool’s regulatory status with Health Canada and understand exactly which uses are authorized here versus which are informational. It’s a five-minute question to ask a vendor, and the answer tells you a great deal about how carefully they’ve entered the Canadian market.

4. Does it strengthen or complicate your device security?

Adding a cloud AI layer means new connections into and out of your imaging environment – and your imaging environment is often the least-hardened corner of the network, full of appliances that are hard to patch. Any new tool should fit a network you already keep segmented and monitored, not become an excuse to open it up. If your scanners, sensors and older imaging PCs aren’t already isolated appropriately, that’s worth fixing first; we covered the how in keeping legacy imaging devices safely on your dental network.

A practical adoption checklist

• Confirm compatibility with your specific scanner, sensors, CBCT/pan and practice-management system before signing anything.
• Get the data story in writing: a vendor/data-processing agreement, data-residency details, retention and breach-notification terms.
• Verify regulatory clearance for clinical use in Canada, and know which features are diagnostic support versus informational.
• Pilot before you commit: run it on real cases with a couple of clinicians, and measure whether it actually saves time and improves the patient conversation.
• Train the team and set the expectation that AI flags are prompts for review, not final calls.
• Fit it to a secure network: make sure imaging devices and any cloud connections are segmented and monitored.

None of this is a reason to avoid modern imaging tools – the unified-view trend is a real improvement over the disconnected software of the last decade, and it pairs naturally with the broader imaging decisions practices are already making, like choosing between an FMX and a CBCT for a given case. It’s a reason to adopt deliberately.

What this means for your practice

AuraVue is a good signal of where digital dentistry is heading: fewer disconnected programs, more unified views, and AI quietly doing first-pass reads to sharpen the clinician’s eye and the patient’s understanding. For a dental practice, the opportunity is real – and so is the homework. The difference between a tool that pays for itself and one that becomes shelfware usually isn’t the software; it’s whether it fits your existing systems, keeps patient data compliant, and lands on a secure, well-run network. Compudent Systems helps dental practices across Ontario evaluate exactly these decisions – imaging and PMS integration, PHIPA-ready data governance and vendor agreements, and the network security that any cloud AI tool depends on. If you’re considering AuraVue or any AI imaging platform and want a straight answer on whether it will fit and stay compliant, contact Compudent for an imaging and data-governance assessment. We’ll help you adopt the good ideas without inheriting the hidden risks.

Sources & further reading:

• PR Newswire – Medit Launches AuraVue: A Unified 3D Intraoral Scan and X-Ray Visualization Powered by Overjet AI
• Overjet – Overjet Partners with Medit to Launch AuraVue
• Medit – AuraVue product page

Related Reading

• How Dental AI Tools Connect to Your Imaging Software: TWAIN, DICOM, API, and PMS Bridges
• Overjet in Your Practice: Integration, RCM Workflow, and Data Governance
• From Roentgen’s Lab to Your Practice Server: How Dental X-ray Imaging Became an IT Discipline

The post One Screen for Scans and X-Rays: What Medit’s AuraVue With Overjet AI Means for Your Dental Practice appeared first on Compudent Systems.

What Check Point VPN is – and why your practice may depend on it

Check Point is a widely deployed enterprise firewall and VPN platform. In a dental office, a device like this typically plays two roles at once: it’s the firewall that separates your internal network from the internet, and it’s the VPN gateway that lets a doctor review images from home, a bookkeeper connect from another location, or your IT provider reach the network to support it. That dual role is exactly what makes it valuable – and exactly what makes a flaw in it so serious. You may not even know the brand of the box in your server closet; many practices simply have “the firewall the IT company installed.” This advisory is a good reason to find out what it is.

What the flaws actually do

Both bugs live in the way the gateway handles digital certificates while it’s setting up a VPN connection – the handshake that happens before anyone logs in. CVE-2026-85102 is an improper validation of certificate data during VPN negotiation that lets a remote attacker execute arbitrary code on a Security Gateway. CVE-2026-85103 is a heap overflow in the certificate decoder that can allow remote code execution on Security Gateways and Security Management Servers. The critical detail for both: they are pre-authentication. An attacker doesn’t need a stolen password, a valid VPN account, or any authorized access – only the ability to reach the gateway’s VPN service over the internet, which is precisely what a VPN gateway is designed to allow. That’s what earns the 9.8 rating, and it’s why the NCSC assessed both the likelihood and the impact as high. As of this writing there’s no public proof-of-concept exploit, but the agency’s message is that this is a matter of when, not if.

Why ‘the firewall’ is the worst possible thing to lose

When the compromised device is a workstation, you have a problem. When it’s the gateway itself, you have a catastrophe. Successful exploitation here means an attacker can, in the NCSC’s words, take full control of the system, view or modify confidential data, and disrupt operations. Translate that into a dental practice: the box that was supposed to keep intruders out is now the intruder’s foothold – sitting at the boundary of your network, with a clear line to your practice-management server, your imaging archive, and every patient record behind it. It’s the ideal launch point for ransomware, for quietly exfiltrating PHI, or for simply shutting the practice down. This is the same reason we keep sounding the alarm on internet-facing perimeter gear, from firewall flaws that ransomware groups actively exploit to the practice router as a hidden backdoor. The device guarding the door is always the highest-value target in the building.

Which versions are affected, and the fix

The affected releases include R81.20, R82, R82.10, R81.10.x and R82.00.x, along with the end-of-support versions R80 through R80.40, R81 and R81.10. Notably, R82.20 is not affected. Check Point has published fixes and rated the response as straightforward for supported versions:

• Live Patch: Take 24 for R81.20, R82 and R82.10 – and for practices using Check Point Live Patch, these protections have applied automatically since September 9, without even a reboot. Confirm you’re actually covered, because the automatic mitigation only supports those three versions and not every configuration.
• Jumbo Hotfix Accumulators: R82.10 Take 44 or later, R82 Take 126 or later, R81.20 Take 166 or later.
• Spark firewalls: R82.00.10 Build 2325 or later, or R81.10.17 Build 4968 or later.

If you’re running one of the end-of-support versions (R80 through R81.10), there is no clean fix path – that gear needs to be upgraded or replaced, not merely patched. Running EoS security appliances on the edge of a network holding patient data is a risk that predates this specific CVE and outlives it. As an interim hardening step for anyone using the Site-to-Site VPN component, Check Point advises modifying VPN rules to limit access to specific, trusted IP addresses.

What to do now

The response is short and time-sensitive. Identify your gear: confirm whether your practice – or the MSP that manages your network – runs Check Point, and which version. If you use an outside IT provider, this is a completely fair thing to email them today and ask for a straight answer. Patch immediately: apply the Live Patch, Jumbo Hotfix or Spark build for your version, and verify the automatic Live Patch protection is actually in place rather than assuming it. Retire end-of-support devices: if you’re on R80-R81.10, plan the replacement now, not next quarter. Reduce exposure: restrict VPN and management access to trusted sources where you can, and never leave a management interface open to the whole internet. Layer your defenses: multi-factor authentication on all remote access, and monitoring that would flag anomalous activity at the gateway. And treat this as a standing habit, not a one-off – the same patch discipline applies to your servers and endpoints, which is why we walked through how a practice should read this month’s Patch Tuesday just last week.

What this means for your practice

CVE-2026-85102 and CVE-2026-85103 are a textbook example of the risk that comes with convenience: the very gateway that lets your team work remotely is a single, internet-facing box that, if it falls, takes the whole network with it. The fix for supported versions is fast and low-drama; the danger is a practice that simply doesn’t know what’s in its server closet, or assumes “the IT company handles it” without ever confirming. Compudent Systems manages exactly this for dental practices across Ontario: we inventory and patch your firewall and VPN gateways, retire the end-of-support gear that quietly accumulates risk, lock down and monitor remote access, and make sure a critical advisory like this one is acted on the day it lands – not discovered after an incident. If you’re not certain your VPN gateway is patched, supported, and properly restricted right now, contact Compudent for a perimeter and remote-access security assessment. We’ll find out what’s guarding your network and make sure it’s actually doing the job.

Sources & further reading:

• BleepingComputer – Dutch NCSC: Critical Check Point VPN flaws exploitation is imminent
• Check Point Advisory sk1000118

Related Reading

• Ransomware Gangs Are Now Through the Front Door: What the SonicWall SMA1000 VPN Attacks Mean for Dental Practices
• A Perfect 10, No Password Required: The N-central Zero-Day (CVE-2026-86218) Your IT Provider Must Have Patched
• A Single Packet, No Password Required: The Actively Exploited Windows IKE Flaw (CVE-2026-33824) and Your Practice

The post The Gateway That Lets Your Team In Can Let Attackers In Too: Critical Check Point VPN Flaws (CVE-2026-85102 / 85103) and Your Practice appeared first on Compudent Systems.