Kort sagt: Den, der vil have en PHP-opdatering indspillet, har brug for mere end nye pakker: Afgørende er den rigtige pakkestatus, genstarten af alle PHP-processer og et bevis for det. Netop det leverer vores PHP-patch-service. I får en skriftlig dokumentation pr. server, som I kan fremlægge internt eller over for tredjepart.
Hvorfor en PHP-opdatering alene ofte ikke er nok
Siden 21.10.2026 findes der rettelser til PHP2Shell-sårbarhederne CVE-2026-109618 og CVE-2026-109619. BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler en øjeblikkelig opdatering. I praksis ser vi tre typiske faldgruber.
For det første viser versionsnummeret ikke altid den sande status. Distributioner og hostingudbydere indspiller nogle gange backports; så melder f.eks. Plesk fortsat 8.2.34, selv om pakkestatus er rettet. For det andet kører der efter indspilningen ofte gamle PHP-processer videre. Nye filer på disken beskytter ikke, så længe de gamle workers arbejder i hukommelsen. For det tredje kører der på en server ofte flere PHP-versioner parallelt, og en af dem bliver glemt.
Få PHP-opdateringen indspillet: de rettede versioner
| Gren | Rettet fra | Forudgående status | Bemærkning |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | kontrollér desuden fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | understøttelsen ophører den 31.12.2026 |
| PHP 8.1 og ældre | ingen officielle opdateringer | – | kun minimale kildekode-backports til 7.4, 8.0, 8.1 |
Ved pakker fra distributioner eller hostingudbydere gælder ikke tallet efter »PHP«, men den pakkestatus, som udbyderen bekræfter som rettet. Hvordan I selv kontrollerer det, står under Kontrollér PHP-version og rettelsesstatus korrekt.
Hvordan hjælper PHP SOS konkret?
- Opgørelse: Vi registrerer alle PHP-installationer på serveren, driftsformen (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) og hvilket website der bruger hvilken version.
- Indspille opdateringen: Vi installerer de rettede versioner fra pakkekilden i jeres distribution, jeres panel eller det officielle projekt. Til containere bygger vi nye images sammen med jer.
- Genstart af alle processer: Vi genstarter PHP-FPM, Apache, LiteSpeed eller de pågældende workers fuldstændigt og kontrollerer, at ingen proces er ældre end opdateringen. Baggrunden står på Genstart PHP-FPM og alle workers.
- Funktionskontrol: Vi åbner de vigtigste sider og funktioner, f.eks. forside, login, formularer og kasse, og kontrollerer fejllogs.
- Dokumentation: I får pr. server en protokol med version, pakkestatus, tidspunkt for genstarten og åbne punkter.
Et typisk kontroltrin efter genstarten ser sådan ud:
# Version af PHP-CLI og FPM-binæren (sti afhænger af systemet)
php -v
php-fpm8.3 -v
# Starttidspunkt for FPM-processerne: skal ligge efter opdateringen
ps -o pid,lstart,cmd -C php-fpm8.3
Særtilfælde: paneler, containere og flere PHP-versioner
På servere med Plesk eller cPanel kommer PHP-versionerne ofte fra panelets pakkekilder og ikke fra distributionen. Dér kontrollerer vi hver installeret version for sig, også dem, der netop ikke er knyttet til noget website. Ubrugte, forældede versioner fjerner vi efter aftale, så de ikke ved en fejl bliver aktiveret igen.
I Docker- og Kubernetes-miljøer er en opdatering på værten ikke nok. PHP sidder i imaget, og først et nybygget image med rettet basisstatus, udrullet til alle kørende containere, lukker sårbarheden. Vi kontrollerer her også, om ældre images i registre eller deployments stadig bruges. Enkeltheder står under Patch PHP i Docker-containere.
Ved mod_php kører PHP direkte i Apache-processen. PHP-teamet vurderer risikoen som højest dér. Efter opdateringen skal Apache selv derfor genstartes fuldstændigt; en ren genindlæsning af konfigurationen er ikke i alle tilfælde nok.
Hvad I får fra os
- en patchprotokol pr. server: installerede pakker, versioner, kilde, tidspunkt
- beviset for, at alle PHP-processer er genstartet
- en liste over kontrollerede websites og funktioner
- henvisninger til systemer, som ikke kunne rettes, med begrundelse
- en anbefaling til den videre vej, f.eks. ved PHP 8.2 på grund af den nære udløbsdato for understøttelsen
Hvad vi har brug for fra jer
- Adgang: SSH med administratorrettigheder eller panel-adgang (Plesk, cPanel o.l.)
- Vedligeholdelsesvindue: hvornår en kort genstart må finde sted
- Kontaktperson: til opfølgende spørgsmål og til godkendelsen efter funktionskontrollen
- Backups: bekræftelse på, at en aktuel sikkerhedskopi findes, eller opgaven at oprette en inden da
- Oplysninger om egenudviklinger: særlige PHP-udvidelser eller konfigurationer, som skal tages hensyn til
Ved shared hosting uden egen serveradgang kan vi ikke selv rette. Vi hjælper jer så med at stille hostingudbyderen de rigtige spørgsmål og vurdere svaret.
Hvad vi ikke lover
Patch-servicen lukker den kendte sårbarhed. Den besvarer ikke, om serveren allerede var kompromitteret før opdateringen, og fjerner ingen indsmuglet skadelig software. Hvis I vil vide det, er PHP2Shell-akuthjælpen med sporsøgning den passende opgave.
For PHP 8.1 og ældre findes der ikke længere officielle opdateringer. Her gennemfører vi midlertidige foranstaltninger og anbefaler migrering til en understøttet version. En kompatibilitetstilsagn for jeres CMS giver vi ikke ud fra hukommelsen, men kontrollerer det ud fra producentens systemkrav.
Ofte stillede spørgsmål
Hvorfor viser min server stadig den gamle PHP-version efter opdateringen?
Det kan have to årsager. Enten har distributionen indspillet en backport, og så forbliver versionsnummeret det samme, selv om pakkestatus er rettet. Eller også kører gamle PHP-processer stadig i hukommelsen og skal genstartes.
Hvilke PHP-versioner lukker PHP2Shell?
Sårbarheden er rettet i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35, offentliggjort den 21.10.2026. Ved distributionspakker gælder den pakkestatus, som udbyderen bekræfter som rettet.
Kan opdateringen lægge mit website ned?
En opdatering inden for samme hovedversion, f.eks. fra 8.3.35 til 8.3.36, er som regel uproblematisk. En kort genstart af PHP-processerne er dog nødvendig. Vi afstemmer tidsvinduet med jer og kontrollerer siderne bagefter.
Er alt klaret med rettelsen?
For selve sårbarheden ja, så snart alle processer er genstartet. Om nogen allerede var trængt ind før rettelsen, viser rettelsen ikke. Det kræver en særskilt kontrol.