PHP-sikkerhedsopdatering 2026: PHP2Shell CVSS 9.2 — guide til rettelsen

Selve offentliggørelsen var usædvanlig. Den 20. oktober udsendte PHPs sikkerhedsteam en forhåndsmeddelelse, planlagde udgivelsen til den 21. oktober kl. 14:00 UTC og forbeholdt sig retten til at udsende den tidligere. CVE-identifikatorerne lækkede dagen før offentliggørelsen sammen med overdrevne påstande om alvor og berørte versioner. Leverandørerne havde allerede modtaget rettelserne til deres distributioner, og nationale CERT'er begyndte at offentliggøre vejledning, før koden overhovedet var offentlig. Med andre ord: Da udgivelsen kom på gaden, havde ingen en legitim undskyldning for at vente.

To sårbarheder, én hasteudgivelse

Ingen af fejlene er en logisk fejl i selve applikationen. Begge ligger i, hvordan PHP opbygger og afvikler en forespørgsel, og derfor kan hverken en framework-opdatering, en plugin-opdatering eller en WAF-regel erstatte opgraderingen af fortolkeren.

CVE-2026-109618 — RCE via korruption ved hukommelsesmangel. Når PHP løber tør for hukommelse, afbryder den forespørgslen i stedet for at fortsætte. Meddelelsen beskriver et forløb, hvor den afbrydelse standsker PHP, mens interne forespørgselsdata kun er delvist initialiseret, så oprydningstrinnet senere behandler ugyldige data som gyldige. En angriber, der kan presse hukommelsesforbruget op mod loftet, kan derfor styre, hvad der sker bagefter. Det er denne fejl, der gør afhjælpningsrådene så kontraintuitive: leverandøren beder administratorer om at forhindre PHP i at ramme sit eget hukommelsesloft — ikke om at stramme det.

CVE-2026-109619 — RCE via forældet global tilstand. Intern tilstand ejet af én forespørgsel kan overleve, efter at hukommelsen bag den er frigivet. Den næste forespørgsel, som den samme worker-proces håndterer, kan forbruge den forældede tilstand, før den normale initialisering nulstiller den. På en worker med lang levetid — netop dét, PHP-FPM, mod_php og LiteSpeed er — er genanvendt hukommelse en normal, permanent tilstand, og derfor er dette ikke et specialtilfælde, der kun rammer eksotiske opsætninger.

Navnet PHP2Shell er ikke en officiel betegnelse fra PHP-projektet; det opstod hos forskere og sikkerhedsleverandører og hængte ved, så du vil se det i scanneroutput, hostingbulletiner og CERT-adviser, der henviser til netop disse to CVE'er.

Hvem er reelt udsat

Meddelelsen er ikke i tvivl: Alle PHP-installationer, der betjener webforespørgsler, er i risiko. Det omfatter PHP-FPM bag nginx eller Apache, Apache med mod_php, php-cgi, LiteSpeed og FrankenPHP. Forskellen mellem dem er, hvor meget arbejde en angriber skal udføre.

Hvis du hoster WordPress, WooCommerce, Laravel, Magento, Magento-nære ERP-systemer eller en hvilken som helst PHP-bookingportal for din handelsvirksomhed, hører du hjemme i de første tre rækker, selv når applikationskoden er fejlfri. For et bredere blik på, hvem der bør eje selve runtime-miljøet, se vores guide til IT-outsourcing i Tyrkiet.

Tjek din version på to minutter

Fælden her er versionsaritmetik. Distributionerne leverer PHP 8.3.6 eller 8.2.x i årevis og backporter sikkerhedsrettelser ind i det samme synlige versionsnummer, så php -v alene afslører ikke, om du er beskyttet. Sammenlign tre ting.

1. Den synlige PHP-version og den SAPI, der betjener trafikken.

2. Distributionens pakkeversion, ikke den opstrøms version. På Debian og Ubuntu er changeloggen det ærlige svar; på RPM-systemer skal du forespørge pakkens changelog.

Nævner changeloggen begge CVE'er i den installerede version, er du patchet, selv om php -v stadig viser 8.3.6. Det er forskellen mellem et rigtigt sikkerhedssvar og rene versionsnumre.

