Kort sagt: Hvis I har mistanke om, at jeres server er blevet hacket via PHP2Shell, så kontakt os nu. Er I berørt? Ring til os. Vi hjælper. Vi overtager fra den første besked inddæmningen, sikrer sporene, lukker sårbarheden, fjerner skadelig kode og dokumenterer hændelsen, indtil den er afsluttet.
Slet intet og opsæt intet på ny nu. Slettede filer og overskrevne logs er de spor, der viser, om og hvordan nogen er trængt ind. Tag om nødvendigt serveren af nettet, men lad den være uændret. Meld en nødsituation, så fortæller vi jer det næste skridt.
Er I berørt? Tegn på, at PHP2Shell allerede er blevet udnyttet
PHP2Shell er navnet på to kritiske sårbarheder i selve PHP, som gør det muligt for angribere at køre skadelig kode på afstand uden login. Der findes endnu ikke noget entydigt fingeraftryk. Derfor tæller det, serveren gør, ikke det, en scanner finder. Tegn på et indbrud er:
- Webserver- eller PHP-FPM-processer, der starter en shell som
shellerbash. Det er et stærkt advarselssignal. - Nye eller ændrede PHP-filer i upload-, cache- eller temp-mapper, som ingen har oprettet.
- Cronjobs, tjenester eller SSH-nøgler, som I ikke kender.
- Udgående forbindelser til ukendte mål, pludselig høj belastning eller usædvanlig datatrafik.
- Forespørgsler i logs fra den 17.10.2026, især påfaldende uploads og sessionsforespørgsler før rettelsen blev indspillet.
- Meddelelser fra hostingudbyder, browser eller søgemaskine om spam, malware eller omdirigeringer.
Mere herom finder I under Er vi allerede kompromitteret?. Hvis der ikke er nogen tegn, er det ikke noget bevis for en ren server. Det betyder blot, at der indtil nu ikke er opdaget noget.
Hvad I gør med det samme
- Ændr intet. Slet ingen filer, indspil ingen backup, foretag ingen nyinstallation, før der er sikret.
- Sikr logs. Bed jeres hostingudbyder eller it-afdeling om ikke at overskrive adgangs-, fejl- og systemlogs. Fagpressen anbefaler at gemme logs fra den 20.10.2026.
- Beslut tilgængeligheden. Hvis data kan sive ud, eller besøgende kan være i fare, så tag siden af nettet eller sæt den i vedligeholdelsestilstand.
- Saml adgangene. Notér, hvem der har adgang til server, panel, CMS og database. Adgangskoder ændrer I først efter aftale og fra en ren enhed.
- Informér de relevante personer. Ledelsen, databeskyttelsesrådgiveren og, hvis I har en police, forsikringsselskabet.
- Ring til os eller skriv. Jo tidligere vi kender situationen, desto mere kan dokumenteres.
Hvordan hjælper PHP SOS konkret?
Vi arbejder på afstand, uden transport, i hele Tyskland og Europa.
- Danne overblik over situationen: Vi afklarer, hvilke systemer der kører, hvilken PHP-driftsform der anvendes, hvad der er opdaget, og hvilke data der kan være berørt.
- Sikre og lukke: Vi sikrer filer, database og logs og fastlægger tilstanden før enhver ændring. Derefter lukker vi sårbarheden med rettelsen eller, hvis den endnu ikke er mulig, med midlertidige foranstaltninger, og genstarter alle PHP-processer.
- Kontrollere og rense: Vi leder efter webshells, bagdøre, cronjobs og fremmede adgange og fjerner dem eller bygger tilstanden op på ny fra pålidelige kilder. Fremgangsmåden beskriver Få malware og webshells fjernet.
- Hærde og rapportere: Vi ændrer de berørte hemmeligheder, efterfølger beskyttelsesforanstaltningerne og leverer en rapport, der skelner mellem dokumenteret, sandsynligt og ukendt.
Vokser hændelsen ud over én server, går vi over til struktureret incident response. Kræves der beviser, der kan holde i retten, inddrager vi it-forensik.
Hvorfor en rettelse alene ikke er nok efter et angreb
Sårbarhederne ligger i PHP-fortolkeren, ikke i CMS'et. PHP-projektet har den 21.10.2026 udgivet versionerne 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Den, der opdaterer bagefter og har genstartet alle workers, er beskyttet mod nye angreb ad denne vej. Det, en angriber har lagt ud tidligere, bliver dog liggende: en webshell, en ekstra konto, en planlagt opgave. Netop derfor er dagene mellem den 17. og den 21.10. særligt vigtige.
Dertil kommer et andet punkt: En webshell er ofte kun det første skridt. Den, der kunne køre kode på webserveren, kunne også læse konfigurationsfiler og derfra overtage adgange til database, mail og API. Disse hemmeligheder skal udskiftes, ellers forbliver døren åben, selv om PHP er patchet. Hvordan I kontrollerer filer og tidspunkter fornuftigt, beskriver vejledningen om at opdage webshells.
Anmeldelsespligt og dokumentation
Kan personoplysninger være berørt, kan en anmeldelse til tilsynsmyndigheden inden for 72 timer blive nødvendig. Uret løber fra kendskabet, ikke fra afslutningen af undersøgelsen. Om jeres tilfælde er anmeldelsespligtigt, afgør databeskyttelsesrådgiveren eller en advokat; vi yder ikke juridisk rådgivning. Vores dokumentation leverer grundlaget hertil. Mere om fristen står under GDPR-anmeldelsespligt inden for 72 timer, skridtene derefter i tjeklisten efter et hack.
Hvad I bør sende til os
- Beskrivelse af, hvad der er påfaldende siden hvornår, og hvem der har bemærket det
- Type af server: egen server, managed server eller hostingpakke, dertil hostingudbyderen
- Resultatet af
php -vog, hvis det er kendt, driftsformen (PHP-FPM, mod_php, LiteSpeed) - Tidspunktet for PHP-opdateringen, hvis den allerede er indspillet
- Adgang til serveren eller tilladelse til at tale med jeres hostingudbyder
- En kontaktperson med beslutningskompetence til nedlukning og genstart
Hvorfor PHP SOS
Vi arbejder Made in Germany og har sammen med vores partnernetværk af cyberprofessionelle i over 25 år specialiseret os i it-sikkerhed. I har én kontaktperson, der følger jer fra den første besked til afslutningen. Alt, hvad vi gør, bliver dokumenteret, så I kan dokumentere det over for ledelse, forsikringsselskab og myndigheder. Vi lover ikke noget, som ingen kan holde: Hvis logs mangler, siger vi det åbent, og vi angiver, hvad der er dokumenteret, og hvad der forbliver formodning.
Er I berørt? Ring til os. Vi hjælper.
Vent ikke, til mistanken bliver til vished. Ring til os eller skriv på WhatsApp. Vi overtager fra den første besked og bliver ved, indtil hændelsen er afsluttet og dokumenteret. Meld en nødsituation nu.
Ofte stillede spørgsmål
Er det nok at opdatere PHP, hvis min server måske allerede er blevet hacket?
Nej. Opdateringen lukker sårbarheden, men fjerner ikke skadelig software, der allerede er blevet indsmuglet, og den beviser ikke, at der ikke er sket noget før. Efter rettelsen skal serveren kontrolleres for spor af et indbrud.
Hvordan genkender jeg et vellykket PHP2Shell-angreb?
Der findes ingen offentliggjorte, bekræftede Indicators of Compromise. Opdagelsen bygger på adfærd: webserverprocesser, der starter en shell, nye PHP-filer i upload- eller cachemapper, ukendte cronjobs eller SSH-nøgler og påfaldende udgående forbindelser.
Skal jeg tage serveren af nettet, hvis jeg har mistanke om et indbrud?
Det er ofte rigtigt, for BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler endda at tage webserveren midlertidigt af nettet, hvis opdateringen ikke kan gennemføres med det samme. Det vigtige er ikke at slette noget og at bevare logs og filer, så hændelsen kan opklares.
Skal jeg underrette databeskyttelsesmyndigheden efter et PHP2Shell-angreb?
Hvis personoplysninger kan være berørt, kan en anmeldelse inden for 72 timer være nødvendig. Beslutningen træffer I sammen med jeres databeskyttelsesrådgiver eller en advokat; vi leverer de tekniske fakta hertil.
Er der virkelig allerede blevet hacket servere via PHP2Shell?
Ifølge mediernes rapportering var der fra den 17.10.2026 de første observerede angrebsforsøg, og Cloudflare rapporterede om observerede angrebsforsøg. BSI meldte i første omgang ingen bekræftede vellykkede angreb i bredden. I det enkelte tilfælde kan det kun afklares på selve serveren.