Healthcare Bug Bounties Should Start Before a Breach

A healthcare bug bounty gives authorized researchers a way to find and report vulnerabilities before criminals exploit them. It works only when the vendor has already published a safe testing scope, assigned people to assess reports, and funded fixes and rewards. The reported SQL injection in Poland’s Medyc software makes the case for doing that work now. Whether a bounty would have prevented this particular breach remains unknown.

One Polish clinic has now told its patients that two separate software suppliers it used, MyDr and Qbusoft’s Medyc, were breached. Its MyDr notice and Medyc notice describe each incident separately. A clinic can face overlapping supplier risks without the intrusions sharing a technical cause.

What do we know about the Medyc incident?

The clinic’s notice attributes the technical findings to Qbusoft’s investigation with forensic experts. It says an attacker used SQL injection in a Medyc application interface on 22–23 August 2026 and transferred an encrypted database archive outside Qbusoft’s environment. The intrusion was detected during the night of 8–9 September. According to the clinic, Qbusoft fixed the flaw on the day it detected the attack, restricted database permissions, rotated technical secrets, and reported the matter to police and Poland’s data-protection authority.

For patients of the clinic’s day addiction-treatment ward, the notice says the downloaded data provably included names, Polish PESEL identification numbers, addresses, phone numbers, and email addresses. The notice says names and PESEL numbers were encrypted at rest, but Qbusoft advised the clinic to assume attackers could readily decrypt those two fields and obtain them in plain text. Scripts also targeted medical-data tables, so the clinic says discharge summaries were very probably taken. The notice does not confirm that discharge summaries were copied.

The Polish data-protection authority, UODO, said on 25 September that media reports suggested as many as five million people might be affected and that it planned an inspection of Qbusoft. That is not a verified incident count. The authority also repeated the digital minister’s 24 September statement that Qbusoft had not reported to CERT Polska or the healthcare-sector CSIRT by then. The clinic’s account of reports to police and UODO names different recipients; both accounts can therefore be true.

Zaufana Trzecia Strona’s report links the Medyc story to the actor behind the earlier MyDr case. Public authorities have not established that attribution in the sources available for this article. The important operational fact needs no attacker identity: a SQL-injection flaw in a Medyc application interface reportedly enabled data to leave the vendor’s environment.

Why set up disclosure and rewards before the first report?

SQL injection is the kind of application defect an external researcher might identify without privileged access. A program can tell that researcher which system is authorized for testing, how to prove a finding without opening real patient records, where to send it, and when to expect a response. NIST’s disclosure guidance recommends a formal process to accept, assess, manage, and communicate about vulnerability reports. It does not promise that such a process will find every flaw.

Start with a vulnerability disclosure program: public contact, scope, rules, safe-harbor terms, a staffed intake queue, and a route from accepted report to fix. Then offer a paid bug bounty when the team can handle the additional reports and has an approved reward budget. The reward creates a reason for researchers to spend time on your product; the intake and remediation process makes that attention useful. If your organization can support both now, publish both now. An incident is a poor moment to write your first rules of engagement.

None of the public Medyc accounts shows that a good-faith researcher found this SQL injection earlier, tried to report it, or would have found it under a bounty. A program also would not replace secure query construction, code review, penetration testing, logging, least-privilege database access, or incident response. It gives researchers a route to report a flaw while there is still time to fix it.

How do you let researchers test without exposing patients?

A medical-software program should make the boundary concrete. The US Department of Health and Human Services disclosure policy provides a useful pattern: test only listed systems, use an exploit only as far as needed to confirm a flaw, stop on sensitive data, and never exfiltrate records. Those are policy choices a vendor can adapt to its own architecture and legal advice, not permission to test another organization’s systems.

Doctolib’s public bug bounty is a healthcare example with an explicit scope, rewards, and testing conditions. A smaller vendor need not copy its reward amounts or program volume. It can copy the discipline of publishing where researchers may work and how to avoid touching patient care.

Run one internal rehearsal before inviting the public: submit a synthetic report, follow its receipt and assignment, verify the response clock, make a fix, and send the researcher a closure note. Resolve any missed handoff before inviting more researchers.

Which medical-software vendors should consider this now?

A supplier holding records for many independent clinics has a responsibility to each of them: one application issue can force each clinic to assess its own patient exposure. Vendors of electronic medical records, practice management, and patient-booking software should publish a disclosure route before they need one. Hosted products and clinic-managed deployments may need different testing boundaries; each program must name only assets the vendor owns or is authorized to have tested.

For a vendor’s engineering or security lead, the useful question is: Could a researcher find the right contact today, make a patient-safe report, and see it reach a person empowered to fix the defect? If the answer is uncertain, map the systems and assign that owner now. A clinic buying software can ask the same question alongside its own supplier-risk review. The earlier MyDr analysis covers the broader limits of disclosure channels across several breach types; the Medyc case sharpens the argument for deciding which product interfaces outside researchers can safely test and report on.

How can Kit help run a healthcare disclosure program?

Kit gives a security team a public reporting portal and program setup, a generated security.txt, a published scope, report assignment and triage, researcher communication, and SLA tracking. A team that chooses to pay bounties can define reward ranges, discuss proposals, record approval, and track the payment handoff. Start with an owned scope and a patient-safe testing policy; then use a synthetic report to check the entire path from submission to closure.

Kit does not scan for SQL injection, secure database queries, or prove that a vendor is breach-free. Those remain engineering and incident-response work. Kit helps an outside researcher reach the team responsible for a fix, with a record of who owns the report and what happens next. For the detailed setup, use the vulnerability disclosure program guide.