The MyDr breach: how 18.8 million PESEL numbers ended up in criminal hands, and why freezing your PESEL only treats the symptom

On August 10, 2026, at 6:30 PM, the Polish security outlet Zaufana Trzecia Strona published a report that, within days, snowballed into one of the worst data security crises in Poland's history. Anonymous attackers reached out to the newsroom claiming they'd stolen a database from MyDr's systems containing 18,814,422 unique PESEL numbers (Poland's national ID number), totaling roughly 2.5 terabytes. Two days later, on August 12, Deputy Prime Minister and Minister of Digital Affairs Krzysztof Gawkowski confirmed at a press conference following a meeting of the Joint Cybersecurity Operations Center that the country was dealing with "an extraordinary data breach affecting close to 19 million Polish citizens". Put the scale in perspective: that's data tied to nearly half of Poland's population, stolen from a single medical software vendor whose name, before August 2026, most of the people whose data it held had probably never even heard of.

I'm writing this not just as commentary on breaking news, but as an analysis grounded in more than twenty-one years working in systems architecture, DevOps, and cloud infrastructure security, plus my current work building a governance and evidence platform for AI systems. This case is, to me, a textbook study in how systemic failures at the intersection of law, business, and engineering compound into a national-scale disaster, and it exposes just how fundamentally broken the underlying mechanism for identifying citizens is, the same mechanism most of Poland's public administration and financial sector still runs on.

What actually happened: timeline and scale

MyDr Sp. z o.o. is a Polish company supplying electronic medical record software to healthcare providers, used by roughly 12,000 clinics and doctors' offices across the country. The company belongs to the Znany Lekarz group. According to findings shared by the spokesperson for the Regional Prosecutor's Office in Warsaw, Piotr Antoni Skiba, the investigation being run by the Central Bureau for Combating Cybercrime centers on an unidentified individual gaining unauthorized access, no later than August 6, 2026, via the internet, to all or part of MyDr's IT systems, after breaking through or bypassing its security safeguards. Industry coverage from August 9, 2026, adds a far more specific detail: the alleged attackers told Cyberdefence24 reporters they got in by exploiting an XML External Entity (XXE) vulnerability in the company's PKCS#12 certificate-handling code, which enabled remote code execution, after which they harvested a GitHub API key and used it to pull the service's source code. This is the part of the story that should worry any engineer responsible for securing systems that process sensitive data, because it describes a textbook, decade-old attack chain well known in the security community: an XML-parsing flaw in certificate handling, escalating to remote code execution, escalating to a stolen authentication secret (the API key), escalating to access to the source code repository, and from there, judging by the scale of the leak, further privilege escalation inside the production environment.

An important methodological caveat: the claim about the specific attack vector, the XXE vulnerability in PKCS#12 handling, comes from the alleged attackers themselves, relayed to journalists, not from an official, technical post-incident report published by MyDr, CERT Polska, or the prosecutor's office. None of the government or company statements issued so far has confirmed or denied that technical version in any detail, which is typical in the early phase of an incident like this. A full technical post-mortem usually surfaces only once an investigation and internal audit wrap up, if it ever gets made public in Poland at all, which is itself a separate systemic problem I get into later in this piece.

The gap between the attackers' claims and the government's numbers is, on its own, worth noting. The attackers cite a very precise figure: 18,814,422 unique PESEL numbers and roughly 2.5 terabytes of data. The Ministry of Digital Affairs talks about "close to 19 million citizens" and "over 2 terabytes of data," a rounder, more conservative figure. That gap isn't accidental: attackers who actually hold the database can quote an exact unique-record count straight out of a SQL COUNT DISTINCT query, while the government is basing its estimates on information supplied by MyDr itself, which, at the time of writing, is still investigating and says it can't yet pin down the precise scope of the breach.

The stolen data spans full names, PESEL numbers, phone numbers, email addresses, regional health-fund affiliation, prescription numbers and contents, referral information, visit history, and in some cases the actual clinical notes describing a patient's treatment and conditions. Under GDPR, this falls into the special category of data, health data, subject to the highest tier of legal protection anywhere in the EU's data-protection framework, precisely because of its potential for extortion, discrimination, or blackmail.

