Kort sagt: Ved websitesikkerheden hos et apotek handler det om sundhedsdata: Den, der forudbestiller et lægemiddel eller fotograferer en recept, afslører noget om sit helbred. Afklar, hvem der driver jeres webserver, lad PHP-rettelse og genstart bekræfte, og hold øje med skjult lægemiddelreklame, som angribere gerne smugler ind på apotekers sider.
Hvilke PHP-systemer apoteker bruger
Mange apoteker har et website med åbningstider, henvisning til vagtapotek og en formular til forudbestilling. Ofte kommer en funktion til upload af recept-fotos eller medicinplaner til, dertil henvendelser om budtjeneste og tider til rådgivning eller vaccinationer. Netapoteker og apoteker med onlinehandel driver desuden en shop, f.eks. på WooCommerce eller Shopware 6.
Nogle sider stammer fra websitepakker fra samarbejdsgrupper eller specialiserede udbydere, andre har et lokalt bureau bygget. For PHP2Shell afgøres det heraf, hvem der driver serveren og dermed er ansvarlig for PHP-rettelsen.
Særligt oplysende er henvendelser om budtjeneste. De forbinder bopælsadresse, telefonnummer og lægemiddel, ofte fra ældre eller plejekrævende mennesker. Den, der opsnapper sådanne datasæt, ved, hvem der bor alene, hvilke midler der regelmæssigt bruges, og hvornår der leveres. Det gør dem interessante for svindlere, der målrettet henvender sig til ældre mennesker.
Sundhedsdata: hvorfor allerede en forudbestillingsformular er følsom
Navn plus lægemiddel giver en sundhedsoplysning. Sådanne oplysninger hører til de særlige kategorier af personoplysninger efter art. 9 GDPR. For apotekere gælder desuden en tavshedspligt, hvis overtrædelse efter § 203 StGB (den tyske straffelov) kan være strafbar.
På webserveren ligger sådanne data flere steder: i formular-pluginets database, i uploadede recept-fotos, i mailkøer og i shoppen med bestillingshistorik. Den, der via PHP2Shell kan udføre kode, kommer som regel til alt dette, uden at skulle logge ind.
Apotek og websitesikkerhed: hvad et angreb forårsager
- Dataudslip: Forudbestillinger og recept-fotos tillader slutninger om sygdomme. Risikoen for de berørte er høj, anmeldelsespligter efter GDPR ligger nær. 72-timersfristen vurderer I sammen med jeres databeskyttelsesrådgiver.
- Pharma-spam: Angribere smugler skjulte sider ind med reklame for receptpligtige midler. Søgemaskiner nedgraderer siden eller viser en advarsel, som beskrevet i vejledningen Fjern Google-advarsel.
- Tabte forudbestillinger: Falder formularen ud eller omdirigerer den, står kunder ved disken, og lægemidlet er ikke bestilt.
- Manipuleret shop: Ændret kode i bestillingsprocessen kan opsnappe betalingsdata eller sende kunder til forfalskede sider.
En opdatering af shoppen eller CMS'et lukker ikke PHP2Shell. Sårbarheden er først udbedret med PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller en backport bekræftet af udbyderen, og først efter genstart af alle PHP-processer.
Ansvarshullet i apoteket
| Område | Typisk ansvarlig | Ofte uafklaret |
|---|---|---|
| Varedisposition, kasser, TI | Softwarehus eller apotekets it | Forbindelse til onlineshoppen |
| Website fra samarbejdspakke | Pakkens udbyder | skriftlig patchbekræftelse |
| Eget website eller shop | Bureau og hostingudbyder | hvem der opdaterer og genstarter PHP |
I filialforbund kommer det til, at hver filial kan have egne formularer eller domæner, som ingen fører central oversigt over.
Udform forudbestilling og recept-upload datasparsomt
Mange apotekerformularer gemmer mere end nødvendigt. En forudbestilling har brug for navn, kontaktmulighed og det ønskede præparat, ikke fødselsdato, adresse eller diagnose. Recept-fotos bør ikke ligge varigt i den offentligt tilgængelige upload-mappe, men slettes efter afhentningen.
Undersøg desuden, hvor formulardataene sendes hen. Havner hver forudbestilling som en ukrypteret mail i en fælles postkasse, som mange medarbejdere har adgang til, er postkassen lige så beskyttelsesværdig som serveren. Og hvis et formular-plugin desuden lægger hver henvendelse i databasen, vokser der dér for hver måned et arkiv med sundhedsdata, som ingen har brug for.
Jo mindre der ligger på webserveren, desto mindre er skaden, hvis den alligevel kompromitteres. Beslutningen om opbevaringsfrister træffer I sammen med jeres databeskyttelsesrådgiver.
De første timer for apotekets ledelse
- Spørg skriftligt hos webserverens driftsansvarlige om PHP-patchstatus og genstart.
- Uden bekræftelse: Slå forudbestillingsformular og recept-upload fra og omstil til telefon. En henvisning på forsiden er nok.
- Lad logs fra 20.10.2026 sikre.
- Kontrollér i Google Search Console, om ukendte sider eller sikkerhedsproblemer meldes.
- Lad gamle recept-fotos og formularindtastninger, der ikke længere er brug for, slette efter aftale med databeskyttelsesrådgiveren.
Hvordan hjælper PHP SOS konkret?
- Vi afklarer med pakkeudbyder, bureau eller hostingudbyder, hvem der patcher PHP, og indhenter bekræftelsen med pakkestatus.
- Vi kontrollerer website og shop for webshells, indsmuglet pharma-spam og ændret bestillingskode og fjerner fundet malware.
- Vi viser, hvor sundhedsdata ligger på serveren, og hjælper med at begrænse opbevaringstid og uploads.
- Vi dokumenterer fund, så jeres databeskyttelsesrådgiver kan vurdere anmeldelsespligten.
Ofte stillede spørgsmål
Er vores varedisposition berørt af PHP2Shell?
Apotekets varedisposition og adgangen til telematikinfrastrukturen kører som regel adskilt fra websitet. Berørt er PHP-webservere, altså oftest website, forudbestillingsformular og onlineshop. Om der findes grænseflader mellem shop og varedisposition, bør jeres it-leverandør undersøge.
Vores website stammer fra en byggekasse fra vores samarbejdsgruppe. Hvem er ansvarlig?
Ved websitepakker fra samarbejdsgrupper, grossister eller specialiserede udbydere driver oftest udbyderen serveren. Så ligger PHP-rettelsen hos denne. Spørg skriftligt om status, for ansvaret for jeres kunders data forbliver hos jeres apotek.
Hvad er et pharma-hack?
Sådan kaldes angreb, hvor der på et kompromitteret website indsmugles skjulte sider eller links til reklame for lægemidler. Besøgende ser ofte intet af det, søgemaskiner derimod gør. For et apotek er det særligt vanskeligt, fordi sådant indhold dukker op under et troværdigt navn.