Kritiske sårbarheter i PHP – oppdater nå (CVE-2026-109618 og CVE-2026-109619)

1. oktober varslet PHP-prosjektet en sikkerhetsutgivelse for to kritiske sårbarheter. 21. oktober klokken 13.30 UTC ble rettelsene sluppet. Begge sårbarhetene gir uautentisert fjernkjøring av kode med CVSS 9,2, og offentlig proof-of-concept-kode sirkulerer allerede.

Dette er ikke en sårbarhet dere planlegger inn i neste vedlikeholdsvindu. Det er en dere utbedrer i dag.

Kortversjonen

• Oppdater til PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35.
• All PHP som håndterer webforespørsler er påvirket – PHP-FPM, mod_php, php-cgi, FrankenPHP og LiteSpeed.
• Én enkelt uautentisert forespørsel kan være nok, og den kan slå til før applikasjonskoden deres i det hele tatt kjører.
• PoC-koden er offentlig. Regn med bred skanning innen timer, ikke uker.
• Kan dere ikke patche med en gang: isoler de internettseksponerte tjenestene til rettelsen er på plass og verifisert.

Hva som skjedde

1. oktober meldte PHP-prosjektet at en sikkerhetsutgivelse var på vei. Dagen etter, 21. oktober klokken 13.30 UTC, ble rettelsene publisert i fire versjoner samtidig: 8.5.12, 8.4.27, 8.3.36 og 8.2.35. CERT-EU sendte ut en sikkerhetsadvarsel samme dag og oppfordret organisasjoner til å patche umiddelbart.

At rettelsen kom raskt er bra. At den tekniske beskrivelsen samtidig ble offentlig, betyr at tiden fra «patch finnes» til «angripere forsøker» måles i timer.

Hva sårbarhetene faktisk gjør

CVE-2026-109618 – minnekorrupsjon ved minnegrensen

PHP stopper en forespørsel som overskrider memory_limit ved å avbryte den med longjmp(). Det betyr at avbruddet kan skje midt i en intern operasjon, mens forespørselens data bare er delvis initialisert – for eksempel under parsing av en filopplasting i et skjema.

Oppryddingen av forespørselen kan da behandle ugyldige data som gyldige og frigjøre minne som aldri ble initialisert. Det minnet kan fortsatt inneholde data fra tidligere allokeringer som angriperen kontrollerer. Resultatet er minnekorrupsjon som kan føre til kodekjøring.

CVE-2026-109619 – gjenværende global tilstand

Intern tilstand som tilhører én forespørsel kan overleve etter at minnet er frigjort – for eksempel etter en fatal feil. En senere forespørsel som håndteres av samme arbeidsprosess kan bruke den gjenværende tilstanden før normal initialisering har rukket å tilbakestille den.

Ingen av sårbarhetene er altså avhengige av at applikasjonen deres har en feil. De ligger i PHPs egen forespørselhåndtering.

En demonstrert exploit viser at én enkelt uautentisert forespørsel kan utløse angrepet før noen applikasjonskode kjører.

Hvem er rammet

Alle PHP-installasjoner som betjener webtrafikk. PHP-teamet vurderer at mod_php er den mest utsatte konfigurasjonen.

• 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
• Utgåtte grener (PHP 8.1 og eldre), som ikke lenger får ordinære oppdateringer

I tillegg: mange kommersielle produkter og åpen kildekode-produkter bruker PHP i bakgrunnen. De kan være påvirket selv om dere ikke selv drifter en PHP-installasjon. NCSC-NL har publisert en oversikt over tredjepartsprogrammer som bygger inn PHP.

Den vanligste feilen vi ser: man teller bare serverne man selv har satt opp. Glem ikke containere, CI-avbildninger, apparater, interne verktøy og leverandørdriftede tjenester.

Kontroller situasjonen – fem minutter per miljø

1. Kjør php -v på hver vert og i hver container. Ikke bare på én.
2. Kartlegg kjøremiljøene: PHP-FPM-pooler, Apache med mod_php, php-cgi, FrankenPHP, LiteSpeed.
3. Bygg containeravbildningene på nytt – det er basisavbildningen som gjelder, ikke den kjørende instansen.
4. Spør leverandører som drifter PHP-avhengige produkter for dere: hvilken versjon kjører dere, og når er dere patchet?
5. Finn utgåtte grener. PHP 8.1 og eldre får ingen ordinære rettelser.

