Written by Två kritiska säkerhetshål i PHP kan låta en angripare köra kod utan inloggning. Säkerhetsuppdateringarna finns, men för den som driver egna webbtjänster gäller det att hitta samtliga installationer och kontrollera att rättelserna faktiskt körs.
Säkerhetshål i själva PHP
Den 21 oktober släppte PHP versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35. De rättar CVE-2026-109618 och CVE-2026-109619, båda kritiska sårbarheter som kan leda till fjärrkörning av kod utan autentisering. Nyheten ligger inom bevakningsperioden 21–28 oktober 2026. PHP:s säkerhetsråd.
Båda felen gäller PHP:s interna minneshantering. Det ena kan uppstå när minnesbrist avbryter hanteringen av en förfrågan. Det andra innebär att internt tillstånd kan hänvisa till minne som redan frigjorts. Under rätt förutsättningar kan följden bli fjärrkörning av kod.
PHP pekar ut alla installationer som hanterar webbförfrågningar som riskutsatta, däribland PHP-FPM och Apache med mod_php. Risken bedöms som högst för mod_php: där har ett angrepp demonstrerats som kan utlösas innan webbapplikationens egen kod körs. Att bara uppdatera webbapplikationen räcker därför inte.
Containern behöver också uppdateras
Docker meddelade den 22 oktober att både Docker Official Images och Docker Hardened Images med PHP hade uppdaterats. Sårbarheterna finns i PHP, men påverkar därmed också tjänster byggda på dessa avbildningar. Docker uppmanar användare att uppdatera omedelbart. Dockers säkerhetsbesked.
För ett homelab eller en mindre driftmiljö blir den praktiska uppgiften att följa PHP hela vägen till den körande tjänsten. En uppdaterad avbildning i ett register visar inte i sig att den egna driftsättningen använder rättelsen.
Redaktionell rekommendation: inventera vilka tjänster som innehåller PHP, kontrollera leverantörernas uppdateringar och verifiera versionen efter driftsättning. Egenbyggda avbildningar och tjänster med fastlåsta beroenden behöver särskild uppmärksamhet. Dokumentera vilken rättad version eller vilket leverantörspaket varje tjänst använder, så att kontrollen går att följa upp.
Äldre versioner kräver ett tydligt besked
PHP 8.1 och äldre får inte längre ordinarie uppdateringar från PHP-projektet. Linuxdistributioner och leverantörer med långtidsstöd kan däremot tillhandahålla bakporterade rättelser. Därför behöver administratören kontrollera leverantörens säkerhetsbesked, snarare än att enbart jämföra ett versionsnummer med PHP:s nya utgåvor.
Säkerhetsföretaget Huntress rekommenderar också en inventering som omfattar PHP inuti leverantörsprogramvara. Det är en användbar påminnelse: utgå från vilka tjänster som körs, inte bara vilka programmeringsspråk som installerats manuellt. Huntress genomgång.
Kompletterande råd efter rättelserna
Den 23 oktober publicerade PHP ett separat råd om sessionernas uppladdningsprogress. Projektet rekommenderar att session.upload_progress.enabled stängs av till nästa ordinarie felrättningsutgåva. Rådet gäller en ovanlig kombination av inställningar och applikationskod som byter sessionsserialisering under körning. PHP uppger att applikationer som aldrig gör ett sådant byte kan behålla funktionen aktiverad. PHP:s kompletterande råd.
Detta bör läsas tillsammans med uppdateringsbeskedet. Tillfälliga inställningsändringar är inte en generell ersättning för säkerhetsuppdateringarna.
Vad vet vi om angrepp?
Huntress uppgav i sin uppdatering den 21 oktober att företaget inte hade observerat utnyttjande i sina partnersystem fram till klockan 16.30 amerikansk östkusttid. Samtidigt hänvisade företaget till andras rapporter om angrepp. Det är en tidsbegränsad observation från en viss kundbas, inte ett besked om att sårbarheterna saknar praktisk risk.
Varför det här är viktigt för svenska läsare
För svenska föreningar, småföretag och privatpersoner med egna webbtjänster är detta framför allt en fråga om driftansvar. Vem uppdaterar PHP: webbhotellet, applikationsleverantören eller du själv? Vår bedömning är att nyhetens viktigaste konsekvens är behovet av en verifierad inventering och uppdatering av varje berörd tjänst.
Källor och datum
- PHP:s primärkälla: säkerhetsråd publicerat 21 oktober 2026; kompletterande sessionsråd publicerat 23 oktober.
- Docker: publicerat 22 oktober 2026; uppdatering av Dockers avbildningar.
- Huntress: oberoende säkerhetskälla med daterade uppdateringar den 21 oktober 2026. Ursprungligt publiceringsdatum framgick inte tydligt av den lästa sidan.