PolyShell (CVE-2026-48356) staat op de CISA KEV-lijst: patchen, zoeken, opruimen

De Amerikaanse cyberdienst CISA heeft PolyShell op 27 oktober 2026 toegevoegd aan de lijst van actief misbruikte kwetsbaarheden. Voor Magento-shops is dat geen nieuws over de patch. Die bestaat al sinds juli. Het is wel een signaal dat er nog genoeg winkels openstaan om misbruik de moeite waard te maken.

Het venijn zit in de volgorde. Wie in maart of april kwetsbaar was, kan al een webshell op de server hebben staan. Een patch zet de deur dicht. Wat er al binnen is, blijft gewoon liggen.

Wat is er aan de hand?

PolyShell is de naam die het Nederlandse securitybedrijf Sansec gaf aan een lek in de REST API van Magento Open Source en Adobe Commerce. Het officiële nummer is CVE-2026-48356. Adobe classificeert het als unrestricted file upload (CWE-434) en geeft het een CVSS-score van 9.6. In het CVE-record en bij NVD staat 9.3. Het verschil zit alleen in de score voor beschikbaarheid.

Zo werkt het, volgens het onderzoek van Sansec:

• De guest-cart endpoints POST /V1/guest-carts/:cartId/items en PUT /V1/guest-carts/:cartId/items/:itemId vereisen geen login.
• Je kunt daar een bestand meesturen als custom option van een winkelwagenregel.
• Magento controleert niet goed of die optie bestaat, of het type een bestand mag zijn, en welke extensie het bestand heeft.
• De enige check is of het bestand op een afbeelding lijkt. Een polyglot, een geldige GIF of PNG met PHP-code erin, komt daar zonder moeite langs.
• Het bestand belandt in pub/media/custom_options/quote/, een map die via het web bereikbaar is.

Of die code daarna ook draait, hangt af van je webserverconfiguratie. Bij een nginx-config die elk .php-bestand naar PHP-FPM doorstuurt, of Apache zonder php_flag engine 0 in die map, heb je remote code execution. Anders blijft het bij een bestand op schijf, of bij stored XSS. Volgens Sansec geldt dat laatste voor versies vóór 2.3.5 of bij afwijkende configuraties. GraphQL gebruikt een ander codepad en is volgens Sansec niet kwetsbaar.

De tijdlijn

• 17 maart 2026: Sansec waarschuwt publiek. Er is dan nog geen patch voor productieversies.
• 19 maart: eerste aanvallen in het wild.
• 30 maart: massale aanvalsgolf. In het rapport over de bijbehorende loader-campagne meldt Sansec dat in één uur 471 winkels een script-loader kregen, nadat er via PolyShell webshells waren geplaatst.
• 14 juli: Adobe publiceert APSB26-73 met de fix voor alle ondersteunde releaselijnen.
• 27 oktober: CISA zet CVE-2026-48356 op de KEV-lijst. Amerikaanse federale instanties moeten vóór 10 november patchen.

Over de schaal van het misbruik: Sansec schrijft dat op 24 maart op "56,7% van alle winkels" kwaadaardige PHP was geüpload, en later dat het aanvallen zag op 79,5% van de winkels. Op dezelfde pagina staat bij dat laatste getal "beschermde winkels". Het gaat dus om winkels die Sansec monitort, niet om alle Magento-shops wereldwijd. Een absoluut aantal gehackte winkels publiceert niemand.

Let op een tegenstelling. Adobe schrijft in het bulletin nog steeds dat het "niet op de hoogte is van misbruik in het wild". Het bulletin dateert van vóór de KEV-opname. CISA en Sansec zeggen allebei dat het lek actief misbruikt wordt.

Wie loopt risico?

Volgens APSB26-73 zijn deze versies kwetsbaar:

Sansec en Adobe zijn het niet eens over 2.4.9

Sansec schreef in mei dat Magento 2.4.9 de fix al bevatte. Adobe noemt 2.4.9 in APSB26-73 juist als kwetsbaar en levert er een aparte patch voor (2.4.9-2026-jul). Wij volgen Adobe. Draai je 2.4.9 zonder de juli-patch, dan behandel je je shop als kwetsbaar.

De isolated patch past niet op elke versie

Adobe levert de fix als isolated patch per releaselijn. Die patch past alleen op het laatste patchniveau van die lijn. De 2.4.7-patch werkt dus alleen op 2.4.7-p10. Zit je op 2.4.7-p6, dan moet je eerst naar p10. Voor Magento Open Source zijn de patches alleen te downloaden vanaf 2.4.6. Draai je Open Source 2.4.5 of ouder, dan is er geen patch. Dan is upgraden de enige weg.

