Bli inte skraj nu, den här texten ser mycket lång ut, men vill du bara ha lite grundläggande information så behöver du bara läsa en bit! Jag säger till när det blir komplicerat!
Det har varit mycket skriverier om allvarliga säkerhetshål i PHP. Men vad rör det dig? Du har en webbplats. Den presenterar företaget, visar vad ni erbjuder och gör det enkelt för kunderna att kontakta er. Kanske händer det inte så mycket mer än så.
Varför skulle någon vilja hacka den?
Det korta svaret är att det inte alltid är din information någon är ute efter. Det kan lika gärna vara tekniken bakom webbplatsen.
En webbplats är nämligen mer än det som syns på skärmen. Bakom kulisserna finns servrar, programvara och databaser som ser till att allt fungerar. Och precis som annan teknik behöver de underhållas.
PHP är en del av programvaran bakom många webbplatser. Den arbetar på servern och sköter exempelvis kontakten med databasen, inloggningar och att plocka fram innehållet som besökaren ska se. Du ser inte PHP när du besöker sidan, men det kan vara PHP som gör att sidan över huvud taget fungerar.
Den 21 oktober 2026 släpptes säkerhetsuppdateringar för två kritiska sårbarheter i PHP. Under rätt förutsättningar kunde de låta en angripare köra egen kod på servern, utan att först behöva logga in. Båda fick allvarlighetsgraden 9,2 av 10 enligt säkerhetsskalan CVSS 4.0. Det här var alltså inget man kunde lägga på att göra-listan till nästa månad.
Vad kan hända med en så enkel sida som min?
En angripare som kan köra kod i webbplatsens miljö kan, beroende på vilka rättigheter som finns, komma åt filer och databasuppgifter, ändra innehåll eller använda miljön för fler angrepp. Det betyder inte automatiskt full kontroll över precis allt på servern, men det kan vara illa nog.
Din restaurangmeny kanske inte är hemlig men du vill knappast att din hemsida ska visa falska betalningsuppgifter, skicka besökare vidare till en bluffsida eller användas för att angripa någon annan.
Det behövs alltså inget stort kundregister för att en webbplats ska behöva skyddas.
Varför innebär det här arbete och en kostnad?
PHP är gratis. Arbetet med att uppdatera och kontrollera en webbplats tar däremot tid.
Ibland räcker det att installera en säkerhetsuppdatering och kontrollera att allt fungerar. I andra fall ligger webbplatsen på en gammal PHP-version och behöver ett större lyft. Då kan även kod, teman och tillägg behöva uppdateras eller anpassas.
Arbetet kan därför omfatta att:
Det är lätt att tänka att jobbet är klart när startsidan ser rätt ut. Men ett kontaktformulär kan ha slutat skicka mejl, eller en bokning kan fastna först när kunden klickar på sista knappen. Sådant behöver också kontrolleras.
Det är det arbetet som kan innebära en kostnad. Hur mycket som behövs beror på webbplatsens skick och vad som redan ingår i ert avtal.
Men webbhotellet uppdaterar väl sådant här?
I många fall uppdaterar webbhotellet själva serverprogramvaran. Men det är en separat sak från att kontrollera att just din webbplats fungerar med en ny PHP-version.
Att uppdatera WordPress är inte heller samma sak som att uppdatera PHP. Det är olika delar som behöver hållas efter.
Fråga därför gärna både webbhotellet och den som sköter webbplatsen vad som är uppdaterat och vad som har kontrollerats.
Ungefär här kan du sluta läsa om du mest ville veta vad det här betyder för din webbplats. Nu går vi lite djupare.
PHP och alla dessa versioner...
PHP har funnits länge, faktiskt ända sedan 1995. Många har genom åren spått att ”nu dör PHP” när nya alternativ har dykt upp. Men språket har hängt kvar och fortsatt utvecklas.
Enligt W3Techs använder ungefär 69 procent av webbplatserna där serverspråket går att identifiera PHP. Det är alltså inte ett mått på all internettrafik eller alla servrar, men det säger en del om spridningen.
WordPress, Drupal och Joomla använder alla PHP. Det finns gott om alternativ därute, exempelvis Python, C# med ASP.NET Core och JavaScript på servern med Node.js, men dem kan vi lämna åt sidan här.
Vad var det egentligen som gick fel?
Det handlade om två fel i PHP:s interna minneshantering. Alltså i själva motorn som kör webbplatsens PHP-kod.
Det första, CVE-2026-109618, handlade om vad som hände när ett anrop nådde PHP:s minnesgräns.
Normalt ska PHP då avbryta arbetet på ett kontrollerat sätt. Men avbrottet kunde inträffa medan interna datastrukturer bara var halvfärdiga. När PHP sedan städade upp kunde det behandla den ofärdiga informationen som om den vore korrekt.
Resultatet kunde bli minneskorruption och i förlängningen att en angripare kunde köra egen kod. Med Apache och mod_php kunde angreppet ske redan innan webbplatsens egen kod började köras. Det var alltså inte något som automatiskt kunde lösas genom att rätta ett WordPress-tillägg till exempel.
Det andra, CVE-2026-109619, handlade om information som felaktigt blev kvar mellan webbanrop.
En PHP-arbetsprocess kan hantera flera anrop efter varandra. När ett anrop är klart ska dess tillfälliga minne frigöras och interna hänvisningar till minnet rensas bort.
Här kunde hänvisningar bli kvar efter att minnet hade frigjorts. Ett senare anrop i samma arbetsprocess kunde sedan använda dem. Det kallas use-after-free och kunde under rätt förutsättningar också leda till att angriparens kod kördes.
Och var kommer AI in i det här?
Tecken på det ena problemet hade identifierats redan 2024. Då fanns misstanken om en allvarlig angreppsmöjlighet, men ingen konkret angreppsväg hade påvisats.
Under 2026 kom ytterligare säkerhetsforskning, där AI användes som hjälpmedel, som visade hur problemen faktiskt kunde utnyttjas. Att hitta en misstänkt svaghet och att visa ett fungerande angrepp är två olika saker.
Rättningen var dessutom komplicerad. Den behövde lösa säkerhetsproblemen utan att skapa nya problem med kompatibilitet och prestanda.
Publiceringen var planerad att ske samordnat med leverantörerna, så att uppdateringar skulle finnas tillgängliga när detaljerna blev offentliga. Men läckor störde planeringen och lanseringen tidigarelagdes till den 21 oktober. Det blev bråttom för många som ansvarar för PHP-miljöer.
Vilka versioner fick rättningarna?
De ordinarie säkerhetsutgåvorna var:
För PHP 7.4, 8.0 och 8.1 publicerades även särskilda källkodspatchar. Det innebar inga nya ordinarie utgåvor eller att versionerna åter fick löpande support. Den som använder en äldre version behöver kontrollera med sin leverantör om rättningarna faktiskt ingår i det installerade paketet.
Även testversionen PHP 8.6.0 RC4 innehöll rättningarna, men den är inte avsedd för produktionsmiljöer.
Så varför rekommenderar vi ändå att gå vidare till PHP 8.5?
Man behöver inte gå hela vägen till PHP 8.5 för att åtgärda just de här två säkerhetshålen. En rättad version inom en annan stödd versionsgren är också ett alternativ.
Men när en äldre webbplats ändå behöver ses över tycker vi att det är ett bra tillfälle att ta sig i kragen och planera för en aktuell version.
PHP 8.2 får exempelvis säkerhetsuppdateringar till den 31 december 2026, medan PHP 8.5 har säkerhetssupport till den 31 december 2029. Det ger mer tid framåt, även om framtida uppdateringar fortfarande behöver installeras.
Vår rekommendation är därför att sikta på PHP 8.5.12 eller senare, efter att webbplatsens kompatibilitet har kontrollerats.
Det är däremot skillnad på att gå från 8.5.11 till 8.5.12 och att gå från 8.1 till 8.5. Det större versionsbytet kan kräva fler ändringar. Om något hindrar det behöver säkerhetshålen ändå åtgärdas direkt, och den större uppgraderingen planeras separat.
En extra detalj för den tekniskt intresserade
Den 23 oktober publicerade PHP-projektet en kompletterande varning om sessionshantering. En ovanlig kombination av inställningar och applikationskod kan lämna ytterligare en möjlighet till kodkörning.
PHP rekommenderar därför att stänga av session.upload_progress.enabled tills nästa ordinarie felrättningsutgåva, om miljön kan beröras. Det handlar om en särskild kombination där applikationen byter sessionsformat under körning samtidigt som funktionen för uppladdningsstatus är aktiv.
Det visar också varför jobbet behöver omfatta mer än att bara läsa ett versionsnummer och säga ”klart”.
En säkerhetsuppdatering täpper till kända hål. Den är inget bevis på att ett intrång aldrig har skett, och den gör inte att webbplatsen kan lämnas utan underhåll framöver.
Är du osäker på vilken PHP-version din webbplats använder eller vad som behöver göras? Kontakta oss på Formsmedjan, så hjälper vi dig att reda ut det.
Det var allt för mig den här gången.
Zacke
På Formsmedjan tror vi på kommunikation som kan bidra till något större....
Vissa lanseringar handlar om att sälja en ny produkt. Andra handlar om att ge...
Efter en sommar med tid för återhämtning och nya perspektiv är vi tillbaka –...
