Sammanfattning
Två kritiska sårbarheter i programmeringsspråket PHP kan göra det möjligt för en extern angripare att exekvera kod på en exponerad server utan att behöva autentisera sig.
Säkerhetsuppdateringar finns tillgängliga. Organisationer bör därför identifiera sina PHP-applikationer, uppdatera till korrigerade versioner och omgående starta om berörda tjänster.
PHP2Shell: Två kritiska sårbarheter möjliggör remote code execution
PHP har precis släppt säkerhetsuppdateringar för två kritiska sårbarheter i själva programmeringsspråket: CVE-2026-109618 och CVE-2026-109619. Sårbarheterna, som av flera researchers har fått namnet PHP2Shell, kan möjliggöra remote code execution utan autentisering, särskilt på PHP-servrar som är exponerade mot internet.
De korrigerade versionerna finns nu tillgängliga. Alla användare rekommenderas att omgående uppdatera sina installationer. Risken bedöms vara särskilt hög i miljöer som använder Apache mod_php, där forskare har visat att sårbarheterna kan utnyttjas innan applikationens kod körs.
Läs det officiella säkerhetsmeddelandet från PHP
Vilka versioner innehåller säkerhetsuppdateringarna?
Följande versioner innehåller säkerhetskorrigeringar:
PHP Branch | Corrected version |
PHP 8.5 | 8.5.12 |
PHP 8.4 | 8.4.27 |
PHP 8.3 | 8.3.36 |
PHP 8.2 | 8.2.35 |
Installationer av PHP 8.1 och äldre versioner omfattas inte längre av PHP-projektets ordinarie säkerhetsunderhåll. Säkerhetsuppdateringar kan dock erbjudas av vissa leverantörer, Linux-distributioner eller aktörer som tillhandahåller långsiktigt stöd (LTS). I annat fall bör en migrering till en version som fortfarande stöds planeras snarast.
PHP 8.2 har fått en säkerhetsuppdatering i denna release, men versionen är planerad att nå slutet av sin livscykel den 31 december 2026. Därför rekommenderas en uppgradering till en nyare version.
I PHP:s säkerhetsmeddelanden tilldelas dessa sårbarheter ett CVSS v4.0-poäng på 9,2, vilket motsvarar den kritiska allvarlighetsgraden.
Varför är denna säkerhetsvarning så viktig?
PHP används på ett mycket stort antal webbplatser, företagsportaler och applikationer som är exponerade mot internet. Risken är inte begränsad till ett visst ramverk eller CMS-system. Alla applikationer som körs på en sårbar PHP-miljö kan vara utsatta.
Bland annat har miljöer med WordPress, Drupal och Joomla använts i demonstrationsscenarier. Att uppdatera själva CMS-systemet är därför inte nödvändigtvis tillräckligt. Det är viktigt att identifiera och säkerhetsuppdatera den underliggande PHP-installationen.
Enligt rapporten från Orange Cyberdefense CERT, som ingår i denna analys, observerades försök att utnyttja sårbarheterna efter att de tekniska detaljerna offentliggjorts. Tillgången till offentliga proof of concept-exempel och förekomsten av flera miljoner exponerade PHP-tjänster kan bidra till att påskynda angrepp under de kommande dagarna.
Möjliga konsekvenser är bland annat:
- Körning av kommandon med webbprocessens behörigheter.
- Installation av skadlig programvara eller webbshells.
- Åtkomst till hemlig information i minnet, såsom lösenord, autentiseringstoken eller API-nycklar.
- Ändring av applikationernas innehåll.
- Åtkomst till de data som behandlas av servern.
- Vidarekoppling till andra komponenter i informationssystemet.
Vilka åtgärder bör vidtas omedelbart?
Berörda organisationer måste behandla denna varning som en prioriterad åtgärd för att åtgärda säkerhetsbrister.
1. Identifiera alla exponerade PHP-installationer
Inventeringen bör omfatta internetanslutna servrar, molnmiljöer, containrar, webbhotellplattformar och infrastrukturer som används av verksamhetskritiska applikationer.
Det är viktigt att identifiera:
- Den exakta PHP-versionen
- Vilket körningsläge som används: mod_php, PHP-FPM, CGI, FrankenPHP eller LiteSpeed.
- Apache-servrar och applikationer som är åtkomliga från internet.
- PHP-versioner som har nått slutet av sin livscykel och inte längre stöds.
- Installationer som inte finns registrerade i det centrala inventeringssystemet.
2. Uppdatera till en korrigerad version
PHP rekommenderar uppgradering till version 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, beroende på kompatibiliteten med den applikation och distribution som används.
Efter uppdateringen är det också nödvändigt att starta om de komponenter som laddar PHP-motorn, framför allt:
- Apache.
- PHP-FPM.
- Långlivade PHP-processer (persistent PHP workers).
- Berörda containrar eller tjänster.
3. Hantera äldre versioner
För PHP 8.1 och äldre versioner bör man kontrollera om säkerhetsuppdateringar finns tillgängliga via Linux-distributionen, utgivaren eller supportleverantören. Om inga tillförlitliga säkerhetsuppdateringar finns tillgängliga måste migreringen till en version som fortfarande stöds påskyndas.
4. Förstärk säkerhetskontrollerna tillfälligt
PHP beskriver flera åtgärder för att minska exponeringen för organisationer som inte kan uppdatera omedelbart.
Dessa åtgärder är tillfälliga och ger inte ett fullständigt skydd. Enligt PHP är uppdatering till en korrigerad version den enda fullständiga lösningen. De tillfälliga åtgärderna får därför inte försena installationen av de korrigerade versionerna.
5. Leta efter tecken på exploatering
Säkerhetsteamen måste granska webbserverloggar, Apache-loggar, PHP-FPM-loggar, detektionssystem och processrelaterade händelser för att identifiera:
- Ovanligt stora eller upprepade förfrågningar.
- Ovanliga fatala fel (fatal errors).
- Frekventa omstarter av processer (workers).
- Oväntade skapanden eller ändringar av filer.
- Underprocesser som startas av webbtjänster.
- Ovanliga utgående nätverksanslutningar från PHP-servrar.
- Misstänkt åtkomst till konfigurationsfiler eller hemlig information, såsom lösenord, autentiseringstoken och API-nycklar.
Att inga synliga säkerhetslarm förekommer utesluter inte att ett intrång har skett. Undersökningarna måste ta hänsyn till hur länge loggar sparas och vilken insyn som finns i de berörda servrarna.
Threat intelligence roll vid hantering av denna sårbarhet
I den här typen av krissituation beror reaktionshastigheten både på tillgången till en säkerhetsuppdatering och på förmågan att snabbt identifiera berörda tillgångar, exploateringsförsök och möjliga tecken på intrång.
CERT Orange Cyberdefense kan hjälpa organisationer med:
- Bedömning av exponering för sårbarheten.
- Prioritering av sårbara tillgångar.
- Kartläggning och verifiering av PHP-versioner och konfigurationer.
- Proaktiv sökning efter tecken på intrång.
- Övervakning av exploateringskampanjer.
- Samordning mellan infrastruktur-, applikations- och säkerhetsteam.
- Införande av detektions- och incidenthanteringsåtgärder.
Behöver ni hjälp med att bedöma er exponering för PHP-sårbarheten? CERT Orange Cyberdefense kan hjälpa er att identifiera berörda miljöer, prioritera åtgärder för att åtgärda sårbarheten och undersöka eventuella tecken på intrång.
Kontakta våra team på: cert-contact.ocd@orange.com
Q&A
Gäller dessa sårbarheter endast WordPress?
Nej. De påverkar själva PHP-motorn. WordPress, Drupal, Joomla och andra applikationer kan vara sårbara om de körs på en sårbar PHP-version.
Räcker det att uppdatera mitt CMS?
Nej. Du måste uppdatera PHP-miljön (runtime) och starta om de berörda tjänsterna. En uppdatering av CMS:et åtgärdar inte automatiskt den installerade PHP-motorn på servern.
Är PHP-FPM påverkat?
Enligt PHP måste alla PHP-installationer som hanterar webbförfrågningar utvärderas, inklusive PHP-FPM. Exponeringsgraden beror bland annat på konfigurationen, den främre webbservern (front-end-servern) och vilka exekveringsvägar som används.
Finns det någon tillräcklig tillfällig åtgärd?
Nej. PHP anger att åtgärder för att minska exponeringen inte utgör en fullständig lösning. Installation av en korrigerad version är fortfarande den enda definitiva lösningen.
Har PHP 8.2 och äldre versioner fortfarande säkerhetsstöd?
PHP 8.2 får fortfarande säkerhetsuppdateringar, bland annat i version 8.2.35, men den här versionsgrenen är planerad att nå slutet av sin livscykel (End of Life, EOL) den 31 december 2026.
PHP 8.1 och äldre versioner omfattas inte längre av PHP:s ordinarie säkerhetsstöd.