3. Om den kørende proces har genindlæst den patchede binærfil. En pakkeopdatering, der aldrig følges op af en genstart, efterlader den gamle kode i hukommelsen. Sammenlign tjenestens starttidspunkt med pakkens installationstidspunkt:

På cPanel, Plesk, DirectAdmin eller en administreret platform er modstykket PHP-vælgeren plus værtens egne sikkerhedsbulletiner: find den indbyggede version, dit site faktisk er tildelt, og ikke den nyeste, panelet reklamerer med. Kan din vært ikke oplyse en patch-dato, skal du behandle sitet som upatchet. Vores services for digital infrastruktur dækker dette audit samt selve opgraderingen; du kan også bare kontakte os med din stack, så fortæller vi, hvad vi ville tjekke.

Rettede versioner og EOL-klippen

PHP understøtter en gren i to år med aktiv udvikling og yderligere to år med sikkerhedsrettelser. Denne politik er netop det, der gav fire samtidige rettelser den 21. oktober — og den er også det, der lader de ældre grene stå alene.

To praktiske advarsler fra meddelelsen. For det første: hvis du installerer PHP fra et community-repository frem for fra din distribution, kan det repository ligge bagefter sikkerhedsvinduet — vedligeholderne af de udbredte Remi-pakker har oplyst, at de ikke ville have opdateringer samme dag, så den sikre vej er din distributions pakker eller en kildekodebygning. For det andet: hvis du er på PHP 8.1 eller ældre, er »at vente på vores vært« en sikkerhedsbeslutning, du træffer på dine kunderes vegne — dokumentér den, eller ændr den.

Patch en produktionsserver uden hændelser

Sikkerhedsopdateringer inden for samme minor-version ødelægger sjældent en applikation; det gør uprøvede genstarter til gengæld. Rækkefølgen nedenfor er den, vi bruger på vores handelsplatforme i drift, og den holder risikovinduet kort uden at sætte sitet på spil.

1. Tag et snapshot først. Et hypervisor- eller volume-snapshot, du faktisk har testet genoprettelsen af, gendannes på minutter, og det gør beslutningen om at patche billig.
2. Reproducer versionen i staging. Samme branch, samme udvidelser, samme PHP-konfigurationsfiler, en kopi af produktionsdataene. Kør checkout-, tilbudsanmodnings- og betalingsflowene, ikke kun forsiden.
3. Opgradér pakkesættet som én enhed. At blande en opgraderet CLI-binærfil med en gammel FPM-binærfil er netop, hvordan man ender med et patchet php -v, mens webtrafikken stadig betjenes af den gamle kode: apt-get update && apt-get install --only-upgrade 'php8.3-*', eller dnf update --security 'php*' på RPM-værter.
4. Genstart den proces, der betjener forespørgslerne, og bekræft så, at den blev genstartet. systemctl restart php8.3-fpm (eller genindlæs Apache / genstart LiteSpeed), tjek derefter tjenestens starttidspunkt igen og kør versions- og changelog-forespørgslerne én gang til.
5. Følg fejlloggen i en time. OOM-beskeder, nye signaturer for fatale fejl og usædvanlige 5xx-rater er signaler om, at afhjælpningsindstillingerne nedenfor kan trænge til justering — ikke grunde til at udskyde opgraderingen.
6. Dokumentér beviserne. Pakkeversionen, changelog-linjen, der nævner begge CVE'er, og tidsstemplet for genstarten. Kunder, revisorer og kontrolgennemgange i ISO 27001-stil beder om præcis det, og det tager ti sekunder at gemme.

Hvor opgraderingen må vente — en valideret ERP-integration, en udgivelseskalender under embargo, et godkendelsesloop hos kunden — bør der samme dag sættes en kompensatorisk kontrol foran den, i stedet for at lade porten stå åben og håbe på det bedste. Præcis det anbefalede adviser fra nationale CERT'er i netop denne situation: isolér internetvendte PHP-applikationer fra det offentlige netværk, hvor øjeblikkelig patching ikke er mulig.

