Kort sagt: Den aktuella Magento-sårbarheten heter PHP2Shell och finns inte i Magento utan i PHP. En Magento-patch stänger den inte. Efter PHP-uppdateringen med omstart bör ni kontrollera app/etc/env.php, databasen med avseende på skimmers och listan över administratörskonton.
Vad PHP2Shell betyder för Magento-butiker
Magento Open Source och Adobe Commerce är stora PHP-applikationer som oftast körs med PHP-FPM. Sårbarheterna CVE-2026-109618 och CVE-2026-109619 gör det enligt PHP-teamet möjligt att köra skadlig kod utan inloggning. Om butiken själv är uppdaterad spelar ingen roll för detta.
Magento-butiker har i flera år varit ett favoritmål för kreditkortsskimming, där inmatningen i kassan läses av. PHP2Shell öppnar ytterligare en väg för det. Palo Alto Networks räknade mer än 22,6 miljoner exponerade, potentiellt sårbara PHP-instanser; vilka butiker som ingår är inte känt.
Magento-sårbarhet: fastställ PHP-statusen på rätt sätt
Magento visar inte PHP-versionen framträdande i administrationen. Kontrollera statusen därför i hostingpanelen för domänen eller låt webbhotellet bekräfta den. php -v på kommandoraden visar bara CLI-PHP, som bin/magento och cronjobb använder. Webb-PHP via FPM kan vara en annan version, och båda måste vara patchade.
Åtgärdade upstream-versioner är 8.5.12, 8.4.27, 8.3.36 och 8.2.35, distributionernas backports kan bära äldre nummer. Vilka PHP-versioner er Magento-version stöder kontrollerar ni enligt systemkraven i Adobes dokumentation (experienceleague.adobe.com). Hos Adobe Commerce på Adobes infrastruktur frågar ni Adobe eller er driftleverantör om läget. En steg-för-steg-anvisning finns i Kontrollera PHP-version och patchstatus på rätt sätt.
Var skadlig kod sitter i Magento
| Plats | Innehåll | Kontrollpunkt |
|---|---|---|
app/etc/env.php |
Databas, krypteringsnyckel, admin-sökväg | Ändringsdatum, förnya värden vid misstanke |
pub/ |
Dokumentrot, pub/media, pub/static |
PHP-filer i media- och static-mapparna |
app/code/ |
egna moduler | okända moduler, ändrade filer |
vendor/ |
Composer-paket, även tillägg | Avvikelser från lockfilen |
generated/, var/ |
genererad kod, cache, loggar | Säkra loggar, generera om koden |
| Databas | Konfiguration, CMS-block, administratörer | främmande skript, nya administratörer |
Skimmers ligger i Magento ofta i databasen, till exempel i inställningarna för extra skript i sidhuvud eller sidfot och i CMS-block. En ren filskanning missar dem. Ofarliga läsåtkomster hjälper vid första anblicken (tabellprefix beroende på installation):
bin/magento info:adminuri
bin/magento module:status
SELECT username, email, created FROM admin_user;
SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '%<script%';
En rensad kassa betyder inte att inga data har läckt ut. Säkra loggar från och med den 20 oktober 2026 och databasutdrag innan ni tar bort skript. Bara så går det i efterhand att fastställa från när och vilka beställningar som berördes.
Administrationsområde och tillägg
Admin-sökvägen är fritt valbar i Magento och står i env.php. En sökväg som är svår att gissa är meningsfull, men ersätter inte tvåfaktorsinloggning eller en begränsning till kända nät. Kontrollera administratörerna och deras roller regelbundet, likaså integrationer och API-token.
Tillägg från tredje part är många i Magento: betalsätt, ERP-kopplingar, sök- och marknadsföringsmoduler. Varje sådant innehåller kod som måste kontrolleras vid PHP-uppgraderingar. Använd composer audit regelbundet och ta bort avstängda moduler helt.
Tänk också på bakgrundsprocesserna. Magento arbetar med cronjobb och ofta med kö-konsumenter som körs som egna PHP-processer via kommandoraden. Efter PHP-uppdateringen måste dessa startas om på samma sätt som PHP-FPM. Efter ett byte av PHP-huvudversion bör ni dessutom låta bygga om den genererade koden i generated/ och de statiska filerna och klicka igenom butiken i en testmiljö innan driften återupptas. Hur omstarten görs på rätt sätt beskrivs i Starta om PHP-FPM och alla workers.
Vad en Magento-uppdatering klarar och inte klarar
En Magento-release eller säkerhetspatch från Adobe stänger fel i butikskoden. Den patchar inte PHP, startar inte om några FPM-processer, tar inte bort skript ur databasen och raderar inga främmande administratörskonton. Har kod redan körts krävs en undersökning. Hur ni känner igen bakdörrar förklaras i Känna igen och ta bort webbshells.
För handlare med kortbetalning gäller dessutom: kontrollera betalleverantörens regler för säkerhetsincidenter och stäm av med denne innan ni förnyar nycklar. Om en anmälan till dataskyddsmyndigheten behövs klarar ni ut tillsammans med ert dataskyddsombud eller en advokat.
Hur hjälper PHP SOS konkret?
- Vi klarlägger webb- och CLI-PHP på er Magento-server och låter patch och omstart bekräftas.
- Vi säkrar loggar, filer och databas spårbart, vid behov via vår IT-forensik.
- Vi kontrollerar
env.php,pub/, moduler, konfigurationstabeller, CMS-block och administratörskonton. - Vi sanerar, förnyar nycklar och åtkomster och dokumenterar tidsperioden för möjlig påverkan för dataskydd och betalleverantör.
Vanliga frågor
Stänger en Magento-säkerhetspatch även PHP2Shell?
Nej. Magento-patchar åtgärdar fel i butikskoden. PHP2Shell finns i serverns PHP-tolk och stängs bara av en PHP-uppdatering eller en bekräftad backport med omstart av alla processer.
Var gömmer angripare kreditkortsskimmers i Magento?
Ofta inte i filer utan i databasen, till exempel i inställningarna för extra skript i sidhuvudet eller i CMS-block. Därför hör en kontroll av databasen alltid till efter en misstanke.
Vem patchar PHP hos Adobe Commerce i molnet?
Det beror på ert avtal och er miljö. Fråga Adobe eller er driftleverantör skriftligen om PHP-status och omstart. Egna tillägg och databasinnehåll är fortfarande ert ansvar.
Varför är app/etc/env.php så viktig?
Filen innehåller databasåtkomst, krypteringsnyckeln och sökvägen till administrationsområdet. Den som kunde läsa den kan dekryptera krypterade värden och hitta administrationen. Vid misstanke bör dessa värden förnyas.