PHP-säkerhetsuppdatering: patcha först, granska sedan hemligheter och åtkomst

Den 21 oktober 2026 släppte PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35 för att rätta CVE-2026-109618 och CVE-2026-109619, kritiska sårbarheter som kan tillåta fjärrkörning av kod utan autentisering. Det officiella beskedet pekar ut installationer som hanterar webbförfrågningar, bland annat PHP-FPM och Apache mod_php. Uppdatering är den fullständiga lösningen; tillfälliga begränsningar är inte likvärdiga.

En sårbar installation bevisar inte ett intrång. Behandla patchning, undersökning och återställning av autentiseringsuppgifter som sammanhängande uppgifter och fatta beslut utifrån miljö och bevis.

Kontrollera vad som faktiskt hanterar förfrågningar

Inventera offentliga webbplatser, interna tjänster, containrar och webbhotellskonton som kör PHP. Bekräfta version och patchstatus för miljön som hanterar webbförfrågningar. Kommandoradens version kan avse en annan installation.

Vid hanterad drift, be operatören bekräfta tillämpat paket, berörd tjänst och omstart eller utrullning. Distributioner kan bakåtportera rättningar, så be om deras bekräftelse i stället för att bara läsa det ursprungliga versionsnumret. Kontrollera omfattningen tillsammans med operatören med PHP-teamets säkerhetsråd. Publicera ingen diagnostiksida som visar serverkonfiguration.

Begränsa exponeringen och återställ en betrodd miljö

Samordna uppdateringen snabbt med driftteam eller webbhotell. Begränsa exponering eller isolera system om incidentbedömningen kräver det, samtidigt som relevanta bevis bevaras. Skjut inte upp brådskande begränsning för att först samla klart loggar.

Granska exponeringsperiod, webb- och systemloggar, oväntade filer eller processer och relevanta granskningshändelser hos leverantörer. Uteblivna larm eller normalt utseende loggar bevisar inte att värden är orörd.

Vid bekräftat eller rimligen misstänkt intrång, följ incidentprocessen för att bygga om eller återställa från betrodd källa. En patch tar inte bort angriparens kvarvarande åtkomstmekanismer. Skapa, ta emot eller installera inte nya hemligheter på en obetrodd värd eller enhet.

Bedöm uppgifterna innan de roteras

Lista det som den berörda processen kunde nå: programkonfiguration, miljövariabler, distributionstoken, databasuppgifter och leverantörers API-nycklar. Fastställ behörighet, omfattning och möjlig exponering. Beskedet ensamt visar inte att organisationens alla uppgifter har läckt.

För potentiellt exponerade uppgifter, samordna byte och återkallelse hos utfärdaren från en betrodd administratörsenhet. Installera ersättningar i den betrodda ombyggda miljön och verifiera legitima integrationer. Välj ordning efter pågående missbruk, leverantörens funktioner och tjänsternas beroenden. Lova inte avbrottsfri drift och låt inte en exponerad nyckel vara aktiv obegränsat av bekvämlighet.

Granska sessioner och återställningsåtkomst när det behövs och dokumentera ansvarig för varje ändring. Lägg aldrig råa hemligheter i incidentärendet eller loggen. OWASP

Avsluta nödåtkomst efter arbetet

Ge insatspersoner egna konton med små behörigheter och en överenskommen sluttid. Granska tillfälliga roller, sessioner, distributionsåtkomst och överlämningslänkar efter återställning. Ta bort kvarvarande åtkomst som inte behövs och kontrollera resultatet i respektive tjänst, inte enbart genom en kalenderpåminnelse.

Skilj på tre olika kontroller

Kontroll	Vad den ändrar	Vad den inte gör
Utgången överlämningslänk	Senare åtkomst genom länken	Återkallar leverantörens uppgift
Återkallad leverantörsnyckel	Om leverantören godtar nyckeln	Raderar kopior eller reparerar en angripen värd
Raderat meddelande eller anteckning	Tillgänglighet i det systemet	Hämtar tillbaka nedladdningar, skärmbilder eller text

Överlämna tillfälligt först när förtroendet återställts

Om processen tillåter det, skapa en lösenordsskyddad anteckning från ett betrott system med bara det en verifierad mottagare behöver. Skicka lösenordet separat och använd utgångstid eller åtkomstgränser när abonnemanget stöder dem. Lägg inte in plånbokens återställningsfraser eller privata nycklar.

LOCK.PUB är ett begränsat överlämningsverktyg: det patchar inte PHP, reparerar inte smittade enheter, återkallar inte leverantörsnycklar och hämtar inte tillbaka kopior. Det ersätter inte hemlighetshanterare, identitetskontroller eller incidenthantering.

Vanliga frågor

Är undersökningen klar när PHP-uppdateringen installerats?

Nej. Den rättar sårbarheten; bevis och exponering avgör vilken undersökning, återställning och hantering av uppgifter som återstår.

Stängs API-nyckeln av när anteckningen löper ut?

Nej. Återkalla eller byt nyckeln hos leverantören. En kopierad uppgift är skild från länken som levererade den.

Läs även: dela API-nycklar med tydliga gränser.