Kort sagt: Efter PHP2Shell er flere meddelelser om PHP sandsynlige, fordi der allerede to dage efter patchen kom en tredje henvisning, et fuldstændigt advisory endnu mangler, og distributioner leverer deres pakker forskudt. Den, der nu indretter et fast forløb for observation, vurdering, opdatering og genstart, reagerer på den næste nye PHP-sikkerhedssårbarhed på timer i stedet for dage.
Patchen var ikke slutningen på historien
Den 21. oktober 2026 lukkede PHP-projektet de to kritiske sårbarheder CVE-2026-109618 og CVE-2026-109619 med versionerne 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Mange ansvarlige satte derefter et flueben. To dage senere, den 23. oktober, fulgte dog endnu en henvisning fra php.net om CVE-2026-115560.
Denne tredje henvisning angår kun en usædvanlig session-konfiguration. Men den viser et mønster, man kender fra store sikkerhedssager: Når en komponent pludselig står i rampelyset, ser mange fagfolk samtidig nærmere efter. Om der opstår flere sårbarheder heraf, ved ingen i dag. Sandsynligt er dog, at nyhedsstrømmen ikke ebber ud.
For jer som driftsansvarlige betyder det: Planlæg opfølgende meddelelser, i stedet for at lade jer overraske af hver enkelt. Det hidtidige forløb af begivenhederne opsummerer vores PHP2Shell-kronologi.
Hvorfor flere meddelelser er sandsynlige
Følgende vurdering bygger på offentligt kendte fakta. Den er ikke en forudsigelse af konkrete sårbarheder.
- Et advisory mangler endnu. php.net behandler CVE-2026-115560 i den regulære udgivelsescyklus og har varslet at offentliggøre det fuldstændige advisory med den næste udgivelse. Indtil da gælder
session.upload_progress.enabled=0som afhjælpning. - Detaljerne var tidligt offentlige. Ifølge flere rapporter blev enkeltheder kendt, før embargoen udløb. Ifølge rapporter har watchTowr efter egne oplysninger genskabt CVE-2026-109618. Sådant arbejde fører ofte til opfølgende spørgsmål om tilstødende kodesteder.
- Distributioner leverer forskudt. Ubuntu forsynede den 21. oktober de aktuelle udgivelser med USN-8948-1 og eftersendte med USN-8948-2 rettelser til 14.04 til 20.04 via Ubuntu Pro. Red Hat skrev i sit bulletin, at nogle opdateringer var tilgængelige, flere under udarbejdelse.
- Udviklingsversionen er berørt. Ifølge php.net indeholder også PHP 8.6.0 RC4 rettelserne. Den, der tester forhåndsversioner, må også opdatere disse miljøer.
- Ældre versioner forbliver åbne. Til PHP 8.1 og ældre findes der kun minimale kildekode-backports. Enhver udbyder, der leverer sådanne versioner, melder sin status selvstændigt og på egne tidspunkter.
Sådan når en ny PHP-sikkerhedssårbarhed jer
Meddelelser kommer ad forskellige veje og med forskellig pålidelighed. Rækkefølgen er næsten altid den samme: først PHP-projektet, så distributioner og hostingudbydere, derefter myndigheder og medier.
| Kilde | Hvad I erfarer dér | Hvor pålidelig |
|---|---|---|
| php.net | Berørte grene, rettede versioner, midlertidige foranstaltninger | Primær kilde |
| Ubuntu, Debian, Red Hat | Pakkestatus pr. udgivelse, tidspunkt for levering | Primær kilde for jeres system |
| Hostingudbydere og panel-udbydere | Status for egne PHP-builds | Kun bindende, hvis skriftlig |
| BSI, CERT-Bund | Vurdering af situationen, advarselsniveau, anbefalinger | Myndighedsvurdering |
| Fagpresse og sikkerhedsfirmaer | Angrebsobservationer, tal, baggrund | Nyttigt, markér som rapport |
Vigtig er forskellen mellem „der findes en patch“ og „mit system har patchen“. Det første udsagn står på php.net. Det andet må I selv dokumentere for hver server.
Abonnér på meddelelserne fra php.net og jeres distribution via RSS eller e-mailliste, og videresend dem til en fælles postkasse eller en kanal, som mere end én person læser. Ferie og sygdom er de hyppigste årsager til forsinkede opdateringer.
Hvad I bør forberede før den næste meddelelse
Erfaringen fra PHP2Shell viser, hvor tid går tabt: ved søgningen efter servere, ved afklaring af ansvar og ved den glemte genstart. Alt det kan klares på forhånd.
- Inventar: En liste over alle servere og websites med PHP-gren, driftsform (PHP-FPM, mod_php, LiteSpeed) og pakkekilde. Uden denne liste begynder hver meddelelse med søgning. Hvordan det lykkes, beskriver indlægget Inventar over alle websites og servere.
- Ansvar: For hvert system er det fastlagt, hvem der patcher, hvem der genstarter, og hvem der godkender. Ved hostingudbydere og bureauer hører det med i kontrakten.
- Vurderingsraster: Tre spørgsmål er nok til den første vurdering. Er vores gren berørt? Bruger vi den berørte funktion eller driftsform? Findes der en patch eller kun midlertidige foranstaltninger?
- Testvej: Et staging-miljø, hvor en PHP-opdatering kan afprøves på kort tid.
- Dokumentation: Et fast format, hvori pakkestatus, fund i changelog og tidspunkt for genstart noteres.
Hvordan et sådant forløb fungerer som rutine i stedet for brandslukning, står under Patchmanagement som proces. Baggrund om PHP-projektets håndtering af sårbarheder giver siden Sådan behandler PHP-projektet sikkerhedssårbarheder.
Egen konfiguration som tidligt varslingssystem
En del af de opfølgende meddelelser angår kun bestemte indstillinger. CVE-2026-115560 er et eksempel: php.net nævner som forudsætning, at en applikation omstiller session-serializeren under kørslen, mens upload progress er aktiv. Applikationer, der aldrig gør det, er ifølge php.net ikke berørt.
Den, der kender sin effektive konfiguration, kan vurdere sådanne meddelelser hurtigere. Notér derfor for hver gren, hvilke værdier der er sat på serversiden, og hvilke applikationer der må overskrive dem. En enkel afstemning af de aktive indstillinger hjælper allerede:
# Effektive værdier fra kommandolinjen (webkonfigurationen kan afvige)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Satte værdier i FPM-poolene (stien er forskellig fra distribution til distribution)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
Kommandolinjen viser ikke nødvendigvis, hvad der gælder i webkonteksten. Klarhed skaber pool- eller VirtualHost-konfigurationen og, kortvarigt og beskyttet, en phpinfo-side.
En yderligere fordel: Den, der ved, hvilke midlertidige værdier der stadig er sat fra PHP2Shell-ugen, kan bevidst kontrollere dem efter den næste regulære udgivelse. Nogle indstillinger, f.eks. deaktiveret upload progress, kan varigt forblive fornuftige. Andre, som meget knappe upload-grænser, bør I efter aftale med fagafdelingerne igen tilpasse til det reelle behov.
Hvordan hjælper PHP SOS konkret?
- Vi følger meddelelserne fra php.net, distributioner og BSI og vurderer nye henvisninger for jeres konkrete systemer.
- Vi udarbejder sammen med jer inventaret over alle PHP-installationer og fastlægger ansvarsområder for hver server.
- Som led i en security-vedligeholdelsesaftale indspiller vi opdateringer, genstarter alle processer og dokumenterer status.
- Ved meddelelser uden patch indsætter vi midlertidige foranstaltninger, så de ikke kan overskrives, og kontrollerer dem bagefter.
Ofte stillede spørgsmål
Findes der allerede en ny PHP-sikkerhedssårbarhed efter PHP2Shell?
Den 23. oktober 2026 offentliggjorde php.net en henvisning til CVE-2026-115560. Kodeudførelse er ifølge den kun mulig ved en usædvanlig session-konfiguration. Et fuldstændigt advisory skal følge med den næste regulære udgivelse.
Skal jeg handle straks ved hver ny meddelelse?
Ikke enhver meddelelse kræver samme hast. Afgørende er alvorlighedsgrad, om jeres konfiguration er berørt, og om en patch er tilgængelig. Et fastlagt forløb hjælper med at vurdere det på minutter i stedet for dage.
Hvor hører jeg først om nye PHP-sårbarheder?
Primære kilder er meddelelserne på php.net og sikkerhedshenvisningerne fra jeres distribution, f.eks. Ubuntu Security Notices, Debian Security Tracker eller Red Hat. BSI (det tyske forbundsagentur for informationssikkerhed) informerer via advarselsmeddelelser. Mediedækning er nyttig, men ofte senere og mindre nøjagtig.
Hvorfor melder distributioner nogle gange dage senere end php.net?
Distributioner skal overtage rettelsen i deres egne pakker, bygge og teste. For ældre udgivelser kan det tage længere eller kun ske via tillægstilbud. Derfor er det umagen værd at følge begge kilder hver for sig.