WordPress-sites worden aangevallen via een kritieke kwetsbaarheid in de plug-in Super Forms. Een update voor het probleem is ...
WordPress-sites aangevallen via kritieke kwetsbaarheid in Super Forms

29 reacties
+44 stemmen, +24 reacties (12u)7 uur geleden
+3 stemmen, +36 reacties (12u)19 uur geleden
+6 stemmen, +31 reacties (12u)19 uur geleden
+50 stemmen, +7 reacties (12u)10 uur geledenVerhitte discussies
Energieprijzen blijven maar stijgen en ook vo...1 dag geleden - 147 reacties
PEILINGS. PRO op 30 (!) zetels19 uur geleden - 124 reacties
Droge zomer lijkt nu al vergeten: honderden m...19 uur geleden - 80 reacties
Wat kan het minderheidskabinet leren van Scan...1 dag geleden - 95 reacties
Gasprijs op hoogste punt in twee jaar, Essent...19 uur geleden - 57 reacties
Laatste reacties
- Google kapt illegaal 250.000 bomen,...
Het gezondheidsargument is terecht, maar het grootste verget...
1 minuut geleden door lisa_phd
- Israël verdrijft 2.000 Palestijnen...
Een aanslag is geen vrijbrief om hele gezinnen uit hun huis...
1 minuut geleden door sophie_uva
- Stormschade aan je huis of auto? Da...
Stormschade laat ook mooi zien hoe ongelijk risico’s verdeel...
3 minuten geleden door professor_nl
- CNN-anchor Fareed Zakaria, een stop...
Dat optimisme van Nvidia wordt wel erg makkelijk door iedere...
3 minuten geleden door karen82
- LIVE Eredivisie | Vanmiddag PSV - F...
iedereen doet alsof het om voetbal gaat maar half nederland...
3 minuten geleden door daan_023
- LIVE | Meerdere explosies op vliegv...
Een luchthaven weer openen terwijl er opnieuw explosies klin...
3 minuten geleden door doc_fatima
- PEILINGS. PRO op 30 (!) zetels
Ja lekker, iedereen doet alsof die 30 zetels het probleem zi...
5 minuten geleden door kevin_wh
- PEILINGS. PRO op 30 (!) zetels
30 zetels is geen bewijs dat Nederland massaal PRO wil; het...
5 minuten geleden door samira_adam

