Kritiske sårbarheder i PHP – opdater nu (CVE-2026-109618 og CVE-2026-109619)

Den 20. oktober varslede PHP-projektet en sikkerhedsrelease for to kritiske sårbarheder. Den 21. oktober klokken 13.30 UTC blev rettelserne udgivet. Begge sårbarheder giver uautentificeret fjernkodekørsel med CVSS 9,2, og offentlig proof-of-concept-kode cirkulerer allerede.

Det er ikke en sårbarhed, I planlægger ind i næste vedligeholdelsesvindue. Det er en, I udbedrer i dag.

Kort udgave

• Opdater til PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35.
• Al PHP, der håndterer webforespørgsler, er påvirket – PHP-FPM, mod_php, php-cgi, FrankenPHP og LiteSpeed.
• En enkelt uautentificeret forespørgsel kan være nok, og den kan slå til, før jeres applikationskode overhovedet kører.
• PoC-koden er offentlig. Regn med bred scanning inden for timer, ikke uger.
• Kan I ikke patche med det samme: isolér de interneteksponerede tjenester, indtil rettelsen er på plads og verificeret.

Hvad skete der

Den 20. oktober meddelte PHP-projektet, at en sikkerhedsrelease var på vej. Dagen efter, den 21. oktober klokken 13.30 UTC, blev rettelserne offentliggjort i fire versioner samtidigt: 8.5.12, 8.4.27, 8.3.36 og 8.2.35. CERT-EU udsendte en sikkerhedsadvarsel samme dag og opfordrede organisationer til at patche med det samme.

At rettelsen kom hurtigt, er godt. At den tekniske beskrivelse samtidig blev offentlig, betyder, at tiden fra "patch findes" til "angribere forsøger" måles i timer.

Hvad sårbarhederne faktisk gør

CVE-2026-109618 – hukommelseskorruption ved hukommelsesgrænsen

PHP stopper en forespørgsel, der overskrider memory_limit, ved at afbryde den med longjmp(). Det betyder, at afbrydelsen kan ske midt i en intern operation, mens forespørgslens data kun er delvist initialiseret – for eksempel under parsingen af en filoverførsel i en formular.

Oprydningen af forespørgslen kan derefter behandle ugyldige data som gyldige og frigive hukommelse, der aldrig blev initialiseret. Den hukommelse kan stadig indeholde data fra tidligere allokeringer, som angriberen kontrollerer. Resultatet er hukommelseskorruption, der kan føre til kodekørsel.

CVE-2026-109619 – resterende global tilstand

Intern tilstand, der hører til en forespørgsel, kan overleve, efter at dens hukommelse er frigivet – for eksempel efter en fatal fejl. En senere forespørgsel, der håndteres af samme arbejdsproces, kan bruge den resterende tilstand, før den normale initialisering har nået at nulstille den.

Ingen af sårbarhederne er altså afhængige af, at jeres applikation har en fejl. De sidder i PHPs egen forespørgselshåndtering.

En demonstreret exploit viser, at en enkelt uautentificeret forespørgsel kan udløse angrebet, før nogen applikationskode kører.

Hvem er ramt

Alle PHP-installationer, der betjener webtrafik. PHP-teamet vurderer, at mod_php er den mest udsatte konfiguration.

• PHP 8.5 før 8.5.12
• PHP 8.4 før 8.4.27
• PHP 8.3 før 8.3.36
• PHP 8.2 før 8.2.35
• Udgåede grene (PHP 8.1 og ældre), som ikke længere får ordinære opdateringer

Derudover: mange kommercielle produkter og open source-produkter bruger PHP i baggrunden. De kan være påvirkede, selv om I ikke selv driver en PHP-installation. NCSC-NL har offentliggjort en oversigt over tredjepartsprogrammer, der indlejrer PHP.

Den mest almindelige fejl, vi ser: man tæller kun de servere, man selv har sat op. Glem ikke containere, CI-images, apparater, interne værktøjer og leverandørdrevne tjenester.

Kontrollér situationen – fem minutter pr. miljø

1. Kør php -v på hver vært og i hver container. Ikke kun på én.
2. Kortlæg kørselsmiljøerne: PHP-FPM-pools, Apache med mod_php, php-cgi, FrankenPHP, LiteSpeed.
3. Genopbyg containerimages – det er basisimaget, der gælder, ikke den kørende instans.
4. Spørg leverandører, der driver PHP-afhængige produkter for jer: hvilken version kører I, og hvornår er I patchet?
5. Find udgåede grene. PHP 8.1 og ældre får ingen ordinære rettelser.

Udbedr

