Ruim 100.000 geblokkeerde pogingen op één plugin
The Hacker News berichtte woensdag 16 september over actief misbruik van CVE-2026-27540 in WooCommerce Wholesale Lead Capture, een betaalde plugin van Rymera Web Co met zo'n 6.000 actieve installaties. Aanvallers uploaden er PHP-webshells mee, zonder in te loggen. Wordfence zegt inmiddels meer dan 100.000 pogingen te hebben geblokkeerd, met pieken tussen juni en augustus.
De patch ligt er sinds 20 februari.
Het lek zit in de upload van het registratieformulier
De plugin registreert een AJAX-actie, wwlc_file_upload_handler, die hoort bij het aanmeldformulier voor zakelijke klanten. Die actie is via admin-ajax.php bereikbaar voor bezoekers zonder account. Op zich niet vreemd. Een aanvraagformulier waarin een prospect een KvK-uittreksel of btw-nummerbewijs kan hangen, dat wil je nu eenmaal open hebben staan.
De fout zit een laag dieper. De handler toetst de bestandsextensie wel tegen een lijst met toegestane types, maar die lijst komt uit het request zelf in plaats van uit serverside configuratie. De aanvaller levert dus zowel het bestand als de regel waaraan het getoetst wordt. Wat er binnenkomt is doorgaans een shell.php die hostgegevens uitprint en een eigen uploadformulier serveert, zodat de rest van de payload er achteraan kan. CVSS 9.8. Alles tot en met 2.0.3.1 is kwetsbaar, 2.0.3.2 is de fix.
Zeven maanden is de echte kwetsbaarheid
Die zeven maanden tussen patch en misbruik zijn interessanter dan de bug zelf.
Wat er bij betaalde extensies bijna altijd onder ligt: de licentie. WordPress haalt updates van premium plugins alleen op als de licentiesleutel geldig en geactiveerd is. Verloopt die sleutel, of is de webshop ooit gekloond naar een acceptatieomgeving waar de activatie is losgeraakt, dan verdwijnt de updatemelding simpelweg uit beeld. Je dashboard meldt niets. Je uptimemonitoring meldt niets.
Bij webshops die wij overnemen kijk ik daarom eerst naar de licentiestatus van de betaalde plugins en pas daarna naar het versieoverzicht. Dat overzicht liegt niet, maar het weet alleen wat de updateserver heeft mogen vertellen. Magento- en Shopware-extensies uit een private Composer-repo hebben precies hetzelfde probleem, alleen zonder dashboard om het in te missen. In een onderhoudsafspraak hoort die licentiestatus net zo goed maandelijks langs te komen als het versienummer.
Wat ik vandaag zou controleren
Als je sinds februari 2.0.3.1 of lager hebt gedraaid, is updaten naar 2.0.3.2 stap één van vier. Daarna:
- de access logs op POST-requests naar
admin-ajax.phpmetaction=wwlc_file_upload_handler, terug tot februari wp-content/uploadsop.php-bestanden die daar niet horen, gesorteerd op wijzigingsdatum- de gebruikerstabel op administrators die je niet zelf hebt aangemaakt
In de rapportage komen bron-IP's voorbij als 92.241.13.213 en 31.59.129.150. Die blokkeren is cosmetisch. Tien adressen tegen een campagne die al maanden loopt houdt niemand tegen, en het geeft je het gevoel dat je klaar bent terwijl je de logs nog niet hebt gelezen.
Wat ik niet zou doen
Een backup van vorige week terugzetten zonder te weten wanneer de shell erop kwam. Bij een lek dat sinds februari wordt uitgebuit is je hele backupreeks waarschijnlijk al besmet en zet je de achterdeur netjes terug. Eerst vaststellen wanneer het eerste verdachte request binnenkwam, dan pas een herstelpunt kiezen.
En ik zou de plugin niet deïnstalleren in de veronderstelling dat het daarmee opgelost is. Het lek verdwijnt, de shell blijft. Die staat als los bestand in de uploadmap en heeft de plugin allang niet meer nodig.