Kort gezegd: Het actuele Magento-beveiligingslek heet PHP2Shell en zit niet in Magento, maar in PHP. Een Magento-patch sluit het niet. Controleer na de PHP-update met herstart app/etc/env.php, de database op skimmers en de lijst met beheerdersaccounts.
Wat PHP2Shell betekent voor Magento-webshops
Magento Open Source en Adobe Commerce zijn grote PHP-applicaties die meestal met PHP-FPM draaien. De kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 maken het volgens het PHP-team mogelijk om zonder inloggen schadelijke code uit te voeren. Of de webshop zelf actueel is, speelt daarbij geen rol.
Magento-webshops zijn al jaren een geliefd doelwit voor creditcardskimming, waarbij invoer in de checkout wordt meegelezen. PHP2Shell opent daarvoor nog een extra weg. Palo Alto Networks telde meer dan 22,6 miljoen blootgestelde, potentieel kwetsbare PHP-instanties; welke webshops daaronder vallen, is niet bekend.
Magento-beveiligingslek: de PHP-status goed vaststellen
Magento toont de PHP-versie niet prominent in de beheeromgeving. Controleer de status daarom in het hostingpaneel voor het domein of laat haar door uw hostingprovider bevestigen. php -v op de opdrachtregel toont alleen de CLI-PHP waarmee bin/magento en cronjobs draaien. De web-PHP via FPM kan een andere versie zijn, en beide moeten zijn gepatcht.
Verholpen upstreamversies zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35; backports van distributies kunnen oudere nummers dragen. Welke PHP-versies uw Magento-versie ondersteunt, controleert u volgens de systeemeisen in de documentatie van Adobe (experienceleague.adobe.com). Vraag bij Adobe Commerce op Adobe-infrastructuur Adobe of uw beheerder naar de status. Een stapsgewijze handleiding biedt PHP-versie en patchstatus goed controleren.
Waar schadelijke code in Magento zit
| Plek | Inhoud | Controlepunt |
|---|---|---|
app/etc/env.php |
Database, versleutelingssleutel, beheerpad | Wijzigingsdatum, waarden bij vermoeden vernieuwen |
pub/ |
Documentroot, pub/media, pub/static |
PHP-bestanden in media- en staticmappen |
app/code/ |
eigen modules | onbekende modules, gewijzigde bestanden |
vendor/ |
Composer-pakketten, ook extensies | afwijkingen van het lockbestand |
generated/, var/ |
gegenereerde code, cache, logs | logs veiligstellen, code opnieuw genereren |
| Database | configuratie, CMS-blokken, beheerders | vreemde scripts, nieuwe beheerders |
Skimmers zitten in Magento vaak in de database, bijvoorbeeld in de instellingen voor extra scripts in de paginakop of -voet en in CMS-blokken. Een pure bestandsscan ziet ze over het hoofd. Ongevaarlijke leestoegangen helpen bij een eerste blik (tabelvoorvoegsel afhankelijk van de installatie):
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%';
Een gereinigde checkout betekent niet dat er geen gegevens zijn weggelekt. Maak een kopie van de logs vanaf 20-10-2026 en van database-dumps voordat u scripts verwijdert. Alleen zo is later vast te stellen vanaf wanneer en welke bestellingen getroffen waren.
Beheergedeelte en extensies
Het beheerpad is in Magento vrij te kiezen en staat in env.php. Een moeilijk te raden pad is zinvol, maar vervangt geen tweestapsverificatie en geen beperking tot bekende netwerken. Controleer de beheerders en hun rollen regelmatig, evenals integraties en API-tokens.
Extensies van derden zijn bij Magento talrijk: betaalmethoden, ERP-koppelingen, zoek- en marketingmodules. Elke extensie brengt code mee die bij PHP-upgrades moet worden gecontroleerd. Gebruik composer audit regelmatig en verwijder uitgeschakelde modules volledig.
Denk ook aan de achtergrondprocessen. Magento werkt met cronjobs en vaak met wachtrij-consumers die als eigen PHP-processen via de opdrachtregel draaien. Na de PHP-update moeten die net zo goed opnieuw starten als PHP-FPM. Na een wissel van de PHP-hoofdversie moet u bovendien de gegenereerde code in generated/ en de statische bestanden opnieuw laten bouwen en de webshop in een testomgeving doorlopen voordat de live-bedrijfsvoering wordt hervat. Hoe de herstart goed lukt, beschrijft PHP-FPM en alle workers herstarten.
Wat een Magento-update wel en niet kan
Een Magento-release of beveiligingspatch van Adobe dicht fouten in de webshopcode. Ze patcht PHP niet, herstart geen FPM-processen, verwijdert geen scripts uit de database en wist geen vreemde beheerdersaccounts. Is er al code uitgevoerd, dan is een onderzoek nodig. Hoe u achterdeuren herkent, legt Webshells herkennen en verwijderen uit.
Voor handelaren met kaartbetalingen geldt aanvullend: controleer de voorschriften van uw betaaldienstverlener voor beveiligingsincidenten en stem met hem af voordat u sleutels vernieuwt. Of een melding aan de toezichthouder voor gegevensbescherming nodig is, bespreekt u met uw functionaris voor gegevensbescherming of advocaat.
Hoe helpt PHP SOS concreet?
- Wij stellen de web- en CLI-PHP van uw Magento-server vast en laten patch en herstart bevestigen.
- Wij maken traceerbaar een kopie van logs, bestanden en database, indien nodig via onze IT-forensiek.
- Wij controleren
env.php,pub/, modules, configuratietabellen, CMS-blokken en beheerdersaccounts. - Wij reinigen, vernieuwen sleutels en toegangen en documenteren de periode van mogelijke getroffenheid voor gegevensbescherming en betaaldienstverlener.
Veelgestelde vragen
Sluit een Magento-beveiligingspatch ook PHP2Shell?
Nee. Magento-patches verhelpen fouten in de webshopcode. PHP2Shell zit in de PHP-interpreter van de server en wordt alleen gesloten door een PHP-update of een bevestigde backport met herstart van alle processen.
Waar verbergen aanvallers creditcardskimmers in Magento?
Vaak niet in bestanden, maar in de database, bijvoorbeeld in instellingen voor extra scripts in de paginakop of in CMS-blokken. Daarom hoort bij een vermoeden altijd ook een controle van de database.
Wie patcht PHP bij Adobe Commerce in de cloud?
Dat hangt af van uw contract en uw omgeving. Vraag Adobe of uw beheerder schriftelijk naar de PHP-status en de herstart. Eigen extensies en database-inhoud blijven uw verantwoordelijkheid.
Waarom is app/etc/env.php zo belangrijk?
Het bestand bevat de databasetoegang, de versleutelingssleutel en het pad naar het beheergedeelte. Wie het kon lezen, kan versleutelde waarden ontsleutelen en de beheeromgeving vinden. Bij een vermoeden moeten deze waarden worden vernieuwd.