Distributionernes pakker. Linux-distributioner og LTS-leverandører havde rettelserne på forhånd. Opdater via pakkehåndteringen, og genstart arbejdsprocesserne.

Containere. Opdater basisimaget, og genopbyg. En genstart af et gammelt image løser intet.

Egenkompileret. Opgrader til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35.

Udgåede versioner. PHP-teamet har offentliggjort minimale backports til 7.4, 8.0 og 8.1 for dem, der bygger fra kildekode eller mangler en LTS-leverandør. Har I en LTS-leverandør: kontakt dem først.

rpms.remirepo.net: dette frivilligt vedligeholdte repository får ingen opdateringer på releasedagen. PHP-teamet opfordrer brugere til at skifte til distributionens pakker eller bygge fra kildekode.

Genstart PHP-FPM og de øvrige arbejdsprocesser efter opdateringen. En ny binær uden genstart er stadig den gamle proces.

Hvis I ikke kan patche i dag

Tiltagene nedenfor reducerer eksponeringen for bestemte angrebsveje. De gør ikke installationen sikker. Kun en opdatering lukker sårbarheden.

Mod CVE-2026-109618:

• Sæt memory_limit=-1 på en måde, applikationen ikke kan overskrive, for eksempel php_admin_value i FPM-poolen eller i Apache-konfigurationen. Kontrollér, at ingen pool, mappe eller applikationsindstilling sætter en grænse tilbage.
• Sæt lav post_max_size: 8M til applikationer uden filoverførsel, 32M hvor overførsel er nødvendig. Hold upload_max_filesize under post_max_size.
• Sæt grænser i webserveren eller proxien for afkodet forespørgselsstørrelse, antal felter, antal multipart-dele, antal headers og indlejringsdepth. Grænserne skal også omfatte forespørgsler uden brugbar Content-Length.
• Brug hukommelsesgrænse i container eller cgroup som tilgængelighedsgrænse, helst med en politik, der kun dræber den ramte arbejdsproces. Brug ikke RLIMIT_AS eller RLIMIT_DATA – de kan udløse den sårbare allokeringsvej.

Mod CVE-2026-109619:

• Sæt session.upload_progress.enabled=0, og genstart hver arbejdsproces. Sæt det i php.ini, i FPM-poolen eller i serverkonfigurationen, så det gælder før forespørgselsparsingen. Stol ikke på ini_set() eller FPM's .user.ini.
• På PHP 8.5: sæt fatal_error_backtraces=0, og genstart hver arbejdsproces.
• Fjern ugyldige eller forældede pr.-forespørgsel-indstillinger, der udsender diagnosticering før initialiseringen. At skjule diagnosticeringen med error_reporting, display_errors eller @ hjælper ikke.
• Ret fatale fejl og køretidsgrænser, som en angriber kan nå – i callbacks, overførsel, import og oprydning.

Hvorfor I ikke bør vente

Tre ting adskiller denne hændelse fra en almindelig patch:

1. Ingen autentificering kræves. Der er ingen login at gemme sig bag.
2. Angrebet sker før jeres kode. Jeres applikationslogik, WAF-regler og tilladelsesmodel er ikke en beskyttelsesbarriere her.
3. PoC er allerede ude. Det, der plejer at tage uger, er allerede gjort af en anden.

Prisen for en patch og en genstart i dag er ubetydelig sammenlignet med prisen for et indbrud. Det gælder især, hvis I er omfattet af NIS2, hvor en betydelig hændelse skal anmeldes inden for 24 timer.

Efter patch – tre ting

1. Verificér på hver node. Versionen – ikke bare at pakkehåndteringen sagde OK.
2. Læs logfilerne baglæns. Multipart-POSTs, uventede 500-svar, nedbrudte arbejdsprocesser og trafik fra ukendte kilder de seneste dage.
3. Ved den mindste mistanke: kør hændelsesrutinen. Isolér, sikr logfiler, vurder om anmeldelse er nødvendig.

Kilder

• CERT-EU, Security Advisory 2026-018: https://cert.europa.eu/publications/security-advisories/2026-018/
• PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35: https://www.php.net/
• GHSA-w8hw-w9fx-j79w: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GHSA-6wmf-4rv5-p3rp: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• NCSC-NL, oversigt over produkter med indlejret PHP: https://github.com/NCSC-NL/php2shell

---

Sårbarheder som denne er selve argumentet for kontinuerlig sikkerhed: patches, verifikation og overvågning, der kører hele tiden – ikke en årlig gennemgang. Læs mere om, hvad kontinuerlig sikkerhed betyder i praksis.