WordPress beveiligen tegen wp2shell (CVE-2026-63030)
In WordPress-versies ouder dan 7.0.3 zit een lek waarmee iemand zonder in te loggen je site kan overnemen. Bijwerken naar 7.0.3 of hoger sluit dat lek. In dit artikel lees je hoe je controleert of je site kwetsbaar is, hoe je veilig bijwerkt en hoe je voorkomt dat je hier opnieuw achteraan moet.
Wat wp2shell is
Normaal moet WordPress bij elke handeling controleren of je daar wel rechten voor hebt. In de kwetsbare versies gaat die controle mis op één specifiek punt: de batch-endpoint van de REST API. Een aanvaller kan daar een reeks opdrachten naartoe sturen die worden uitgevoerd alsof hij beheerder is, terwijl hij nooit heeft ingelogd.
Wat er daarna gebeurt is standaardwerk: er wordt een extra beheerdersaccount aangemaakt, een webshell (een PHP-bestand waarmee de aanvaller commando's op je server kan uitvoeren) tussen je uploads gezet, en er wordt op een paar plekken tegelijk zorgvuldig een terugweg ingebouwd. Vanaf dat moment is de site niet alleen kwetsbaar, maar overgenomen: spam vanaf je account, bezoekers die worden doorgestuurd, SEO-spam in je pagina's en toegang tot klant- en ordergegevens.
Het lek wordt geautomatiseerd afgescand. Een site die kwetsbaar online staat, wordt doorgaans binnen enkele dagen gevonden. Dat is de reden dat we hier actief op scannen en klanten aanschrijven.
Belangrijk: controleer eerst of de site al besmet is
Updaten sluit het lek, maar verwijdert geen backdoor die er al in zit. Werk je een besmette site bij, dan patch je de voordeur terwijl de achterdeur openstaat, en heb je bovendien het gevoel dat het is opgelost.
Loop daarom eerst deze drie punten na voordat je gaat bijwerken:
- Ga in WordPress naar Gebruikers en filter op Beheerder. Zie je een account dat je niet zelf hebt aangemaakt, vooral met een naam die begint met wpsvc_, wp2_ of w2s_, ga dan niet updaten.
- Kijk in je bestanden of er PHP-bestanden staan in wp-content/uploads. Daar hoort normaal geen PHP te staan, alleen afbeeldingen, pdf's en dergelijke.
- Kijk of de map wp-content/mu-plugins bestaat en of er iets in staat dat je niet herkent. Deze map is er in een standaardinstallatie niet.
Vind je één van deze drie, ga dan naar het artikel over het opschonen van een besmette site. Vind je niets, ga dan door met bijwerken.
Wil je dit sneller controleren en heb je toegang tot SSH of de cPanel Terminal, dan doe je dat zo vanuit de map van je WordPress-installatie:
wp user list --role=administrator find wp-content/uploads -name "*.php" ls -la wp-content/mu-plugins
Je WordPress-versie controleren
In WordPress zelf staat je versienummer onderaan het dashboard, rechtsonder, en op Dashboard > Updates.
Via SSH of de cPanel Terminal, vanuit de public_html of WordPress installatie map:
wp core version
Staat er een versie lager dan 7.0.3, dan is de site kwetsbaar.
Bijwerken vanuit WordPress
Dit is de weg die voor de meeste sites prima werkt.
- Maak eerst een back-up, of controleer of er een recente back-up klaarstaat. Ga daarna pas verder.
- Ga naar Dashboard > Updates.
- Werk WordPress zelf bij en wacht tot de pagina meldt dat het gelukt is.
- Werk daarna al je plugins bij, en daarna je thema's. Doe dit in deze volgorde: plugins verwachten de nieuwe core, niet andersom.
- Ga terug naar Dashboard > Updates en controleer of er nu 7.0.3 of hoger staat.
Loopt de update vast op een time-out, dan is de kans groot dat het via de Terminal wel lukt, omdat die niet aan de uitvoeringstijd van een webrequest gebonden is.
Bijwerken via SSH of de cPanel Terminal
Werk je meerdere sites bij, dan gaat dit een stuk sneller. Ga eerst naar de map van de installatie, dus de map waarin wp-config.php staat.
wp core update wp core version wp plugin update --all wp theme update --all
Controleer daarna of de core niet is aangepast:
wp core verify-checksums
Dit vergelijkt elk WordPress-bestand met de officiële versie van wordpress.org. Krijg je hier meldingen over bestanden die afwijken of die er niet horen te staan, dan is dat een sterk signaal dat er iets in de installatie is gewijzigd. Ga in dat geval verder met het artikel over het opschonen van een besmette site.
Heb je meerdere installaties in één cPanel-account staan, vergeet dan de addon-domeinen en subdomeinen niet. Deze regel laat zien waar overal een WordPress-installatie staat:
find ~ -name "wp-config.php" -not -path "/wp-content/"
Controleren of het gelukt is
Na het bijwerken loop je dit nog even na.
- Draait de site normaal? Open de homepage, een subpagina en het dashboard.
- Staat er 7.0.3 of hoger?
- Zijn er geen beheerdersaccounts bijgekomen die je niet kent?
- Staan er geen PHP-bestanden in wp-content/uploads?
Voorkomen dat je hier opnieuw achteraan moet
Bijwerken lost dit lek op. De volgende is een kwestie van tijd, dus het loont om een paar dingen structureel te regelen.
Zet automatische updates aan voor de core en voor plugins waarvan je weet dat ze stabiel updaten. Je regelt dat per plugin op de pagina Plugins, in de kolom Automatische updates. Voor sites met maatwerk is een vaste maandelijkse onderhoudsronde een beter idee dan alles blind laten bijwerken.
Zet de bestandseditor in het dashboard uit. Dat scheelt een aanvaller die op de één of andere manier binnenkomt een makkelijke manier om code toe te voegen. Voeg dit toe aan wp-config.php, boven de regel die begint met /* That's all:
define( 'DISALLOW_FILE_EDIT', true );
Ruim beheerdersaccounts op die niemand meer gebruikt, bijvoorbeeld van een bureau of freelancer die niet meer bij het project betrokken is. Elk account dat blijft staan is een ingang die niemand in de gaten houdt.
Gebruik je XML-RPC niet, bijvoorbeeld voor de WordPress-app of Jetpack, zet dat dan uit. Het is een veelgebruikt doelwit voor geautomatiseerde inlogpogingen.
Wat wij aan onze kant al hebben gedaan
Onze firewall blokkeert op platformniveau de aanvalspaden richting de batch-endpoint die we nu kennen, inclusief de encoded variant die scanners gebruiken om dat soort blokkades te omzeilen. Imunify360 monitort daarnaast op de bestanden en gedragingen die bij deze aanval horen.
Dat koopt tijd, maar het is nadrukkelijk een tijdelijke maatregel. Het dekt geen nieuwe varianten en het vervangt de update niet. De versie bijwerken is het enige dat het lek echt sluit.
Kom je er niet uit?
Twijfel je of een site kwetsbaar of al besmet is, of loopt de update ergens op vast? Stuur ons een bericht met de betreffende domeinen, dan kijken we met je mee.