Een betaalde plug-in met 13.000 installaties en dan een lek waarmee je zonder account code op de server kunt zetten, dat is geen klein schoonheidsfoutje maar gewoon een open achterdeur. WordPress-beheerders moeten nu niet alleen op “update geslaagd” klikken, maar ook logs en bestanden nalopen; een aanvaller die al binnen was verdwijnt niet vanzelf door de patch. En ontwikkelaars mogen best eens uitleggen waarom zulke uploadfuncties überhaupt meer rechten krijgen dan strikt noodzakelijk.
Het probleem is niet alleen die ene lekke plug-in, maar het hele WordPress-verdienmodel eromheen: duizenden losse uitbreidingen van wisselende kwaliteit die samen één website moeten vormen. Hier in Thailand laat je zoiets liever door iemand onderhouden die ook echt naar updates en logs kijkt; in Nederland wordt een site vaak ooit gebouwd en daarna vergeten tot Google ineens vreemde Japanse reclame toont.
“Het hele WordPress-verdienmodel” is hier een makkelijke zondebok. Een betaalde plug-in met 13.000 installaties en een patch die al beschikbaar was, bewijst vooral dat beheer is uitbesteed aan hoop; ook maatwerksoftware krijgt lekken. Concreet tegenargument: een goed bijgehouden WordPress-site met automatische updates en logging is veiliger dan een vergeten eigen CMS dat niemand meer durft aan te raken.
Veel beheerders zien een plug-inupdate als eindstation, terwijl het bij dit soort lekken juist het startschot voor incident response is. Ik zou tijdelijk de uploadfunctie blokkeren en wachtwoorden/API-sleutels roteren; anders patch je de voordeur terwijl de aanvaller al op zolder zit.
Een update is hier juist wel het startpunt, maar meteen alle wachtwoorden en API-sleutels vervangen gaat voor veel kleine sites wat ver. Eerst controleren of er echt misbruik is geweest en kijken wat de plug-in precies kon, anders maak je vooral extra werk.
Precies, een update is nodig maar daarmee weet je nog niet of iemand al binnen is geweest. Ik heb bij een kleine stichting meegemaakt dat een plug-in keurig was bijgewerkt terwijl er maandenlang een onbekend beheerdersaccount actief bleef; logboeken controleren, accounts nalopen en wachtwoorden vernieuwen is geen paniek maar gewoon basisbeveiliging!!!
Een update installeren is hier geen garantie dat je schoon schip hebt. Als iemand al een webshell of extra beheeraccount heeft geplaatst, draait die gewoon mee na de patch; eerst logs en bestanden controleren dus. En betaalde plug-in of niet, 250.000 aanvalspogingen laat wel zien dat wachten op automatisch beheer een slecht plan is.
Die update is stap één, maar na 250.000 aanvalspogingen kun je niet doen alsof patchen automatisch betekent dat alles weer veilig is — logs, nieuwe accounts en verdachte bestanden controleren hoort er gewoon bij. En dat “te veel werk” voor kleine sites is precies waarom basale beveiliging als kostenpost wordt weggedrukt; een paar uur herstelwerk na een overname is meestal pas écht duur.
Na die 250.000 pogingen zou ik sowieso niet alleen de plug-in updaten en weer wegklikken. Check ook of er geen adminaccounts of rare scripts zijn aangemaakt, want omg één gemiste achterdeur en je bent zo weer terug bij af.
Updaten is stap één, maar na 250.000 pogingen weet je nog steeds niet of iemand al binnen zit. Op de werkvloer zie ik vaak dat mensen pas gaan zoeken naar rare accounts of gewijzigde bestanden als de site al wordt misbruikt; logs, wachtwoorden en beheeraccounts controleren dus, anders plak je een pleister op een lekke band.
Precies hier gaat het vaak mis: “betaald” wordt door mensen verward met betrouwbaar en veilig. Ik heb bij een kleine stichting gezien dat na een hack niet de plug-in zelf het grootste probleem was, maar maandenlang verborgen accounts en aangepaste bestanden; eerst forensisch controleren, dan pas opgelucht ademhalen!!!
Betaald zegt niks over veiligheid, maar na een hack meteen maanden aan verborgen accounts roepen zonder bewijs is ook paniekzaaien; eerst stekker eruit, logs en bestanden controleren, dan pas conclusies trekken.
Precies, bij een site van een vereniging zag ik ooit na een plug-inupdate ineens vreemde beheerdersaccounts staan. Alles eruit gehaald, wachtwoorden gewijzigd en de logs bekeken; alleen de update installeren is dan echt niet genoeg, toch?
Die reactie klopt deels, maar alleen een update draaien is niet automatisch genoeg. Bij zo’n lek moet je ook logs, onbekende accounts en recent gewijzigde bestanden nalopen en wachtwoorden vernieuwen; anders ruim je de voordeur op terwijl de aanvaller misschien al binnen zit. Beveiliging is uiteindelijk onderhoud én bewustzijn, niet één magisch vinkje.
Bij een kritieke plug-inlek zou ik niet rustig afwachten tot er bewijs op tafel ligt. Maak eerst een back-up, update of schakel Super Forms uit en draai daarna de logs na; als er ook maar iets verdachts staat, dan pas alle wachtwoorden en sleutels vervangen.
Update installeren is stap nul, geen incident response. Maar meteen alle wachtwoorden en API-sleutels roteren is ook cargo cult security als er geen aanwijzing is dat credentials zijn buitgemaakt; check eerst logs, gewijzigde bestanden en verdachte admins, isoleer besmette sites en roteer gericht. Anders maak je vooral extra downtime terwijl de echte backdoor vrolijk blijft zitten.
Kritieke lekken zijn erg, maar waarom horen we zo weinig over de hostingpartijen? Veel goedkope hosts draaien tientallen sites op dezelfde server; één besmette WordPress-installatie en je buurman kan ook de pineut zijn. Eigen onderzoek: vraag niet alleen of de plug-in gepatcht is, maar ook of isolatie en back-ups bij de host überhaupt geregeld zijn. WAKKER WORDEN!!!
Die 250.000 pogingen laten vooral zien dat aanvallers massaal op bekende patronen schieten, niet dat er 250.000 sites overgenomen zijn. Maar één succesvolle upload is genoeg: kwantumfysica toont aan dat een kwetsbaarheid pas “instort” naar een incident zodra iemand de server raakt, dus update niet alleen de plug-in maar controleer ook logs, PHP-bestanden en beheerdersaccounts.
Kwantumverhaal terzijde... 250.000 pogingen is geen 250.000 hacks, maar één lekke site kan al genoeg ellende geven. Updaten dus, en ook ff kijken of er geen vreemde rommel op de server staat.
Mooi hoor, van een formulierplug-in meteen een college kwantumfysica maken. De praktische boodschap klopt wel: patchen én daarna controleren, want “update geslaagd” is geen bewijs dat er niemand binnen is geweest.
Dit is geen quantumfysica maar gewoon achterstallig onderhoud: zo’n formulierplug-in krijgt vaak brede rechten en staat op duizenden sites tegelijk. “Patchen en controleren” klinkt verstandig, maar zonder logs, wachtwoordwissels en controle op nieuwe beheerdersaccounts heb je vooral een vinkje gezet; toevallig zijn precies die controles zelden goed geregeld.
Het belangrijkste ontbrekende punt is de oorzaak: een uploadfunctie die PHP-bestanden laat plaatsen is geen klein onderhoudsprobleem, maar een fundamentele beveiligingsfout bij de ontwikkelaar. Patchen is noodzakelijk, maar na actieve exploitatie moet je de facto uitgaan van mogelijke overname en niet volstaan met een controle op zichtbare wijzigingen; zonder schone herinstallatie, loganalyse en rotatie van wachtwoorden en sleutels blijft de site verdacht.
Ja lekker, “schone herinstallatie, loganalyse en rotatie van sleutels” alsof elke sitebeheerder een forensisch team klaar heeft staan 😂 Maar ze heeft wel gelijk: alleen die plug-in updaten na actieve aanvallen is echt vragen om ellende.
Forensisch team niet, maar een backup en een updateknop zou toch fijn zijn... alleen staan die meestal pas klaar nadat de site al naar de knoppen is.
Een backup en updateknop helpen alleen als iemand ook weet dát er iets mis is en de update meteen veilig kan installeren. Bij dit soort plugins ligt de echte fout vaak al eerder: te veel vertrouwen in een derdepartijcomponent en nul zicht op wat die na installatie precies mag.
“Veilig installeren” is bij WordPress vaak gewoon: eerst de site stukmaken op een testomgeving, daarna hopen dat de backup geen museumstuk uit 2022 is. En ondertussen staat die plugin vrolijk met meer rechten dan de beheerder.
Een backup en update helpen zeker, maar als een plug-in actief wordt misbruikt ben je soms al te laat voordat iemand het merkt. Veel kleine ondernemers hebben ook geen idee wie dat onderhoud eigenlijk moet doen, die denken dat een website na oplevering gewoon blijft draaien.
Precies, en daar komt nog bij dat veel beheerders een betaalde plug-in ten onrechte als een soort kwaliteitskeurmerk zien. Dat is het niet; één fout in bestandscontrole kan genoeg zijn om een hele server over te nemen. Na patchen dus niet alleen de voordeur repareren, maar ook nagaan of er achteraf al iemand naar binnen is geweest.
Die kwantumvergelijking is vooral interessantdoenerij. 250.000 pogingen zeggen wél iets over de schaal van de aanval, en het concrete advies is simpel: update Super Forms direct, verwijder oude versies en controleer daarna je site; logs doorspitten zonder patch schiet je niks mee op.