Midlertidige afhjælpninger: indsnævr vinduet, men luk det ikke

PHP-advisen fastslår uden omsvøb, at der ikke findes en fuldstændig afhjælpning, og at opdatering er det eneste sikre valg. Behandl det følgende som beskyttelse på dage, ikke uger, anvendt på et niveau, som applikationen ikke kan overskrive, og med samtlige workere genstartet bagefter.

Mod CVE-2026-109618 (vejen via hukommelsesmangel)

• Lad PHP bruge maskinens hukommelse i bund i stedet for at stoppe ved sin egen grænse: memory_limit = -1, helst som php_admin_value memory_limit = -1, så applikationskoden ikke kan sætte loftet på igen.
• Hold request bodies små i fortolkeren: advisens vejledning lyder på omkring 8 MB, når der ikke er uploads, og omkring 32 MB, når der er, med upload_max_filesize sat lavere end post_max_size.
• Håndhæv de kostbare begrænsninger i proxyen, for skaden sidder i den afkodede forespørgsel, ikke i den overførte størrelse: samlet afkodet body-størrelse, antal inputfelter, antal multipart-dele, antal headers, indlejringsdybde — og dæk også forespørgsler, der ankommer uden en brugbar Content-Length.
• Begræns sprængradius med en hukommelsesgrænse på container- eller cgroup-niveau, dimensioneret så en dræbt worker kun er en tilgængelighedshændelse og ikke en hændelse for hele værten. Brug ikke RLIMIT_AS eller RLIMIT_DATA som erstatning: de udløser netop den fejlslagne allokering, som udgør den sårbare kodevej.

Mod CVE-2026-109619 (vejen via forældet tilstand)

• Deaktivér session upload progress med session.upload_progress.enabled = 0, sat i php.ini, i FPM-poolen eller i serverkonfigurationen — et sted, hvor indstillingen træder i kraft, før forespørgslerne bliver behandlet. Genstart derefter samtlige workere, fordi FPM deler allerede initialiseret modultilstand på tværs af forespørgsler. ini_set() og .user.ini kommer for sent til at gøre en forskel.
• På PHP 8.5 skal du sætte fatal_error_backtraces = 0 og genstarte.
• Fjern indstillinger pr. forespørgsel, som er ugyldige eller forældede og derfor udsender diagnostik under den tidlige initialisering. At undertrykke meddelelsen med error_reporting, display_errors eller @ fjerner ikke kodevejen.
• Jag de fatale fejl og langvarige timeouts, som en angriber kan nå, i upload- og import-håndtering, callback-kode og oprydningsroutiner — præcis der, hvor begge fejl holder til.

Et CDN eller en WAF foran origin-serveren gør stadig sin nytte: rate limiting, blokering af uregelmæssige forespørgselsformer og virtuel patching reducerer støj og bremser opportunistisk scanning. De er et fartbump for en målrettet angriber, ikke en kontrol, du kan godkende som afhjælpning.

Det skal du spørge dit webhotel om i dag

Supportscripts besvarer det spørgsmål med »vi er altid patchet«. Bed i stedet om beviser, du kan arkivere:

• Den indbyggede PHP-version, der er tildelt vores konto, og om den er en distributionspakke eller en leverandørbuild.
• Datoen, hvor rettelserne til CVE-2026-109618 og CVE-2026-109619 nåede jeres serverpark, sammen med den interne streng for pakkeversionen.
• Om rettelsen gælder den SAPI, der betjener vores site (FPM, LiteSpeed, mod_php), og de staging- eller backup-noder, vi eventuelt ville gendanne.
• Hvis platformen endnu ikke er patchet: Hvilken kompensatorisk kontrol er på plads, og indtil hvornår?
• Jeres faste praksis for EOL-branches — hvad sker der med mit site den 1. januar 2027, når sikkerhedsunderstøttelsen af PHP 8.2 ophører?

En leverandør, der besvarer de fem spørgsmål i én e-mail, er en leverandør, der er værd at beholde. En, der vender tilbage med markedsføringstekst, er en samtale om migrering; den samme omhu gælder som i vores arbejde med ISO 27001-gapvurderinger, hvor leverancen er dokumentation, ikke beroligende ord.

