← Back to the blog

The MyDr attack: what we actually know about the medical data breach

On 10 August 2026, MyDr - one of Poland's largest providers of electronic medical records (EDM) software - announced it was investigating a serious security incident. Unknown perpetrators claim to have stolen 2.5 TB of data and a database holding 18,814,422 unique PESEL numbers (Polish national ID numbers) along with prescription data. It is potentially one of the largest medical data breaches in the country's history - but "potentially" is the operative word.

Context and legality. This is educational material describing a publicly reported incident. We consistently separate the attackers' claims from what has been independently verified - at this stage the company has not confirmed a breach and the investigation is ongoing. We did not use any Tor sources or "leak sites"; we rely on reputable open-web reporting (chiefly Zaufana Trzecia Strona) and official statements. Testing systems you do not own is legal only with the owner's written authorisation.

What MyDr is, and why the scale is so large

MyDr is a platform used by doctors and clinics - they are the ones who enter visit data and issue prescriptions. A patient usually doesn't even know their data passes through it. The company itself says it handles 3 million visits and 2.7 million prescriptions per month across thousands of healthcare points. That explains why the claimed figure of 18+ million records is plausible in order of magnitude - it fits the system's potential reach.

In ownership terms MyDr belongs to the ZnanyLekarz group, which in turn belongs to DocPlanner (a company present in 13 countries, founded by Mariusz Gralewski). Important for the risk picture: MyDr and ZnanyLekarz run separate systems and do not share data - the incident concerns the MyDr platform, not DocPlanner's whole portfolio.

Timeline

Per the available reporting: on 5 August the attackers reportedly emailed the CEO of the owning company, attaching a password-protected PDF of "evidence" and a request to make contact. On Saturday 8 August they contacted the newsroom at Zaufana Trzecia Strona. On 10 August MyDr published a statement about the investigation and an FAQ for clients, and Deputy PM and Minister of Digital Affairs Krzysztof Gawkowski confirmed the services were handling the case, writing that "much indicates that an unauthorised person may have gained access" to the data.

What data is in play

The attackers claim to hold a complete patient database. Zaufana Trzecia Strona verified part of the samples provided and - as far as it could - did not catch the attackers in a lie. Based on those samples, records contain:

• PESEL number, full name and date of birth (for the public figure checked, the date and PESEL were correct),
• phone numbers (one was confirmed against other sources; some records held the placeholder 111111111),
• NFZ region (the national health-fund region matched for the people checked),
• prescription data - including a list of 25 prescription numbers tied to one person (no drug names in that sample).

To gauge coverage, the newsroom ran a small experiment: for five checked PESEL numbers of industry people, the attackers returned records in three cases. Statistically small, but consistent with the claimed size of the database.

Beyond patient data, the attackers claim access to the company's internal systems: Jira, HubSpot CRM, an account on the SMSApi gateway (they allegedly sent an SMS to employees from the company's own account), plus a GitHub repository with source code and AWS infrastructure. The stolen material reportedly included internal correspondence, information about new hires, a whistleblower report and a price list for advertising specific drugs. To be clear: 2.5 TB and 18.8 million are numbers stated by the attackers, and cannot be independently confirmed at this stage.

What the published screenshots show (data redacted)

The attackers did not publish a public dump of the whole database - they circulated proof privately: to the newsroom at Zaufana Trzecia Strona and to the company's CEO (via the Session messenger). Below we describe what those materials showed, with people's data redacted. We do not quote any real numbers, names or phone numbers.

The strongest piece of proof was a screenshot of a database record for one of Poland's top politicians. It held his correct date of birth, PESEL number, full name and two phone numbers (one confirmed against other sources), a matching NFZ region, and a prescription. Separately, a list of 25 prescription numbers tied to that person was provided (without drug names). The newsroom also confirmed its own record: a correct PESEL and NFZ region, though the phone field held the placeholder 111111111.

Beyond patient records, internal company material also circulated: a screenshot from Jira, an SMS reportedly sent to employees from the company's own SMSApi account, and a password-protected PDF sent to the CEO (the password was his PESEL) - containing internal correspondence, information about new hires, a whistleblower report, a fragment of the database of cooperating doctors, and a price list for advertising specific drugs. Zaufana Trzecia Strona, which published these screenshots, itself masked the sensitive parts - including a still-working link to the PDF file.

Why this is dangerous. The impact of such a data set goes far beyond "a number in a database":

• Identity theft and fraud. PESEL + full name + date of birth + phone is enough to attempt financial fraud and impersonation.
• Targeted phishing and vishing. With prescription data and the NFZ region, an attacker can call "from the clinic about your prescription" - convincingly, because they know the details. This is data you cannot change like a password.
• Extortion and sensitive data. Treatment information is a special category under GDPR; disclosing it can be used for pressure, smear or discrimination - especially against public figures, whose records appeared in the samples.
• Abuse of the SMS channel. Access to the company's SMSApi account allows phishing texts from a genuine sender - the victim has no way to tell them apart from the clinic's own messages.
• Harm to the company. Leaked internal correspondence, a whistleblower report or a drug-advertising price list are a separate layer of damage - reputational and commercial.

How - according to the attackers - the breach happened

This is the part to read with the most caution, because it comes solely from the attackers and has not been confirmed. Per their account, the chain looked like this:

1. XXE in PKCS#12 certificate handling → remote code execution. The entry point was said to be an XML External Entity flaw when processing PKCS#12 containers. It is a technically plausible scenario: PKCS#12 is a "bundle" format for a key and certificate, and if the application parses related XML somewhere with a misconfigured parser (external entities enabled), an attacker can make the server reach for local files or network resources - and, in worse variants, reach code execution.
2. A GitHub API key. The RCE reportedly let them read an API key off the host that opened access to the repository holding the service's source code.
3. Source code → AWS infrastructure. With the code in hand, the attackers reportedly found their way into the cloud environment on AWS, and from there to the data.