MyDr's confirmation of the attack lagged behind the first media reports, with the company issuing a statement on August 12, 2026, two days after the story broke via Zaufana Trzecia Strona, and only after the digital affairs minister had already publicly confirmed the scale of the incident on Onet. In its statement, the company described the attack as "an external, deliberate act of a criminal nature," while cautioning that the data involved most likely dates back to archival records, primarily from 2024 and earlier, and may not cover every one of the company's clients or every one of their patients. MyDr also stated that its systems remain fully operational and safe to use, that its cybersecurity partners are actively monitoring the dark web, and that as of the statement's publication, no evidence had surfaced that the data had been published or made publicly available, adding that clients currently don't need to take any action.

Crucially, Minister Gawkowski provided one hard piece of evidence backing the attackers' claims: he revealed that, to prove they genuinely held the stolen database, the attackers sent over the data of a prominent Polish politician, including that person's PESEL number and their prescription history. That detail cuts through any speculation that this whole incident might be an exaggerated bluff by a criminal group trying to spark panic without real data to back it up. The government also confirmed the attackers' motive appears financial rather than political, that the breach did not touch the state's central e-health system (known as P1), and that nothing so far points to the attack originating from outside Poland. Investigators are pursuing this as an extortion case rather than as state-sponsored espionage.

Why this breach is different from what came before

Poland has already dealt with serious medical data breaches, including the ALAB laboratory incident, which niebezpiecznik.pl referenced directly in its August 17, 2026 commentary, noting that some of the guidance around handling breach fallout had already been issued back then, after that earlier case. What sets the MyDr breach apart is sheer scale: 18.8 million unique PESEL numbers, per the attackers' own claims, means data covering nearly half of Poland's population, surpassing every previously known, publicly disclosed incident in the country by number of people affected.

The second distinguishing factor is MyDr's own corporate structure, which niebezpiecznik.pl called out sharply in reader commentary under its August 17, 2026 article, pointing out that MyDr Sp. z o.o. operates on a founding capital of around PLN 5,600, sits fully owned by a Dutch parent entity, which in turn has capital ties to the investment bank Goldman Sachs, and that the company's IPO prospectus reportedly disclosed an intent to use patient medical data to train AI models. That comment, however sharply worded, cuts straight to the core structural problem: medical data belonging to millions of Poles, data subject to the highest level of legal protection anywhere in the EU, ends up in practice held by private entities with relatively modest registered capital, tied financially to foreign investment funds, operating on a business model in which patient data itself gradually becomes a commercial asset that outgrows the original purpose for which it was collected.

It's worth being precise here: this isn't a case of the state centralizing medical records and handing them to one private vendor. As one commenter under the niebezpiecznik piece rightly pointed out, the data reached MyDr independently, through the individual decisions of roughly 20,000 separate clinics and doctors' offices, each of which made its own choice to pick this particular software vendor for managing medical records. That reflects a broader, structural problem in Poland's digital healthcare services market: small and mid-sized medical practices, lacking their own IT resources or the expertise to build and maintain a secure data-management system, quite reasonably buy ready-made solutions from specialized vendors like MyDr. That's a rational business decision on its own, but it concentrates risk: once thousands of independent clinics rely on a single vendor, any single flaw in that vendor's defenses instantly becomes a systemic failure at the scale of every patient across those clinics.

The state's response: Bezpieczne Dane, PESEL freezing, and the limits of that approach

The government's headline, actionable recommendation to citizens, repeated by Minister Gawkowski at every media appearance since August 10, 2026, is to freeze their PESEL number through the mObywatel app, the mObywatel.gov.pl portal, in person at a local government office, or at a bank branch. The minister has stressed that the whole process takes about five seconds in the app and called it "basic, elementary digital hygiene". The second piece of the institutional response is the government's Bezpieczne Dane ("Safe Data") portal, available at bezpiecznedane.gov.pl, where citizens can log in with their Trusted Profile (profil zaufany) to check whether their data shows up in any reported security incidents. One important caveat is worth flagging: on the day the first breach reports broke, the Bezpieczne Dane portal was down for an extended stretch, and data specific to the MyDr incident hadn't yet been loaded into the service's database by the time the first news stories ran. Minister Gawkowski said the data would be added incrementally, once MyDr actually reconstructs and organizes the full scope of the stolen records, which, as of an August 13, 2026 statement, was still ongoing.

Freezing your PESEL, while genuinely worth doing, protects against a specific, limited set of threats: it blocks taking out a loan or credit agreement, issuing a duplicate SIM card, withdrawing cash at a bank branch, or signing a notarial deed using a frozen PESEL number without first lifting the freeze. It doesn't, however, protect against the full range of risks that come with a medical-data breach specifically. A legal expert quoted by Rzeczpospolita stresses that freezing your PESEL should be treated as just the first of several steps, to be followed by changing any exposed passwords and staying alert for months to phishing attempts and impersonation scams, since this kind of breach hands criminals real material, actual past visits, actual prescribed medications, the actual name of the clinic a patient attended, to craft highly convincing, personalized scam messages.