Utbedre

Distribusjonenes pakker. Linux-distribusjoner og LTS-leverandører hadde rettelsene på forhånd. Oppdater via pakkehåndteringen og start arbeidsprosessene på nytt.

Containere. Oppdater basisavbildningen og bygg på nytt. En omstart av en gammel avbildning løser ingenting.

Egenkompilert. Oppgrader til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35.

Utgåtte versjoner. PHP-teamet har publisert minimale backports for 7.4, 8.0 og 8.1 for dem som bygger fra kildekode eller mangler LTS-leverandør. Har dere en LTS-leverandør: kontakt dem først.

rpms.remirepo.net: dette frivillig vedlikeholdte repositoriet får ingen oppdateringer på utgivelsesdagen. PHP-teamet oppfordrer brukere til å bytte til distribusjonens pakker eller bygge fra kildekode.

Start PHP-FPM og de øvrige arbeidsprosessene på nytt etter oppdateringen. En ny binær uten omstart er fortsatt den gamle prosessen.

Hvis dere ikke kan patche i dag

Tiltakene nedenfor reduserer eksponeringen for bestemte angrepsveier. De gjør ikke installasjonen sikker. Bare en oppdatering lukker sårbarheten.

Mot CVE-2026-109618:

• Sett memory_limit=-1 på en måte applikasjonen ikke kan overskrive, for eksempel php_admin_value i FPM-poolen eller i Apache-konfigurasjonen. Kontroller at ingen pool, katalog eller applikasjonsinnstilling setter en grense tilbake.
• Sett lav post_max_size: 8M for applikasjoner uten filopplasting, 32M der opplasting er nødvendig. Hold upload_max_filesize under post_max_size.
• Sett grenser i webserveren eller proxyen for dekodet forespørselsstørrelse, antall felt, antall multipart-deler, antall headere og nesting-dybde. Grensene må også omfatte forespørsler uten brukbar Content-Length.
• Bruk minnegrense i container eller cgroup som tilgjengelighetsgrense, helst med en policy som bare dreper den rammede arbeidsprosessen. Bruk ikke RLIMIT_AS eller RLIMIT_DATA – de kan utløse den sårbare allokeringsveien.

Mot CVE-2026-109619:

• Sett session.upload_progress.enabled=0 og start hver arbeidsprosess på nytt. Sett det i php.ini, i FPM-poolen eller i serverkonfigurasjonen slik at det gjelder før forespørselsparsingen. Stol ikke på ini_set() eller FPMs .user.ini.
• På PHP 8.5: sett fatal_error_backtraces=0 og start hver arbeidsprosess på nytt.
• Fjern ugyldige eller utdaterte per-forespørsel-innstillinger som avgir diagnostikk før initialiseringen. Å skjule diagnostikken med error_reporting, display_errors eller @ hjelper ikke.
• Rett fatale feil og kjøretidsgrenser som en angriper kan nå – i callbacks, opplasting, import og opprydding.

Hvorfor dere ikke bør vente

Tre ting skiller denne hendelsen fra en vanlig patch:

1. Ingen autentisering kreves. Det finnes ingen innlogging å gjemme seg bak.
2. Angrepet skjer før koden deres. Applikasjonslogikken, WAF-reglene og tilgangsmodellen deres er ikke en beskyttelsesbarriere her.
3. PoC er allerede ute. Det som pleier å ta uker, er allerede gjort av noen andre.

Kostnaden for en patch og en omstart i dag er ubetydelig sammenlignet med kostnaden for et inntrengning. Det gjelder særlig hvis dere omfattes av NIS2, der en betydelig hendelse skal varsles innen 24 timer.

Etter patch – tre ting

1. Verifiser på hver node. Versjonen – ikke bare at pakkehåndteringen sa OK.
2. Les loggene bakover. Multipart-POST-er, uventede 500-svar, krasjede arbeidsprosesser og trafikk fra ukjente kilder de siste døgnene.
3. Ved minste mistanke: kjør hendelsesrutinen. Isoler, sikre logger, vurder om varsling kreves.

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, oversikt over produkter med innebygd PHP: https://github.com/NCSC-NL/php2shell

---

Sårbarheter som denne er selve argumentet for kontinuerlig sikkerhet: patcher, verifisering og overvåking som pågår hele tiden – ikke en årlig gjennomgang. Les mer om hva kontinuerlig sikkerhet betyr i praksis.