Vad är PHP2Shell?
PHP2Shell är namnet på två sårbarheter i PHP, CVE-2026-109618 och CVE-2026-109619. PHP-projektet släppte rättningarna den 21 oktober 2026 på eftermiddagen svensk tid. Båda sårbarheterna har den officiella allvarlighetsgraden 9,2 av 10 enligt CVSS v4.0. Under vissa förutsättningar kan en angripare köra egen kod på webbservern utan att logga in.
Rättade versioner finns för fyra versionsgrenar av PHP:
- 8.2.35
- 8.3.36
- 8.4.27
- 8.5.12
CERT-SE publicerade en varning samma dag. Fem dagar senare lade den amerikanska myndigheten CISA till båda sårbarheterna i sin lista över sårbarheter som används i faktiska attacker.
Vad det betyder för en Magento-butik
Magento och Adobe Commerce körs på PHP. Det gäller även Shopware och WooCommerce. Sårbarheterna sitter i själva PHP. En Magento-butik med alla Adobes säkerhetspatchar installerade kan därför fortfarande vara exponerad.
Det omvända gäller också. En uppdaterad PHP-version ersätter inte Magentos egna säkerhetspatchar. Butiken behöver båda. Ansvaret för de två delarna ligger dessutom ofta hos olika parter. Webbhotellet sköter normalt PHP på servern. Byrån eller den interna utvecklaren sköter normalt Magento.
Så kontrollerar du att butiken är uppdaterad
Kontrollen ska gälla den PHP som faktiskt hanterar besökarnas anrop. En server kan ha flera PHP-versioner installerade. Kommandoraden kan visa en rättad version medan webbservern fortfarande kör en äldre.
- Kontrollera versionsnumret för webbserverns PHP. Den som har serveråtkomst eller tillgång till hostingpanelen kan se det. Jämför med de rättade versionerna ovan.
- Kontrollera att PHP har startats om efter uppdateringen. En installerad uppdatering börjar gälla först när PHP-processerna har startats om.
- Fråga efter källan om versionsnumret är lägre. PHP från en Linux-distributions paket kan ha ett äldre versionsnummer trots att rättningen finns med. Då ska leverantören kunna visa distributionens säkerhetsmeddelande för paketet.
- Glöm inte testmiljöer. En äldre testmiljö som är nåbar från internet och delar databas med butiken kan ge samma åtkomst som den riktiga butiken. Den behöver samma uppdatering.
- Få svaret skriftligt. Ett versionsnummer och ett datum för installationen säger mer än ett muntligt ja.
Vad du bör fråga ditt webbhotell
Webbhotellet är oftast rätt part att fråga först, eftersom det sköter PHP på servern. Frågorna nedan ger ett svar du kan kontrollera.
- Vilken PHP-version och vilket paket kör webbservern för vår butik i dag?
- När installerades rättningen för CVE-2026-109618 och CVE-2026-109619?
- Har både webbserverns PHP och kommandoradens PHP uppdaterats?
- Sparar ni loggar från tiden före uppdateringen, om vi behöver leta efter spår av intrång?
- Hur hanterar ni nästa kritiska PHP-release, och hur snabbt får vi besked?
Om webbhotellet bara erbjuder servern och inte sköter PHP, ligger ansvaret hos den som administrerar servern. Det kan vara byrån eller en intern resurs. Guiden om molninfrastruktur för e-handel går igenom hur ansvaret brukar delas mellan hosting och utveckling.
Om butiken kör PHP 8.1 eller äldre
PHP-projektet släppte inga officiella rättningar för version 8.1 och äldre. Butiker på PHP 7.4 till 8.1 är beroende av att Linux-distributionen eller webbhotellet har lagt in en egen rättning.
CERT-SE rekommenderar att internetexponerade PHP-applikationer isoleras från publika nät om uppdateringarna inte kan installeras. För en e-handel är det i praktiken en nödåtgärd, eftersom butiken då inte kan ta emot kunder. Den långsiktiga åtgärden är att uppgradera PHP.
En PHP-uppgradering kräver ofta en Magento-uppgradering, eftersom varje Magento-version bara stöder vissa PHP-versioner. Moduler från tredje part behöver också testas mot den nya versionen. Planera därför uppgraderingen som ett projekt med testmiljö. Om butiken ändå står inför ett större plattformsbeslut beskriver guiden om byte av e-handelsplattform vad ett sådant byte innebär.
Kontrollera tecken på intrång efter uppdateringen
En uppdatering stänger hålet för nya angripare. Den tar inte bort en angripare som redan har tagit sig in. Detaljerna om sårbarheterna läckte dagen före rättningen, och attacker bekräftades inom några dagar. En butik som uppdaterades sent bör därför kontrolleras för spår av intrång.
På e-handelssajter slutar ett intrång ofta med en betalningsskimmer i kassan. Den kopierar kortuppgifter medan kunden skriver in dem och syns i kundens webbläsare snarare än på servern. Ett annat vanligt spår är en bakdörr i form av okända PHP-filer på servern. Nya adminkonton och okända schemalagda uppgifter är också värda att kontrollera. Guiden om skadlig kod i e-handeln förklarar hur skanning på serversidan och övervakning av kassan kompletterar varandra.
Erfarenheterna från tidigare Magento-sårbarheter pekar åt samma håll. Artikeln Magento-säkerhet: lärdomar från SessionReaper och CosmicSting visar hur tiden mellan rättning och installation avgjorde vilka butiker som drabbades.
Sätt en rutin för nästa release
Fler kritiska PHP-releaser kommer att följa. Den viktigaste lärdomen är att tiden från släpp till installation räknas i timmar. Hos Nordic Web Team var alla kunder som kör PHP uppdaterade inom 17 timmar, vilket artikeln om PHP-uppdateringen beskriver steg för steg.
En fungerande rutin kräver ett namngivet ansvar för PHP och ett för plattformen. Den kräver också en aktuell lista över vilka PHP-versioner butikens miljöer kör, och en överenskommen tidsram för kritiska uppdateringar. Med det på plats tar frågan om butiken är uppdaterad minuter att besvara.