Polish Medical Software Was Breached Through SQL Injection — Patient Data Left the Network

• The Mess: Attackers exploited an SQL injection in Medyc, a medical software platform developed by Polish vendor Qbusoft, and extracted a database archive from the provider’s environment.
• The Damage: Names, PESEL numbers, addresses, phone numbers and email addresses were exposed, while investigators say scripts also targeted tables containing medical records.
• The Fix: Patch the application, rotate every database and application secret, restrict database permissions and assume affected data may have been accessed.

Healthcare software just became another database worth stealing.

A cyberattack against Medyc, a medical practice and patient-management platform developed by Polish company Qbusoft, exposed patient information after attackers exploited an SQL injection vulnerability in the application.

The incident was not discovered immediately.

According to an official breach notification issued by an affected medical facility, the attacker exploited the application between August 22 and August 23, 2026.

The intrusion was detected during the night of September 8–9.

That is more than two weeks between exploitation and detection.

The attacker had time.

The entry point was SQL injection

The vulnerability was in the Medyc application’s interface.

The attack used SQL injection, one of the oldest and most well-understood classes of web application vulnerabilities.

The concept is brutally simple.

An application takes attacker-controlled input and passes it into a database query without correctly separating data from SQL instructions.

The database then executes something the developer never intended.

In this case, the attacker apparently used the vulnerable interface to access information inside the Medyc environment.

The affected facility states that an encrypted database archive was successfully transferred outside Qbusoft’s environment.

That is the point where this stopped being an attempted intrusion.

The data left the network.

The database contained patient information

The affected medical provider says the stolen dataset contained:

• names
• surnames
• PESEL numbers
• residential addresses
• telephone numbers
• email addresses

Some of those fields were stored encrypted.

That sounds reassuring until the next part of the investigation.

According to the provider’s notification, Qbusoft advised that the encryption protecting names, surnames and PESEL numbers could potentially be broken easily.

The facility therefore says affected organizations should assume that attackers may have obtained those identifiers in readable form.

This is a classic example of why encryption at rest cannot be treated as a magic shield.

Encryption is useful.

Weak key management, weak application design or compromised application secrets can change the practical value of that protection.

Medical records may also be involved

The situation becomes considerably more serious here.

The affected provider says investigators found evidence that attackers executed scripts targeting database tables containing medical information.

The vendor reportedly assessed it as highly likely that attackers also obtained medical documentation, including hospital-treatment discharge information.

The exact scope is still being investigated.

That distinction matters.

There is a difference between:

confirmed stolen data

and

data that investigators believe was probably accessed.

At the time of publication, the larger claims circulating online about the total number of affected patients should not be treated as independently confirmed.

The technical evidence already available is sufficient without inflating the numbers.

A confirmed SQL injection followed by database exfiltration is already a serious incident.

The attacker didn’t need ransomware

There was no need to encrypt servers.

No dramatic ransomware screen.

No destructive payload.

The attacker simply extracted data.

That is often much harder for an organization to notice.

A ransomware attack announces itself.

Database theft can remain invisible until someone detects an unusual query, an unexpected outbound transfer or a notification from an affected customer.

This incident shows the other side of cybercrime economics.

Medical data is valuable without taking systems offline.

Qbusoft removed the vulnerability

According to the affected facility’s notification, Qbusoft identified and permanently fixed the SQL injection vulnerability on the day the incident was detected.

The provider also reportedly:

• restricted database privileges
• forced rotation of passwords
• rotated technical secrets
• increased monitoring
• preserved forensic evidence
• notified law enforcement
• notified the data protection authority

Those are the right categories of response after an application-layer database compromise.

But there is an important distinction between fixing the vulnerability and removing the attacker.

If an attacker already extracted data, patching the SQL injection doesn’t undo the theft.

Credential rotation matters

A compromised application can expose more than its database.

Modern medical applications usually need credentials for:

• databases
• LDAP or identity services
• backups
• integrations
• APIs
• messaging systems
• external healthcare services

If an attacker gained access to application configuration or database connection information, those credentials should be considered potentially exposed.

That’s why forced rotation is important.

Changing only the database password may not be enough.

Every secret accessible from the compromised application should be reviewed.

The database needs tighter permissions too

The incident also highlights a basic database security principle:

The application should not have more database privileges than it needs.

If the application only needs to read and modify specific tables, it should not have unrestricted administrative access to the entire database.

Least privilege doesn’t prevent SQL injection.

It limits what SQL injection can accomplish.

An attacker who compromises a low-privileged database account should hit another boundary before reaching every table containing sensitive medical information.

Healthcare is becoming a bigger attack surface

Polish healthcare organizations have faced a series of serious cyber incidents in recent months.

On October 1, Poland’s Ministry of Health said that CSIRT CeZ had detected nearly 1,400 incidents by September 2026.

The ministry also said the security recommendations prepared by CSIRT CeZ for healthcare-software providers cover areas including security management, data protection, system architecture, authentication, access control, permissions, monitoring and incident response.

That is significant because healthcare security isn’t just about hospitals.

The software supply chain matters.

A clinic can run a reasonable security program and still inherit risk from a vendor whose application sits between the clinic and its patient database.

This is a software supply-chain problem

Medyc is an example of a dangerous pattern.

A medical organization outsources part of its digital infrastructure to a software provider.

The provider manages the application.

The application manages patient data.

The healthcare organization trusts the provider.

Then an attacker finds one SQL injection.

The attack path becomes:

Internet → vulnerable application → database → patient records.

The clinic doesn’t need to have an exposed database port.

The database can sit safely behind several network controls.

The application is enough.

What administrators should check

Healthcare organizations using Medyc or similar externally managed platforms should verify exactly what data is processed by the vendor.

They should also ask:

• Which application versions are currently deployed?
• When was the vulnerable interface patched?
• What database accounts does the application use?
• What privileges do those accounts have?
• Were all application and database secrets rotated?
• Was outbound database traffic monitored?
• Are database audit logs retained?
• What evidence exists of queries against medical-record tables?
• Which patient records may have been accessed?
• Has the provider completed forensic analysis?
• Has the incident been formally reported to the relevant authorities?

Those questions are much more useful than simply asking whether the application is “secure.”

SQL injection is still winning

This is the embarrassing part.

SQL injection isn’t new.

Developers have been defending against it for decades.

Parameterized queries exist.

ORMs exist.

Input validation exists.

Database privilege separation exists.

Static analysis exists.

Dynamic application testing exists.

Security testing exists.

And yet an SQL injection still managed to become the initial access vector for a healthcare-data breach in 2026.

That isn’t a failure of exotic technology.

It’s a failure to consistently enforce basic application-security controls.

Bugstoday opinion

The most worrying part of this incident isn’t that someone found an SQL injection.

It’s that the vulnerability existed in software sitting directly in the middle of healthcare data flows.

One application bug was enough to turn a medical software platform into a data-exfiltration pipeline.

And the attacker didn’t need ransomware, malware or a sophisticated zero-day.

Just a database query.

This is exactly why healthcare vendors need to treat application security as infrastructure security.

If your application touches patient records, your SQL injection problem is also your customer’s privacy problem.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• Qbusoft / Medyc incident communications
• Odwykowo-Psychiatryczny Ośrodek Leczniczy — Medyc data breach notification
• Polish Office for Personal Data Protection (UODO) — Medyc/Qbusoft investigation
• Centrum e-Zdrowia — CSIRT CeZ cybersecurity incident report
• Polish Ministry of Health — healthcare cybersecurity update, October 1, 2026