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.
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):
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 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.
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.
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.
- 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.