# Magento-sårbarhet PHP2Shell: skydda Magento och Adobe Commerce > Skydda Magento och Adobe Commerce efter PHP2Shell: klarlägg PHP-status, skydda env.php, hitta skimmers i databasen och pub/ samt kontrollera admin. Källa: https://phpsos.de/sv/plattformen/magento-adobe-commerce/ Aktualitet: 2026-10-25 Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6 **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](https://phpsos.de/sv/php2shell/php-version-pruefen/). ## 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): ```bash bin/magento info:adminuri bin/magento module:status ``` ```sql SELECT username, email, created FROM admin_user; SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '% **Viktigt:** > 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](https://phpsos.de/sv/php2shell/php-fpm-neustart/). ## 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](https://phpsos.de/sv/ratgeber/webshell-erkennen/). 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](https://phpsos.de/sv/leistungen/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. ## Källor - [php.net: säkerhetsmeddelanden](https://www.php.net/) - [Adobe Commerce](https://business.adobe.com/) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/) - [Palo Alto/TechTarget: exponerade instanser](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)