October 7, 2026 No Malware Required: How an “IDOR” Flaw in Dental Software Exposed Patient Records — and the Questions to Ask Your Vendor
Most of the breaches a dental practice reads about involve something dramatic: ransomware locking the schedule, a phishing email that stole a password, a server encrypted overnight. A disclosure at the start of October 2026 is a useful reminder that some of the worst exposures involve none of that. According to a report on OffSeq’s Threat Radar, a European dental-software vendor had patient and staff records exposed through a flaw that required no malware, no stolen credentials, and no clever social engineering. The attacker simply changed a number in a web request.
The flaw has an unglamorous name — IDOR, or insecure direct object reference — and it is one of the most common serious weaknesses in web and mobile software. It is worth ten minutes of a practice owner’s attention, not because you can patch it yourself, but because understanding it changes the questions you ask the companies that hold your patients’ data.
What actually happened
The vendor, FELG Software, makes a practice application used by dental offices. Per the report, an attacker calling themselves “Horus” found that the application’s API — the behind-the-scenes interface the software uses to fetch records — would hand back a patient’s data based purely on an identifying number in the request, without first checking whether the person making the request was allowed to see that record. By incrementing the number — 1, 2, 3, and so on — the attacker could walk straight through the database, pulling patient and staff information one record at a time, and then issued a ransom demand.
That is the entire attack. No encryption, no exploit kit, no password cracking. A legitimate-looking request, repeated with a different number each time.
Why IDOR is so easy to miss
Every modern application refers to things by identifiers: patient #4471, image #9052, invoice #11388. Those numbers routinely appear in web addresses and API calls — that part is normal and fine. The flaw is not the visible number; it is the missing check behind it. Secure software, every single time a record is requested, asks a second question: “is the person asking actually entitled to this particular record?” IDOR is what happens when the software skips that question and trusts the number alone.
This is why security professionals file it under broken access control — currently the number-one category on the industry’s OWASP Top 10 list of web application risks. It is insidious precisely because the feature works perfectly for honest users. Nothing crashes, nothing looks wrong, and ordinary testing rarely catches it, because ordinary testing checks that you can see your data — not that you are stopped from seeing someone else’s.
How it differs from the flaws we usually discuss
We recently explained how SQL injection can expose data inside practice-management software, and the two are worth telling apart, because the defenses differ. SQL injection tricks a database into running commands it was never meant to run — the attacker injects something foreign. IDOR injects nothing. It uses the application exactly as designed and simply asks for records that should have been off-limits. One is a break-in; the other is an unlocked door. A practice does not need to know how to fix either, but knowing they are different helps you recognize that “our vendor said they protect against hackers” is not a complete answer.
Why this is a dental-practice problem, not just a software problem
It is tempting to read “vendor flaw” and conclude there is nothing to do. But the records exposed in a breach like this are your patients’ records, and under PHIPA and HIPAA the obligation to safeguard that information does not fully transfer to a vendor just because the data lives on their servers. When you entrust patient data to a cloud practice-management system, an imaging platform, a patient-communication tool, or an online booking service, you are trusting that each of those vendors wrote their access checks correctly — something you cannot see and did not test.
This is the same uncomfortable lesson behind a vendor freezing its own development to deal with security bugs: your practice inherits the security maturity of every supplier it relies on. And the consequences land on you. A single exposed database can become a reportable breach affecting thousands of people, exactly as it did when one compromised account exposed 45,853 patients at another practice. The cause differs; the aftermath — notification letters, regulatory scrutiny, lost trust — looks the same.
The questions to put to your software vendors
You cannot read your vendors’ source code, but you can ask questions whose answers reveal whether they take access control seriously. Vague or defensive responses are themselves an answer.
- “Do you perform independent security testing, and how often?” A mature vendor commissions regular third-party penetration tests and application security assessments. IDOR is a flaw a competent tester looks for specifically; a vendor that tests will usually have found and fixed its own before an attacker did.
- “How does your system verify that a logged-in user can only access their own practice’s and patients’ records?” You want to hear that authorization is checked on every request, server-side — not that access is controlled only by what the user interface shows.
- “Do you keep access logs, and would you be able to tell us which records were accessed if there were an incident?” If a breach happens, the ability to scope it precisely is the difference between notifying the handful of affected patients and having to notify everyone.
- “What is your breach-notification commitment to us, in writing?” Your regulatory clock starts when you learn of an exposure. A vendor contract should obligate prompt notification, not a quiet mention weeks later.
- “Who else can see our data, and where is it hosted?” Sub-processors and data residency matter for both compliance and your own understanding of the risk surface.
What you can control on your own side
Vendor diligence is the main lever here, but a few practice-side habits reduce the blast radius of any exposure. Grant staff only the access they genuinely need inside each system, so a single account — or a single flaw — reaches less. Remove logins the moment someone leaves. Keep an inventory of every third-party service that touches patient data, so that when a breach notice arrives you already know whether you are affected. And treat a vendor’s security answers as part of the buying decision, not an afterthought once the contract is signed.
The pattern behind the headline
The enduring lesson of an IDOR breach is that a catastrophic data exposure does not require a sophisticated attacker — only a missing check and someone patient enough to count upward. For a dental practice, the defensible position is not to become web-security experts, but to choose and hold accountable the vendors who are. The practices that come through incidents like this best are the ones that asked the hard questions before they signed, kept a clear picture of who holds their data, and had a plan for the day a supplier calls with bad news.
How Compudent Systems can help
At Compudent Systems, we help dental practices across the GTA and Ontario manage the risk that comes with every piece of software and every vendor that touches patient data. We can help you inventory the systems and third parties holding your PHI, put the right security and breach-notification questions to your vendors, tighten access and account hygiene inside your practice, and build an incident-response plan so a vendor’s bad day does not become your compliance crisis. Contact Compudent Systems for a security and vendor-risk assessment — and turn “our software company had a breach” from a scramble into a procedure you have already rehearsed.
Sources & further reading:
Related Reading
- The Breach Vector Hiding in Your Practice Management Software: SQL Injection Explained for Dental Offices
- New HIPAA Security Rule Requirements: Mandatory Vulnerability Scanning and Penetration Testing for Dental Practices
- One Compromised Account, 45,853 Patients: The Hawaii Family Dental Breach and the Weak Link You Actually Control