Assistance Publique – Hôpitaux de Paris (AP-HP) runs the Paris region's public hospitals and describes itself as Europe's largest university hospital centre. On October 7, 2026 it confirmed that attackers stole identity data for 1,015 patients. They got in through the online patient service of SRD Restauration, a meal-ordering product published by Dedalus and used in 23 AP-HP hospitals. The stolen data includes names, birth-related information and internal patient ID numbers. AP-HP says no medical, banking, administrative or contact data appears to be affected. The 1,015 figure is provisional. It covers only the records authenticated so far, and the attackers claim on a cybercriminal forum to hold data on more patients plus some staff accounts. All eight sources for this brief are secondary reporting. Every one of them relies on AP-HP's own October 7 statement, and none adds independent technical detail.
What Happened
- September 24, 2026: AP-HP learned that data presented as coming from its systems was being offered for sale on a cybercriminal forum. Every source agrees on this date.
- The intrusion: AP-HP's analysis places the break-in "a few days" before the alert. The exact date has not been disclosed (Ostraca).
- September 25: AP-HP filed a criminal complaint the day after the alert (France 3; Ostraca gives the specific date).
- Late September to early October: AP-HP's digital services department investigated over several days with partners and the authorities, then confirmed that part of the published data came from its systems (Cyberiack, Cyberattaque.org).
- October 7: AP-HP published its public confirmation.
Reports describe the forum activity differently. Cyberiack and What's up Doc say the data was offered for sale and that a first set was published. France 3 says the data was published on the forum. In both versions, at least part of the data is now circulating publicly.
What Was Taken
Confirmed by AP-HP (1,015 patients): - Last name and first name - Birth-related information. AP-HP has not said whether this means full date of birth, place of birth, or both. - Internal patient identifier
Not affected, according to AP-HP: direct or indirect medical data, administrative or banking information, and contact details. AP-HP gives two reasons: what the software holds, and what has been published so far. Cyberiack points out that AP-HP phrased this conditionally ("would not be affected") because the investigation is ongoing.
Claimed but not confirmed: AP-HP itself notes that the forum post claims "a larger number of patients and data relating to certain professional accounts" on the software (What's up Doc). The attackers have not given a figure, and AP-HP has not confirmed these claims (Ostraca). So the scale is at least 1,015 patients, with an unknown upper bound. Readers should not treat 1,015 as the final count.
No source names the threat actor or the forum.
Why It Matters
Vendor-supplied software is an attack surface. The breach did not touch AP-HP's core electronic patient record. What's up Doc notes that this record is also supplied by Dedalus. The attackers instead went through a low-priority catering module with an internet-facing patient portal. Software like this often gets less security review than clinical systems, yet it still holds patient identities across dozens of sites.
The stolen data is useful to fraudsters. Names, birth details and a hospital-internal patient ID make credible pretexts for hospital-themed phishing and phone scams. These are messages like "Your AP-HP stay: please confirm your identity" or "billing issue for your hospitalisation." ITonline and ID Protect both flag targeted phishing and identity fraud as the likely follow-on risk. The internal patient ID is a particular concern because patients may treat it as a sign that a message is legitimate.
Staff accounts may extend the risk. If the claim about professional accounts holds, stolen credentials or account data could enable further access or social engineering against hospital staff. AP-HP's password reset suggests it took this possibility seriously.
Dedalus customers elsewhere should check their exposure. No source says the vulnerability was specific to AP-HP's deployment. Ostraca notes that it is unknown whether the root cause lies in the product itself, its configuration, its hosting or access management. Other hospitals running SRD Restauration with a patient-facing online module should assume they may be exposed until Dedalus clarifies.
The Attack Technique
AP-HP has said little about the technical cause. What it has said:
- Entry point: a fraudulent intrusion into the online service that lets hospitalised patients reach SRD Restauration and choose meals for their stay (France 3, quoting AP-HP).
- Action on objective: files were extracted from a module of the SRD Restauration software (Ostraca, LeBigData).
- Root cause: not disclosed. Sources differ on who fixed it. Ostraca and LeBigData say the vendors ("fournisseurs") patched the vulnerabilities. What's up Doc says AP-HP states corrective measures were applied. These accounts are compatible but leave unclear whether the flaw was in Dedalus's product or in how it was deployed. LeBigData describes "SRD restauration" as a company. Every other source identifies Dedalus as the publisher, and this brief follows that majority.
AP-HP's containment steps: - The online meal-selection service was shut down until further notice. - User passwords were reset. - The vulnerabilities that may have allowed the intrusion were remediated. - Other security measures were introduced (France 3, What's up Doc).
No CVE, indicators of compromise or attack-chain details have been published.
What Organizations Should Do
- List every internet-facing service that touches patient identity data, including non-clinical ones. Catering, parking, Wi-Fi portals, appointment kiosks and entertainment systems often pull patient demographics from the hospital information system. Each one needs the same exposure review as the electronic patient record.
- Contact Dedalus if you run SRD Restauration. Ask whether the flaw was in the product or in deployment, whether a patch or configuration guidance exists, and whether other customers' patient portals were affected. Until you have answers, consider limiting the patient-facing module to the internal network or disabling it.
- Collect only the data each system needs. A meal-ordering system needs a room number, dietary constraints and perhaps a first name. It should not hold full birth details and permanent patient IDs. Pass short-lived, purpose-specific tokens to ancillary systems instead of master identifiers.
- Reset and review vendor-application credentials after any third-party incident. Follow AP-HP's lead: rotate passwords for staff accounts on the affected application. Check whether any of those credentials are reused elsewhere, enforce MFA, and audit for unusual logins in the weeks before discovery.
- Watch criminal forums for your own data. AP-HP learned of the breach from a forum listing, not from its own detection. Use threat-intelligence monitoring for your organisation and key vendor names, and log and alert on bulk data reads from ancillary applications so that exfiltration is caught before a sale listing appears.
- Warn patients before the phishing starts. Tell affected patients clearly what data was stolen. State that the hospital will never ask for banking details or passwords by email or phone, and explain how they can verify any message that claims to come from the hospital.
Sources: AP-HP: Data of 1,015 patients stolen via meal-ordering software Cy... | Des données d'identité de plus de 1000 patients de l'APHP dérobées... | Die AP-HP bestätigt ein Datenleck bei Patienten - ITonline | AP-HP : des données de patients volées via… le logiciel de commande... | AP-HP : 1 015 patients exposés après le piratage d’un logiciel util... | Fuite de données à l’AP-HP : 1 015 patients concernés, quels risque... | Fuite AP-HP 2026 : 1 015 patients via un logiciel de repas | AP-HP piratée, les données de 1 015 patients volées : voici ce que...