A critical point raised by niebezpiecznik.pl, which I'm quoting here in full context, targets a serious practical flaw in the very idea of a blanket, top-down PESEL freeze for every citizen, an option Minister Gawkowski floated in an August 13, 2026 interview with Polsat News, saying the government is considering automatically freezing PESEL numbers to help digitally excluded citizens. Niebezpiecznik points out that a blanket, top-down freeze simply can't be imposed mechanically, because it would also apply to people who don't use the mObywatel app and have significantly limited practical access to a government office where they'd need to go to lift the freeze whenever they actually need it, for instance to take out a legitimate loan. Citing 2024 data from Poland's Central Statistical Office (GUS), referenced in the comment thread under the niebezpiecznik article, only 61 percent of people aged 16 to 74 used e-government services at all, and among people aged 55 to 64, only 25.5 percent could independently make changes to their electronic settings, a figure that dropped to 10.1 percent among those aged 65 to 74. That's a real, practical digital-inclusion problem that any blanket, top-down PESEL reform needs to solve before rollout, not after the fact.

A second, more technical flaw with PESEL freezing, raised in the same niebezpiecznik discussion, involves phone number porting between carriers. Under Poland's Electronic Communications Law (art. 297), the requirement to check a PESEL freeze applies only to issuing a duplicate SIM card with the same carrier, not to porting a number to a different carrier under a new contract. In practice, that means someone with a frozen PESEL could theoretically still fall victim to a SIM-swap-style number takeover through a carrier port-out, if the attacker has a forged ID document in the victim's name. That's a technical detail you won't hear in official government messaging urging people to freeze their PESEL, and it's exactly the kind of nuance any serious cybersecurity explainer needs to include.

Legal and financial fallout across the healthcare ecosystem

Rzeczpospolita's August 12, 2026 analysis flags serious legal consequences reaching well beyond MyDr itself: administrative fines and damages claims could hit thousands of clinics that use its system, because under GDPR, it's those clinics, as data controllers for their own patients, that bear primary responsibility for choosing an adequately secured data processor, with MyDr acting in this arrangement as the processor working on their behalf. Poland's data protection authority (UODO) stated explicitly that the legal obligation to notify affected individuals falls on the data controllers, meaning the individual medical practices that use MyDr's services, not on MyDr itself as the processor. In practice, that means 12,000 independent clinics across Poland now face a legal obligation to notify their own patients about a breach they didn't cause and had no direct control over the technical root cause of, yet another sign of just how disproportionate the legal liability structure is relative to who actually controls security in an IT-outsourcing model built around one central vendor.

UODO has opened a formal investigation into the case. The Central Bureau for Combating Cybercrime is leading the criminal investigation, overseen by the Regional Prosecutor's Office in Warsaw, with charges under investigation covering unauthorized access to an IT system after breaching its security, as well as unauthorized processing of personal data, including health data, through its transfer by the attackers to the Zaufana Trzecia Strona newsroom. On August 13, 2026, Deputy PM Gawkowski said he wasn't ruling out legislative changes once the incident is fully analyzed, though he hasn't yet specified which area of law those changes would target.

Why PESEL, as an identification mechanism, is architecturally obsolete

Here's where I want to shift from reporting the facts to giving my own expert take, built on twenty-one years of hands-on work with systems architecture and security infrastructure. PESEL, introduced in Poland in 1979, was designed for an era with no concept of mass, digital data breaches or the risk of identity data being algorithmically exploited at a scale of millions of records at once. PESEL is a static number, assigned once for life, encoding a person's date of birth and gender directly into its structure, which is itself a fundamental design flaw by modern information-security standards: an identifier meant to function as an authentication secret in practice functions as a publicly known, static, non-resettable access key to a citizen's identity, routinely typed into hundreds of paper and digital forms over that person's entire lifetime.

The architectural problem boils down to one fundamental design flaw: PESEL bundles together two entirely separate functions that a well-designed security system should keep apart. The first function is identification, a public reference number that uniquely points to a specific person in a database, analogous to a primary key in a relational database. The second function, as practiced by banks, telecom carriers, and countless other institutions, is quasi-authentication, treating mere knowledge of a PESEL number as proof that the person providing it is actually the person that number belongs to. That's the exact same conceptual mistake IT security made for decades with credit card numbers and email addresses, treating them simultaneously as identifiers and as authorization secrets, until the financial and tech industries learned the hard way that those two functions need to be separated, which is how we ended up with CVV codes, two-factor authentication, and tokenization.

