The cyber incident affecting MyDr has exposed a risk that reaches well beyond the healthcare sector.
Polish authorities say the breach may concern almost 19 million people. Around 12,000 medical facilities use MyDr services. The affected environment contained sensitive medical and personal information, including prescription data, appointments and records linked to patients. MyDr has said the affected information appears to date from 2024 or earlier and that forensic analysis is still determining the exact volume and categories of data involved.
For CIOs, CTOs and security leaders in Poland, the relevant issue is broader than the compromise of one healthcare platform. A breach on this scale creates several forms of downstream risk at once: concentration risk in a critical supplier, exposure of persistent personal identifiers, possible credential and cloud-security failures, and a much larger pool of personal information that criminals may use in social engineering.
The technical investigation is still incomplete. That limits what can be stated about the original attack with confidence. It does not prevent security teams from examining the control failures that could produce this type of incident and the risks created by the stolen data.
The MyDr incident became public in August 2026 after reports of unauthorized access to the company's data.
According to Notes from Poland, the alleged attackers told Polish security publication Zaufana Trzecia Strona that they had obtained information relating to around 18.8 million people. They supplied journalists with data belonging to a senior Polish politician as evidence of access. MyDr then confirmed that an external criminal actor had accessed some of its data.
Cybernews reported that the material shown to journalists included a PESEL number, two telephone numbers and 25 prescriptions linked to the politician. The attackers claimed possession of more than 2.5 TB of information. MyDr has not confirmed that volume and has said it will establish the scope through forensic analysis.
The Polish authorities have not attributed the incident to a state actor. Digital Affairs Minister Krzysztof Gawkowski said the available information pointed instead toward financially motivated cybercrime.
The existence and scale of the breach are established. The complete intrusion path is not.
Some reporting around the incident has described a possible path involving an application vulnerability followed by exposure of development or cloud credentials. That chain should remain labelled as reported until MyDr, investigators or another authoritative source publishes forensic evidence confirming it.
Security teams should therefore examine Internet-facing services not only for vulnerabilities in the applications themselves, but also for the credentials and permissions available after compromise.
MITRE ATT&CK classifies exploitation of an Internet-facing service for initial access as T1190, Exploit Public-Facing Application. The technique covers weaknesses in exposed systems that attackers use to enter an environment. MITRE recommends measures including patching, vulnerability scanning, network segmentation and limiting the privileges available to exposed services.
Consider an Internet-facing application that can read a long-lived repository token, an API credential or a cloud service identity. An attacker who compromises the application may inherit those permissions. The severity of the original software flaw then depends on what those permissions allow.
An exposed workload with tightly scoped credentials may give the attacker limited access. A workload with broad repository or cloud privileges can turn the same vulnerability into a much larger breach.
Mandiant's M-Trends 2026 found that exploitation accounted for 32% of initial infection vectors in its 2025 investigations, making it the leading vector for the sixth consecutive year.
Security teams need to know which secrets an exposed service can access, what privileges those secrets carry and where they can be used.
AWS recommends keeping credentials out of application code and retrieving secrets at runtime through dedicated secret-management mechanisms. It also recommends temporary credentials over long-lived access keys where possible.
An exposed service should have access only to the resources it needs. Development tokens should have narrow permissions. Cloud identities should follow least privilege. Secrets should be revocable without major disruption. Access to sensitive data stores should require controls separate from the application tier.
These measures reduce the amount of infrastructure an attacker can reach after a successful exploit.
Around 12,000 medical facilities reportedly use the MyDr platform.
A provider operating at that scale can accumulate a large amount of sensitive information from organizations that may otherwise have no technical relationship with one another. Attackers need to compromise one environment to reach data connected to thousands of customers or partners.
This concentration exists across modern business infrastructure. Organizations depend on payroll platforms, SaaS applications, managed service providers, cloud vendors and sector-specific software. Each integration can create access to data, identities or operational processes.
The assessment of a critical supplier should include the consequences of compromise, not just evidence of compliance. Organizations should know:
This gives management a clearer view of concentration and dependency than a questionnaire alone.
For regulated organizations, the same analysis also supports requirements around third-party ICT risk, operational resilience and incident management.
Free guide
Reporting deadlines don't wait for the forensics
Timelines, responsibilities and a readiness checklist for NIS2, DORA & GDPR.
The information exposed in a breach does not need to contain corporate passwords to create corporate security problems.
The reported MyDr data includes categories such as PESEL numbers, telephone numbers, prescription information and other medical records. Polish authorities have advised citizens to check whether their data was affected and to restrict their PESEL number through government services where appropriate.
For individuals, the risks include fraud, phishing and possible abuse of sensitive medical information. For businesses, an attacker who knows accurate information about an employee can build a better impersonation attempt.
A criminal may already know the employee's full name and work email from public sources. A breached dataset can add a personal telephone number, national identifier or private contextual information. None of these data points should authenticate a user, but they can make a fraudulent conversation sound credible.
This becomes relevant in helpdesk calls, MFA resets, customer account recovery and other processes where staff make judgement calls about identity.
Mandiant recorded a sharp increase in voice phishing during 2025. Vishing accounted for 11% of observed initial infection vectors, second only to exploitation in the M-Trends 2026 dataset.
Google Threat Intelligence has also documented ShinyHunters-related operations in which attackers used voice phishing and victim-specific credential-harvesting sites to steal SSO credentials and MFA codes. After gaining access, the actors targeted cloud SaaS applications and stole information for extortion.
There is no evidence that data from MyDr has been used in those campaigns or in comparable attacks against Polish companies. The comparison concerns technique, not attribution.
The risk for organizations comes from the overlap between the leaked information and the information social engineers use to build trust.
Security teams should review any process that relies on private biographical information to establish identity.
PESEL numbers, dates of birth, phone numbers and addresses can help distinguish one customer or employee from another. They make poor authentication factors because they remain valid after disclosure.
A security leader can ask the helpdesk team to walk through a password or MFA reset for an employee whose personal information has already been exposed. The review should establish what an attacker would need to know, which controls require possession of a trusted device or cryptographic factor, and where a member of staff can override those controls.
High-risk accounts deserve stronger recovery mechanisms and phishing-resistant authentication where the technology allows it.
The same principle applies to customer-facing processes in financial services.
“An incident of this scale is relevant far beyond the organization that was breached. When personal information such as PESEL numbers, contact details and other sensitive data is exposed, businesses have to assume that criminals may use it to make impersonation attempts more credible.
For financial institutions, that makes strong identity controls even more important. Personal information can provide context during verification, but it should not be sufficient to prove that somebody is who they claim to be. Authentication and recovery processes have to remain reliable even when an attacker already knows a great deal about the customer or employee.”
[NAME, TITLE], Miloan Polska
Any business that operates a service desk, call centre or account-recovery process faces the same underlying problem.
Identify the services that can reach sensitive data or privileged back-end systems.
Give priority to applications that combine public exposure with access to high-value information. Vulnerability management should include code and configuration issues, dependency risk, application testing and rapid remediation for exposed services.
MITRE's guidance for T1190 includes vulnerability scanning, software updates, segmentation and privileged-account management.
Map the credentials available to application workloads.
Long-lived API keys, repository tokens and cloud credentials deserve particular attention because attackers can use them outside the normal user-authentication process.
For each credential, the organization should know who owns it, where it can be used, which permissions it grants and how it can be rotated or revoked.
Rank suppliers by the damage their compromise could cause.
A provider that processes regulated data for thousands of customers or maintains privileged integration into critical systems deserves more scrutiny than a vendor with no sensitive access.
The review should combine contractual due diligence with technical understanding of integrations, tokens and data flows.
Test how staff respond when the caller already possesses correct personal information.
The scenario should include a request to reset a password, replace an MFA method or recover an account.
A mature process should require evidence an attacker cannot obtain by purchasing or combining leaked data.
Many security controls focus on preventing entry. A large data breach can occur after an attacker starts using legitimate credentials or legitimate cloud APIs.
Security teams should check whether their monitoring would identify unusual repository access, suspicious cloud authentication, abnormal database queries and large exports from SaaS or storage platforms.
Mandiant found that organizations detected malicious activity internally in 52% of investigated incidents during 2025, up from 43% in the prior year. Global median dwell time still increased from 11 to 14 days.
Those figures support continued investment in post-compromise visibility.
Incident-response planning also needs to account for attackers who steal information without encrypting systems.
Google Threat Intelligence's reporting on ShinyHunters-associated activity describes operators who gained access to SaaS environments, exfiltrated sensitive information and used the stolen material for extortion.
Production systems may continue to work. Employees may see no obvious disruption. The organization still needs to determine what the attacker accessed, which data left the environment and whether the stolen credentials remain usable.
Security teams need sufficient logs from identity providers, cloud platforms, SaaS applications and data stores to reconstruct access. Management also needs established ownership for regulatory assessment, customer communication and containment.
The forensic investigation into MyDr may still change the technical account of how the attackers entered the environment. The broader exposure is already clear.
A provider used by thousands of medical facilities held highly sensitive information relating to a substantial part of Poland's population. Attackers obtained unauthorized access, and some of the data shown to journalists included persistent personal identifiers and prescription information.
For security leaders, the incident warrants a review of several connected controls. Internet-facing applications need safeguards that limit the consequences of exploitation. Application identities and secrets need narrow privileges. Critical suppliers need to be assessed according to the access and data they concentrate. Identity processes need to remain secure after personal information becomes known to an attacker. Monitoring needs to show what an attacker does after gaining legitimate access.
A practical assessment can start with a critical Internet-facing service and assume that an attacker has compromised it. From there, trace the credentials available to the service, the systems those credentials can reach, the data available through those systems and the telemetry that would expose unusual use.
That exercise provides a useful measure of exposure regardless of whether an organization shares the specific vulnerability involved in the MyDr incident.
Reviewing your exposure after the MyDr breach? Q-Sec can walk through your application, identity, monitoring and incident-response controls with you.
Talk to Q-Sec: team@q-sec.com | q-sec.com
Related reading
Sources: cybernews.com, notesfrompoland.com, attack.mitre.org.