PHP2Shell: Kritiska PHP-säkerhetshål – så patchar ni nu

21 oktober 2026 | PHP | IT-säkerhet

Den 21 oktober 2026 publicerade PHP:s säkerhetsteam uppdateringar för alla PHP-versioner som fortfarande stöds. De täpper till två kritiska sårbarheter som har blivit kända som PHP2Shell. BSI har utfärdat en varning om detta och kräver att berörda system patchas utan dröjsmål. Den som driver en webbserver med PHP bör agera redan i dag. Det gäller även alla som ”bara” driver en WordPress, Nextcloud eller Joomla, eftersom dessa applikationer körs på PHP.

Det här inlägget sammanfattar vad som har hänt, vilka PHP-versioner som berörs, vilken version ni behöver nu och hur ni på några minuter kontrollerar om er server är skyddad.

Vad har hänt? Tidsförloppet

PHP:s säkerhetsteam har i förväg aviserat publiceringen av rättelserna så att webbhotell och administratörer hade tid att förbereda sig. Själva publiceringen skedde den 21 oktober 2026. BSI utfärdade sin varning (version 1.1) samma dag.

• 20 oktober 2026: Förvarning från PHP:s säkerhetsteam om att säkerhetsuppdateringar publiceras dagen därpå.
• 21 oktober 2026, 14:00 UTC (kl. 16:00 CEST): Patcharna för PHP 8.5, 8.4, 8.3 och 8.2 publiceras.
• 21 oktober 2026: BSI varnar för de ”kritiska sårbarheter som hotar webbapplikationer världen över” och rekommenderar att patcha utan dröjsmål. Enligt BSI har stora hostingleverantörer delvis tagit servrar offline som en försiktighetsåtgärd.

De båda PHP-sårbarheterna i överblick

Det rör sig om två separata fel i PHP-kärnan: CVE-2026-109618 och CVE-2026-109619. Enligt PHP:s säkerhetsteam kan båda leda till att en angripare kan köra programkod på servern utan att logga in (unauthenticated Remote Code Execution). Sårbarheterna bedöms med CVSS v4.0: 9,2 (kritisk).

Enligt BSI:s bedömning fanns det vid tidpunkten för publiceringen inga bekräftade angrepp, men det fanns obekräftade indikationer på utnyttjandeförsök. Vid kritiska säkerhetshål i så utbredd programvara måste man enligt erfarenhet räkna med att angripare analyserar rättelserna och förbereder automatiserade angrepp. Tidsfönstret för patchning är därför kort.

Vem berörs?

Berörd är i princip varje server där PHP körs, oavsett hur PHP är kopplat: PHP-FPM, mod_php i Apache, php-cgi, FrankenPHP eller LiteSpeed. Enligt PHP:s säkerhetsteam är risken störst vid Apache med mod_php.

BSI nämner uttryckligen applikationer som bygger på PHP och därför kan vara medberörda:

• Innehållshanteringssystem: WordPress, Drupal, TYPO3, Joomla
• Webbutikssystem: Magento
• Moln- och fillagring: Nextcloud
• Brandväggsgränssnitt: pfSense, OPNsense

Själva applikationen behöver för detta inte vara felaktig. Säkerhetshålet ligger i PHP, därför hjälper en uppdatering av enbart WordPress, Nextcloud & Co. inte. PHP-versionen på servern måste uppdateras. För brandväggar som pfSense och OPNsense kommer den rättade PHP-versionen via tillverkarens respektive firmware-uppdatering.

Dessa PHP-versioner är säkra

Sårbarheterna är åtgärdade i följande versioner. Allt under dessa räknas som sårbart.

Så kontrollerar och uppdaterar ni er server

1. Fastställ installerad PHP-version

På serverns kommandorad visar php -v versionen av kommandoradens PHP. Webbservern kan använda en annan PHP-version. Kontrollera därför också versionen av PHP-FPM respektive Apache-modulen, till exempel med php-fpm8.3 -v eller via en sida som skriver ut phpinfo() (ta sedan genast bort den igen).

2. Installera uppdateringen via pakethanteringen

På Debian, Ubuntu, RHEL och släktingar kommer den rättade versionen via den vanliga pakethanteringen, till exempel apt update && apt upgrade eller dnf upgrade. Vid externa källor som Sury-PPA eller Remi-Repository dyker de nya paketen oftast upp inom kort.

3. Starta om PHP-tjänsten