Skal du gå ud fra, at du var kompromitteret?

Ikke automatisk — men undersøg det i stedet for at gætte, især hvis serveren var eksponeret mod det offentlige internet i vinduet, før din patch.

• Se efter processer, listeners og cron-poster, du ikke selv har oprettet, samt udgående forbindelser fra den bruger, som PHP-workeren kører som.
• Diff de skrivbare applikationsmapper mod en autoritativ deploy-kilde: nye PHP-filer, ændrede upload-mapper, temp-mapper, der uventet er eksekverbare.
• Gennemsøg webloggene for forespørgselsstorme omkring offentliggørelsestimerne, usædvanligt store multipart-bodier eller forespørgsler, der returnerede 500 med OOM-signaturer i PHP-fejlloggen.
• Tjek, at den patchede binærfil faktisk kører — sammenligningen af genstartstidspunkterne ovenfor giver svaret.
• Hvis noget ser forkert ud, så behandl det som en hændelse: sikr disken og loggene, rotér alle credentials, som applikationen kan læse, og genopbyg fra et verificeret rent image. At geninstallere PHP-pakken oven på en kompromitteret vært er ikke afhjælpning.

Et gennemarbejdet eksempel fra vores egen infrastruktur

Vi driver worldwidetradex.com på Ubuntu 24.04 LTS med nginx og PHP-FPM, så den 22. oktober kørte vi tjekkene ovenfor på os selv. Resultaterne er en god illustration af, hvorfor versionsregnestykket betyder noget:

Lektionen kan overføres til enhver stack: Dit sikkerhedsniveau er pakkeversionen plus changeloggen plus genstarten, ikke marketing-versionsstrengen i webhotellets kontrolpanel.

Gør patchingen til rutine i stedet for til heltearbejde

PHP2Shell huskes ikke, fordi det er eksotisk; det huskes, fordi den fortolker, som det meste af nettet kører på, rummede en kritisk fejl, der kunne udløses før autentificering, og fordi tusindvis af værter måtte reagere i løbet af få timer. De teams, der sov igennem den, var ikke heldige — de havde automatisering.

• Uovervågede sikkerhedsopgraderinger af fortolkeren, hvor version og genstart registreres automatisk.
• Et inventar, der ved, hvilken SAPI og hvilken PHP-branch hvert enkelt site bruger, herunder staging, backups og dét ene WordPress fra 2019.
• En indøvet gendannelsesvej, så »patch nu« aldrig bliver afvejet mod »vi kan ikke rulle tilbage«.
• En branch-plan: intet på en PHP-udgivelse, hvis sikkerhedsunderstøttelse ophører inden for de næste tolv måneder.
• Én navngivet ejer pr. server og en skriftlig eskaleringsvej til de dage, hvor en patch lander kl. 14:00 UTC en onsdag.

Vil du hellere købe den kompetence end selv at bemande den, overtager vi ejerskabet af PHP-produktionsplatforme — patchrytme, overvågning, backups og dokumenterede gendannelser — som en del af vores arbejde med administreret infrastruktur. Start med en kort beskrivelse af behovet og dine mængder: anmod om et tilbud.

Ofte stillede spørgsmål

Kilder

• PHP — sikkerhedsadvisen “Critical remote code execution vulnerabilities, update now” og udgivelsesmeddelelserne fra den 21. oktober 2026, herunder vejledningen til afhjælpning og tidslinjen for understøttelse på oversigten over understøttede versioner.
• GitHub Security Advisories for PHP-repositoryet: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) og GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• CERT-EU — Security Advisory 2026-018, “Critical Vulnerabilities in PHP”, som nævner begge CVE'er.
• Infosecurity Magazine — “Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches” (21. oktober 2026) og “PHP2Shell Exploitation Attempt Detected by Amazon Four Days Before Vulnerability Disclosure” (22. oktober 2026).

Vil du have opgraderingen klaret for dig? For at drøfte patching, en versionsgennemgang, migrering til en administreret og patchet PHP-platform eller infrastrukturen omkring den kan du kontakte os eller ringe til +90 505 679 78 03.