PESEL freezing, introduced in Poland in 2023, is essentially a procedural patch slapped on top of this fundamental architectural flaw, not a fix to the architecture itself. It works on the same logic as freezing a lost credit card: it blocks a specific set of predefined uses (loans, SIM duplicates, cash withdrawals, notarial deeds), but it doesn't change the fact that the PESEL number itself remains a static, non-removable, publicly compromised identifier whose mere knowledge still unlocks plenty of other processes outside the scope of the freeze, registering at a doctor's office, for instance, something commenters under the niebezpiecznik article explicitly flagged, pointing to the practical problem of a patient who can't exactly walk into a clinic and "introduce himself as John Smith".

An alternative I consider genuinely viable: a rotating, context-bound identity token

As someone currently building evidence and governance infrastructure for high-risk data systems, I want to reframe the PESEL problem, not as something you patch with yet another procedural mechanism bolted onto an existing, flawed static number, but as an architecture problem, one that today's most secure payment systems and the world's most advanced digital-identity deployments have already solved through contextual tokenization.

What follows isn't a finished piece of draft legislation. It's an architectural sketch of what modernizing Poland's citizen-identification system could look like, built on patterns already proven in other security domains. Instead of one static PESEL number used identically at the bank, at the doctor's office, with a telecom carrier, and at a government office, a contextual-tokenization system would assign each citizen a single, immutable, protected master identifier, held exclusively in a state registry and never exposed to third parties in plain form. Every institution that needs to identify a citizen, a bank, a clinic, a telecom carrier, would instead receive a unique context token, mathematically linked to the master identifier but impossible to reverse-engineer without access to the state registry, the same principle behind card tokenization already used at scale by Apple Pay and Google Pay.

In practice, that would mean a breach at one clinic or one bank would expose only a token useful in that specific institutional context, worthless to an attacker trying to reuse it at a bank, with a different carrier, or at another clinic, since each of those entities would hold a completely different token, mathematically unlinked to tokens issued to other institutions without going through the central government registry's conversion process. I'd also consider it essential to add periodic or on-demand rotation of these context tokens, the same principle behind expiring and refreshing session tokens in secure authentication systems, which would further limit the value of a stolen token over time, even in the event of a breach at a specific institution.

I fully recognize that rolling out an architecture like this at a national scale is a project on par with a full digital rebuild of state registries, requiring years of work, massive investment, and a deep overhaul of the administrative law governing data exchange between institutions. I'm not proposing this as a fix for next quarter. I'm proposing it as the strategic direction Poland should be deliberately moving toward, instead of continuing to patch one procedural mechanism after another, like PESEL freezing, onto a fundamentally obsolete 1979-era identification architecture, in a world where the scale and frequency of data breaches is growing exponentially, not linearly.

What needs to happen now, regardless of any architectural overhaul

Until a fundamental architectural reform like that becomes a realistic political option, I see several much simpler, immediately actionable measures as essential, ones that directly address the most glaring weaknesses this MyDr incident exposed. First: a mandatory, full technical post-incident report from every entity processing high-risk data once an investigation wraps up, modeled on the aviation industry's practice after every crash, because Poland's tech sector today systemically doesn't share technical breach details, which makes it impossible for other companies to learn from each other's mistakes and lets the same vulnerability classes, like the decade-old XXE flaws well known in web-application security, keep recurring. Second: a real administrative-penalty structure scaled to revenue, not registered capital, directly addressing the issue raised in public discussion, where a small company with low registered capital can end up facing a fine wildly disproportionate to the real-world harm inflicted on millions of citizens. Third: a mandatory, recurring, independent third-party security audit for any software vendor serving more than a defined threshold of medical practices or institutional clients, scaled to the systemic risk created when data belonging to millions of citizens becomes concentrated in the hands of one private technology vendor.

This breach isn't an anomaly that a one-time push to get twenty million Poles to freeze their PESEL can fix. It's a symptom of a far deeper architectural problem, an obsolete citizen-identification mechanism, systemic risk concentration in the hands of underfunded, private IT vendors serving the public sector, and the absence of a culture of transparent, technical incident reporting across Poland's tech ecosystem. Solving it requires infrastructural thinking, not procedural thinking, and that's exactly the distinction I keep pushing for in every project I build.