En paketuppdatering ensam räcker inte: körande PHP-processer behåller den gamla koden i minnet. Starta om PHP-FPM (systemctl restart php8.3-fpm) respektive Apache (systemctl restart apache2), och kontrollera därefter om processerna startades efter uppdateringen.

4. Webbplatser hos webbhotell

Vid delat webbhotell uppdaterar normalt leverantören. I kundmenyn går det oftast att ställa in PHP-versionen per webbplats. Välj där en av de säkra versionerna som nämns ovan, eller fråga leverantören om läget för patcharna. Enligt BSI har enskilda leverantörer tagit servrar från nätet som en försiktighetsåtgärd. Om er webbplats tillfälligt inte är nåbar kan det vara orsaken.

PHP 8.1 och äldre: ingen officiell uppdatering

För PHP 8.1 och äldre finns inga officiella säkerhetsuppdateringar längre. Operatörer av sådana system har två möjligheter:

• Byta till en version som stöds (rekommenderas). Ju äldre versionen är, desto större är anpassningsarbetet för applikation och tillägg, därför bör ett byte testas i förväg.
• Föra tillbaka rättelser (backport). PHP:s säkerhetsteam har gjort rättelserna tillgängliga i utvecklingsgrenar på GitHub. Den som kompilerar PHP själv kan föra över dessa ändringar till äldre versioner. Det är en övergångslösning och kräver specialistkunskap.

Även PHP 8.2 stöds bara till och med den 31 december 2026. Planera därför in övergången till PHP 8.4 eller 8.5 nu, och skjut inte upp den till årsskiftet.

Övergångsåtgärder och frågan ”Ta servern offline?”

PHP:s säkerhetsteam har i samband med aviseringen också beskrivit tillfälliga skyddsåtgärder. Dessa minskar risken men täpper inte till säkerhetshålen fullständigt. De ersätter inte uppdateringen och är bara avsedda att överbrygga tiden fram till uppdateringen.

Om en server bör tas från nätet fram till uppdateringen beror på dess betydelse och nåbarhet. BSI anger att stora leverantörer har tagit det steget. Som tumregel gäller:

• Offentligt nåbar server, uppdatering möjlig nu: patcha omedelbart, ingen avstängning nödvändig.
• Offentligt nåbar server, uppdatering inte möjlig på kort sikt: begränsa åtkomsten (till exempel via brandväggen enbart för kända adresser) eller stäng av tjänsten tillfälligt, särskilt vid mod_php.
• Enbart internt nåbar server: patcha inom kort, brådskan är lägre.

Vanliga frågor

Måste jag uppdatera WordPress, Joomla eller Nextcloud?

Inte på grund av den här sårbarheten. Den finns i PHP, inte i applikationen. Uppdatera PHP-versionen på servern. En uppdatering av applikationen är ändå meningsfull oberoende av detta.

Hur ser jag om någon redan har utnyttjat sårbarheten?

Det är svårt att få ett säkert svar. Varningssignaler är okända PHP-filer i webbkatalogen, ovanliga processer under webbserveranvändaren, nya användarkonton eller cronjobb samt ovanlig utgående datatrafik. Vid en konkret misstanke bör systemet undersökas forensiskt och i tveksamma fall sättas upp på nytt.

Räcker det med en Web Application Firewall?

En brandvägg kan fånga upp kända angreppsmönster, men är ingen ersättning för uppdateringen. Mer om samspelet mellan flera skyddslager kan du läsa i vårt inlägg Säkra Odoo 19: brandvägg, 2FA & Web RBL. Principerna gäller för alla webbapplikationer.

Påverkas Odoo?

Nej. Odoo är skrivet i Python och körs inte på PHP. Det är bara PHP-applikationer som körs på samma server som kan påverkas.

Var hittar jag den officiella informationen?

Tillkännagivandet från PHP:s säkerhetsteam finns i nyhetsarkivet på php.net (inlägg från den 20 oktober 2026), versionerna under php.net/downloads. BSI:s varning har numret 2026-297981-1032 och är publicerad på bsi.bund.de .

Stöd från Biricon IT Services

Om du inte är säker på vilken PHP-version som körs på din server, eller behöver hjälp med patchningen, hjälper vi dig gärna: med inventering av alla PHP-system, med installation av uppdateringarna, med övergången till en PHP-version som fortfarande stöds och med kontroll av eventuellt intrång. Som IT-leverantör sköter vi servrar, brandväggar och webbapplikationer för små och medelstora företag.

Kontakta oss nu

Läget per den 21 oktober 2026. Situationen kan snabbt förändras; avgörande är publikationerna från PHP:s säkerhetsteam och BSI.