Even if this account proves inaccurate, its moral is universal: a single data-parsing flaw rarely stops at one host. Secrets baked into code or reachable from a host (API keys, cloud credentials) turn a local RCE into a full chain all the way to the database.

Who is behind it - and why "APT group" is premature

This needs stating plainly, because labels appear fast online. As of now, no one has attributed the attack to any known group - neither an APT (state-sponsored) nor a specific ransomware crew. More than that, the attackers are clearly covering their tracks and posing as someone they are not. Zaufana Trzecia Strona flagged several signals: they communicate in English, "smile in Russian" (the characteristic ))))))))), and their English reads as if someone had an AI model rewrite the text "as though written by a middling-English-speaking citizen of some Asian country." That points to a deliberate false trail, not an authentic group signature.

The clues to motive, by contrast, are fairly legible and point to financial extortion rather than classic espionage: contact via the Session messenger, an "offer to sell the results of a security audit" made to the CEO, an attempt to get the story into the media. That is the playbook of modern data extortion (leverage from the threat of disclosure), often without an encryption stage. It is also worth noting what the reporting so far does not show: a public post on a Tor "leak site." The attackers took the route of direct pressure, not a public auction. If hard attribution evidence emerges, we will update this post - until then "APT group" remains an unsupported hypothesis.

How to judge credibility - a method lesson

This incident is a good illustration of how to treat "mega-breaches" in real time. First, you can verify samples, not the whole: a few records could be confirmed, but not 2.5 TB or 18 million. Second, a genuine sample does not prove the size of the database - those are two different things. Third, the style of communication can be a costume; emojis and broken English are a cheap way to muddy attribution today. Solid reporting - like ZTS's - frames it exactly this way: it states what was verified and openly says what was not.

The company's and the state's response - plus the GDPR catch

MyDr launched its incident-response procedures, engaged its security, engineering and infrastructure teams plus external experts and legal advisors, notified the authorities and its clients (clinics and doctors), and published an FAQ. The company says its systems are working normally and - while the investigation continues - it does not confirm a data theft.

There is a real problem here for patients, though. MyDr acts as a data processor under GDPR, while the data controllers are the thousands of healthcare facilities. In practice that means MyDr cannot simply hand victims' data to, say, CERT Polska and the bezpiecznedane.gov.pl service. Establishing "am I in the breach" will therefore be hard and slow for many people - the information has to travel: MyDr → facility (controller) → patient.

Why healthcare is such a tempting target

Medical data is the full set: personal and contact details, medical history, results, treatment. And the state of defences is often weak. A Centrum e-Zdrowia study of over 11,000 entities found that 72% of facilities have no cybersecurity team (around 59% among hospitals), roughly 60% do not monitor for vulnerabilities, and fewer than 60% regularly test that backups can be restored. Per the sector CSIRT CeZ, ransomware attacks on healthcare worldwide grew from 69 (2020) to 506 (2024). In 2024, according to Check Point Research, medical organisations accounted for about 10% of all publicly disclosed ransomware victims - second only to manufacturing.

How to defend - lessons for vendors and clinics

Regardless of exactly how this attack unfolded, the claimed chain points at typical, fixable weaknesses. In order of priority:

1. Harden XML parsing (defend against XXE). Disable external entities and DTD expansion in XML parsers; use libraries in a "secure by default" configuration. It is the most effective and cheapest XXE mitigation, including when processing certificates and signed documents.
2. Get secrets out of code and off hosts. Keep API keys (like the alleged GitHub token) and cloud credentials in a dedicated secrets vault, injected at runtime with a short lifetime. Scan repositories for embedded secrets and rotate everything after any exposure.
3. Least privilege in the cloud. Assume a single host will be compromised and limit the blast radius: narrow IAM roles, segmentation, no "flat" path from a front-end app to the full patient database. Access to sensitive data belongs behind extra barriers.
4. Monitoring and egress control. Exfiltrating 2.5 TB is an event that should leave a trace. Filter egress, alert on unusual transfers and log access to data. Continuous visibility beats a quarterly audit when detection needs to happen in hours, not months.
5. Supply-chain security. For a clinic, the EDM vendor is part of its own attack surface. Write security requirements, an audit right and an incident-notification regime into contracts - this is also a direct NIS2/KSC requirement.

What a patient can do

For now there is no simple way to check yourself whether you are in this breach, so it is worth acting preventively. Sensible steps: flag/lock your PESEL number (the mObywatel reservation register), stay alert to phishing and vishing that invokes "medical data" or prescriptions, and be wary of calls and emails that prey on this story. A PESEL cannot be "revoked," but reserving it makes financial abuse harder.

What this means

The MyDr attack - if its scale is confirmed - shows that a single medical-software vendor can become a single point of failure for the data of millions of patients. This is squarely NIS2/KSC territory: vulnerability management, access control, supply-chain security and the ability to detect incidents. It is the same direction we described with the GTG-1002 campaign and the JadePuffer agentic ransomware - scale and tempo are rising, and the weakest link is often basic hygiene: data parsing, secrets, privileges.

We covered the requirements in detail on the NIS2 / KSC page. If you build or host systems processing sensitive data and want to test your resilience - from XXE/RCE flaws through secret hygiene to the blast radius after one host is taken - that is exactly our specialisation: penetration testing and attack-surface review. Book a consultation before someone else does it for you with a message reading "we have the results of your audit."

Sources: Zaufana Trzecia Strona · CRN Polska · ITwiz · Bankier.pl · iMagazine · MyDr statement (FAQ)