Op Adobe Commerce Cloud zit de fix in de laatste update van cloud-patches. Adobe waarschuwt dat de isolated patch daar bovenop installeren tot fouten kan leiden.

Wat je nu doet: de checklist

Doe het in deze volgorde. Eerst de deur dicht, dan zoeken, dan opruimen.

1. Patch.

• Stel vast op welke versie en welk patchniveau je zit (composer show magento/product-community-edition of de enterprise-variant).
• Breng de shop naar het laatste patchniveau van je lijn.
• Pas de juli-patch uit KA-37421 toe, of upgrade naar een -2026-jul-release.
• Gebruik je Adobe Commerce Events, ga dan naar 1.21.0.
• Controleer het resultaat met de Commerce Version Tool van Adobe. Die werkt pas nadat de CE-patch is toegepast.

2. Sluit de uploadmap af.

Blokkeer webtoegang tot pub/media/custom_options/. Sansec geeft voor nginx dit blok, te plaatsen vóór elk \.php$-blok:

location ~* ^/pub/media/custom_options/ {
    deny all;
    return 403;
}

Op Apache controleer je of de .htaccess in die map de PHP-engine uitzet en toegang weigert. Let op: dit voorkomt dat geplaatste bestanden uitgevoerd worden. Het voorkomt niet dat ze geüpload worden. Dat doet alleen de patch of een WAF die de API-call zelf blokkeert.

3. Zoek naar geplaatste bestanden. Zie de volgende sectie.

4. Ruim op en roteer.

• Verwijder alles wat er niet hoort en zet een schone versie terug waar nodig.
• Verwijder onbekende accounts in de admin_user-tabel.
• Wijzig daarna de wachtwoorden van de database, admin-accounts en API-integraties.

Twijfel je of je alles hebt gevonden? Dan is het verstandiger de server als gecompromitteerd te behandelen. Op /security/gehackt lees je hoe wij zo'n opschoning aanpakken.

Hoe controleer je of je geraakt bent?

Patchen verwijdert geen bestanden die eerder zijn geüpload. Ook niet als de patch al in juli is geïnstalleerd. Dit zijn de checks die Sansec noemt, aangevuld met wat voor de hand ligt.

Uploads in de custom_options-map

find pub/media/custom_options/ -type f ! -name '.htaccess'

Elk .php-, .phtml- of .phar-bestand in die map is volgens Sansec een sterke aanwijzing voor een compromittering. Ook "afbeeldingen" verdienen een blik: een polyglot heeft een geldige afbeeldingsheader. Zoek binnen die map op PHP-tags:

grep -rlE "<\?(php|=)" pub/media/custom_options/

Bekende bestandsnamen uit de aanvallen zijn onder meer index.php, bypass.phtml, c.php, r.php, rce.php, test.php, json-shell.php en static.php. Sansec zag ook namen met een cijfer ervoor, zoals 780index.php.

De accesson.php-backdoor

find /var/www -name 'accesson.php' -type f

Pas het pad aan naar je eigen webroot. Op één gehackte winkel vond Sansec dit bestand in nieuwe assets/images/-submappen in vrijwel elke hoofdmap: app/, var/, vendor/, pub/ en generated/. De backdoor print altijd 8194460. Daarmee testen aanvallers of hun shell nog leeft.

Scripts in CMS-content

Na de uploads volgde in veel gevallen een script-loader in CMS-blokken. Sansec noemt onder meer de domeinen lanhd6549tdhse.top, additionalver.com en deepveindrilling.com. Zoek in cms_block en cms_page op die domeinen en op onbekende <script>-tags. Hoe je dat met veilige SQL doet, staat in ons artikel over de deepveindrilling-loader in CMS-blokken.

Logs

Zoek in je access logs naar POST en PUT op /rest/ en guest-carts/.../items met ongewoon grote bodies. Sansec publiceerde tientallen IP-adressen die naar het lek scanden. Vind je een treffer, kijk dan wat er rond dat tijdstip in pub/media/ is aangemaakt.

Vind je iets? Ga dan niet alleen dat ene bestand verwijderen. Een webshell is een ingang, en wie binnen was, heeft vaak meer achtergelaten: een admin-account, een cronjob of een extra backdoor.

Waar dit past naast andere Magento-lekken

PolyShell is niet het enige Magento-lek dit jaar. BlockStrap en StyleSmuggler hebben elk hun eigen patch en eigen sporen. Het patroon is wel steeds hetzelfde. Een shop die achterloopt met patches, loopt achter op meerdere fronten tegelijk. Wil je dat structureel geregeld hebben, kijk dan naar Magento support of ons overzicht van Magento-security.