# Magento-sårbarhed PHP2Shell: sådan sikrer I Magento og Adobe Commerce > Sikr Magento og Adobe Commerce efter PHP2Shell: afklar PHP-status, beskyt env.php, find skimmere i database og pub/, og kontrollér admin-konti. Kilde: https://phpsos.de/da/plattformen/magento-adobe-commerce/ Status: 25.10.2026 Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6 **Kort sagt:** Den aktuelle Magento-sårbarhed hedder PHP2Shell og sidder ikke i Magento, men i PHP. En Magento-patch lukker den ikke. Efter PHP-opdateringen med genstart bør I kontrollere `app/etc/env.php`, databasen for skimmere og listen over admin-konti. ## Hvad PHP2Shell betyder for Magento-shops Magento Open Source og Adobe Commerce er store PHP-applikationer, der som regel kører med PHP-FPM. Sårbarhederne CVE-2026-109618 og CVE-2026-109619 gør det ifølge PHP-teamet muligt at køre skadelig kode uden login. Om shoppen selv er opdateret, spiller ingen rolle for det. Magento-shops har i årevis været et foretrukket mål for kreditkort-skimming, hvor indtastninger i checkout læses med. PHP2Shell åbner endnu en vej hertil. Palo Alto Networks talte mere end 22,6 millioner eksponerede, potentielt sårbare PHP-instanser; hvilke shops der er iblandt, vides ikke. ## Magento-sårbarhed: fastslå PHP-status korrekt Magento viser ikke PHP-versionen fremtrædende i admin. Kontrollér derfor status i hostingpanelet for domænet, eller lad hostingudbyderen bekræfte den. `php -v` på kommandolinjen viser kun CLI-PHP, som `bin/magento` og cronjobs kører med. Web-PHP via FPM kan være en anden version, og begge skal være patchet. Rettede upstream-versioner er 8.5.12, 8.4.27, 8.3.36 og 8.2.35, distributioners backports kan bære ældre numre. Hvilke PHP-versioner jeres Magento-version understøtter, kontrollerer I ifølge systemkravene i Adobes dokumentation (experienceleague.adobe.com). Ved Adobe Commerce på Adobes infrastruktur spørger I Adobe eller jeres driftsleverandør om status. En trin-for-trin-vejledning findes i [Kontrollér PHP-version og patch-status korrekt](https://phpsos.de/da/php2shell/php-version-pruefen/). ## Hvor skadelig kode sidder i Magento | Sted | Indhold | Kontrolpunkt | |---|---|---| | `app/etc/env.php` | Database, krypteringsnøgle, admin-sti | Ændringsdato, forny værdier ved mistanke | | `pub/` | Dokumentrod, `pub/media`, `pub/static` | PHP-filer i medie- og static-mapper | | `app/code/` | egne moduler | ukendte moduler, ændrede filer | | `vendor/` | Composer-pakker, også udvidelser | afvigelser fra lockfilen | | `generated/`, `var/` | genereret kode, cache, logs | sikre logs, generér kode på ny | | Database | Konfiguration, CMS-blokke, admin-brugere | fremmede scripts, nye admins | Skimmere ligger i Magento ofte i databasen, for eksempel i indstillingerne for yderligere scripts i sidehoved eller sidefod og i CMS-blokke. En ren filscanning overser dem. Ufarlige læseadgange hjælper ved første blik (tabelpræfiks afhængigt af installationen): ```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 '% **Vigtigt:** > En renset checkout betyder ikke, at der ikke er sivet data ud. Sikr logs fra 20.10.2026 og database-udtræk, før I fjerner scripts. Kun sådan kan det senere fastslås, fra hvornår og hvilke ordrer der var berørt. ## Admin-området og udvidelser Admin-stien kan i Magento vælges frit og står i `env.php`. En sti, der er svær at gætte, er fornuftig, men erstatter hverken totrinsgodkendelse eller en begrænsning til kendte netværk. Kontrollér admin-brugerne og deres roller regelmæssigt, ligeså integrationer og API-tokens. Udvidelser fra tredjepartsudbydere er talrige i Magento: betalingsmetoder, ERP-integrationer, søge- og marketingmoduler. Hver medbringer kode, som skal kontrolleres ved PHP-opgraderinger. Brug `composer audit` regelmæssigt, og fjern slukkede moduler fuldstændigt. Tænk også på baggrundsprocesserne. Magento arbejder med cronjobs og ofte med kø-consumers, som kører som egne PHP-processer via kommandolinjen. Efter PHP-opdateringen skal disse genstartes ligesom PHP-FPM. Efter et skifte af PHP-hovedversion bør I desuden få den genererede kode i `generated/` og de statiske filer bygget på ny og gennemklikke shoppen i et testmiljø, før driften i live tages op igen. Hvordan genstarten lykkes rent, beskriver [Genstart PHP-FPM og alle workers](https://phpsos.de/da/php2shell/php-fpm-neustart/). ## Hvad en Magento-opdatering kan, og hvad den ikke kan En Magento-release eller sikkerhedspatch fra Adobe lukker fejl i shoppens kode. Den patcher ikke PHP, genstarter ikke FPM-processer, fjerner ikke scripts fra databasen og sletter ikke fremmede admin-konti. Er der allerede kørt kode, kræves der en undersøgelse. Hvordan I opdager bagdøre, forklarer [Opdag og fjern webshells](https://phpsos.de/da/ratgeber/webshell-erkennen/). For forhandlere med kortbetaling gælder desuden: Kontrollér jeres betalingsudbyders regler for sikkerhedshændelser, og afstem med denne, før I fornyer nøgler. Om en anmeldelse til tilsynsmyndigheden for databeskyttelse er nødvendig, afklarer I med jeres databeskyttelsesrådgiver eller advokat. ## Hvordan hjælper PHP SOS konkret? - Vi afklarer web- og CLI-PHP på jeres Magento-server og lader rettelse og genstart bekræfte. - Vi sikrer logs, filer og database sporbart, om nødvendigt via vores [IT-forensik](https://phpsos.de/da/leistungen/it-forensik/). - Vi kontrollerer `env.php`, `pub/`, moduler, konfigurationstabeller, CMS-blokke og admin-konti. - Vi renser, fornyer nøgler og adgange og dokumenterer perioden for mulig berørthed til databeskyttelsen og betalingsudbyderen. ## Ofte stillede spørgsmål **Lukker en Magento-sikkerhedspatch også PHP2Shell?** Nej. Magento-patches udbedrer fejl i shoppens kode. PHP2Shell ligger i serverens PHP-fortolker og lukkes kun af en PHP-opdatering eller en bekræftet backport med genstart af alle processer. **Hvor skjuler angribere kreditkort-skimmere i Magento?** Ofte ikke i filer, men i databasen, f.eks. i indstillinger for yderligere scripts i sidehovedet eller i CMS-blokke. Derfor hører en kontrol af databasen altid med ved en mistanke. **Hvem patcher PHP ved Adobe Commerce i skyen?** Det afhænger af jeres kontrakt og jeres miljø. Spørg Adobe eller jeres driftsleverandør skriftligt om PHP-status og genstarten. Egne udvidelser og databaseindhold forbliver jeres ansvar. **Hvorfor er app/etc/env.php så vigtig?** Filen indeholder databaseadgang, krypteringsnøglen og stien til admin-området. Den, der kunne læse den, kan dekryptere krypterede værdier og finde admin. Ved mistanke bør disse værdier fornyes. ## Kilder - [php.net: Sikkerhedsmeddelelser](https://www.php.net/) - [Adobe Commerce](https://business.adobe.com/) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/) - [Palo Alto/TechTarget: eksponerede instanser](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)