Onderzoekers hebben een intrigerende WordPress-compromittatie beschreven waarbij een backdoor na opschonen opnieuw wordt opgebouwd. Het bijzondere daaraan: je verwijdert de ene component, maar op een volgende page load komt de functionaliteit terug via andere installatieroutes. Voor beheerders voelt dat alsof het malware “terugveert” in plaats van verdwijnt—en dat vraagt om een andere aanpak dan alleen bestanden wissen.
In dit artikel zetten we uiteen hoe de WordPress backdoor herstelt zichzelf, welke signalen je kunt herkennen, en hoe je de schade verkleint. We sluiten af met een actueel tweede aandachtspunt: een high-severity wpForo-kwetsbaarheid die al actief wordt misbruikt.
Waarom deze WordPress-backdoor niet verdwijnt
De onderzoekers koppelen de activiteit aan een malwarefamilie die door Sucuri is aangeduid als een “self-healing mesh” dat via blockchain-achtige elementen wordt aangestuurd. De kernboodschap: de payload leeft niet op één plek. In plaats daarvan is dezelfde backdoorfunctionality verspreid over meerdere bronnen—waardoor verwijderen van één onderdeel onvoldoende is.
Beheerders die pluginbestanden verwijderen, vallen vaak in een val: er is een herbouwlus die opnieuw plugin- en theme-onderdelen terugplaatst. Daarbij wordt gebruikgemaakt van zowel file-based locaties als content in de database en zelfs gedeeld geheugen.
Zo herstelt de backdoor zichzelf via meerdere lagen
Volgens de technische beschrijving gebruikt de backdoor ten minste acht componenten die elkaar kunnen aanvullen. Dat betekent dat één overgebleven kopie genoeg kan zijn om het systeem opnieuw op te tuigen.
Een paar belangrijke bouwstenen:
- .user.ini stelt auto_prepend_file in om voor elke PHP-aanroep een loader te laten draaien binnen de betreffende directorystructuur.
- Verborgen loaderbestanden (met dot-prefix) functioneren als eerste-stadium om een nep-plugin te lokaliseren en opnieuw te activeren.
- Een loadercomponent in de cache/database draagt een gecodeerde of gecomprimeerde payload mee die opnieuw inzetbaar is wanneer onderdelen ontbreken.
- db.php wordt tijdens WordPress-bootstrap geladen en bevat de volledige backdoorpayload in een vorm die eerst wordt gedecodeerd en daarna opnieuw wordt ingezet als plugin.
- advanced-cache.php draait vroeg in de caching-flow en herbouwt vervolgens de plugin vanuit meerdere onafhankelijke bronnen, waaronder gedeeld geheugen, een ZIP-bundel en database-inhoud.
- Theme-resident variant: een functiesbestand in een theme bevat een tweeling van db.php die bij afwezigheid weer herbouwt.
- Must-use plugin en een duplicaat in de normale pluginmap zorgen voor redundantie.
Het resultaat is een circulair systeem zonder één “makkelijke” stopknop. Wat je ook verwijdert, de backdoor kan vanuit een andere overgebleven laag opnieuw worden opgebouwd.
Gecodeerde code en verborgen commando’s
De beschreven malware gebruikt geen leesbare function-namen. In plaats daarvan zit er een decoder die de code herschikt met behulp van een substitutie-cipher. Daardoor is statische analyse lastiger en lijken onderdelen op “ruis” totdat ze worden gedecodeerd tijdens uitvoering.
Daarnaast koppelt de backdoor de command-and-control (C2) aan communicatie via Ethereum-gerelateerde infrastructuur. De malware fingerprint de geïnfecteerde site, haalt aanvullende payloads op en draait vervolgens een reinfectielus.
Ook noemt Sucuri dat het mogelijk is om zichzelf te verbergen in administratieve plugin-schermen of in update-checks. Verder kan de operator acties uitvoeren zoals het creëren van een verborgen beheerdersaccount en het uitschakelen of verwijderen van specifieke plugins.
Realtime herinfectie: de cron- en page-load aanpak
Een belangrijk operationeel detail is dat herplaatsing niet per se afhankelijk is van bezoekers die “aan” staan. De malware registreert cron hooks. Daarbij zou de server-side cron (system cron) het WordPress cron-bestand uitvoeren en op schema herdeployments triggeren.
Daarnaast kan een volgende page load al genoeg zijn om de herbouw te starten. Dat verklaart waarom opschonen in de praktijk soms lijkt te werken—tot het moment waarop een volgende request een herstelmechanisme in werking zet.
Waar je extra op moet letten bij opschonen
Als je vermoedt dat WordPress backdoor herstelt zichzelf, beperk je reactie dan niet tot “alles verwijderen wat je vindt”. Deze casus laat zien dat een complete aanpak minimaal ook andere opslaglagen moet meenemen.
Concreet betekent dit in elk geval:
- Bestanden: niet alleen de zichtbare pluginmappen, maar ook theme-bestanden, cache-gerelateerde bestanden en hidden/dot-prefixed varianten.
- Database: controle op injecties in instellingen, inhoud of opgeslagen payloadcomponenten die tijdens bootstrap opnieuw worden ingezet.
- Shared memory (waar van toepassing): op servers die System V shared memory ondersteunen, kan de payload in RAM verblijven. In dat scenario kan “bestand opschonen” onvoldoende zijn, omdat het systeem vanuit geheugen terug kan schrijven.
- Geplande taken: controleer cron-instellingen en hooks die door malware kunnen zijn toegevoegd.
Omdat de backdoor zichzelf kan laten heropbouwen vanuit meerdere bronnen, is een herinfectie-check onderdeel van het herstelproces. Pas na herinspectie op volgende requests of geplande momenten kun je met meer zekerheid zeggen dat de incidentrespons werkt.
Risico’s voor bezoekers: skimmers en code-injectie
De operator kan via de backdoor controle uitoefenen over de WordPress-site. In de beschrijving wordt vermeld dat de malware arbitraire JavaScript kan ophalen om bezoekers te targeten met skimmers (of andere kwaadaardige injecties). Ook kan de backdoor PHP-code uitvoeren.
Voor organisaties betekent dit dat je niet alleen naar integriteit van bestanden moet kijken, maar ook naar mogelijke impact op eindgebruikers—denk aan ongebruikelijke transactiestromen, verdachte formulieren of afwijkende scripts.
Actueel: wpForo SQL-injectie wordt al misbruikt
Naast deze self-healing WordPress backdoor waarschuwen onderzoekers ook voor een andere kwetsbaarheid: een high-severity, unauthenticated SQL injection in de wpForo Forum WordPress plugin.
Het gaat om CVE-2026-1581 met een CVSS-score van 7.5. Volgens de melding beïnvloedt de bug alle versies tot en met 2.4.14 en wordt er actief misbruik gemaakt.
Telemetry van Previdian laat zien dat er sinds 3 juli 2026 minder dan 20 pogingen met gericht exploitieren zijn waargenomen. De activiteit kwam vanuit vijf unieke IP-adressen in onder meer Bulgarije, Zwitserland, Frankrijk, de VS en Jemen.
Praktisch advies: zorg dat wpForo (en alle gerelateerde plugins) up-to-date zijn en monitor op verdachte database-activiteiten en onverwachte logins, zeker wanneer je niet-geauthenticeerde endpoints hebt.
Maak je WordPress-aanpak robuuster
Deze incidenten onderstrepen dat moderne compromittaties niet per se “één bestand” zijn. Soms is het een set van componenten die op elkaar steunen—met herbouwmechanismen als onderdeel van het verdedigings- of overlevingsmodel van de aanvaller.
Wil je je aanpak aanscherpen? Zie deze situaties vooral als ondersteuning bij je security fundamentals en herstelstrategie. Als je wilt, kun je ook lezen hoe AI het tempo van kwetsbaarheidsscanning verandert, terwijl de basis belangrijk blijft: AI verandert het tempo van kwetsbaarheidsscanning.
Verder kan het helpen om je software supply chain onder de loep te nemen, omdat aanvallers soms via kwetsbare of gemanipuleerde componenten binnenkomen. Dit onderwerp sluit aan bij: Software supply chain moderniseren: minder CVE-risico.
Conclusie: herstel is meer dan opschonen
De beschreven WordPress-compromittatie maakt één punt glashelder: WordPress backdoor herstelt zichzelf kan zelfs optreden wanneer je zichtbare malware verwijdert. Door redundantie over bestanden, database en gedeeld geheugen blijft functionaliteit beschikbaar en kan de backdoor zichzelf opnieuw opbouwen via page loads en cron-achtige triggers.
Combineer daarom grondig opschonen met controle op database-inhoud, plannen die terugkeer veroorzaken en—waar relevant—geheugenpersistente componenten. Houd daarnaast je plugins, zoals wpForo, strak bijgewerkt, omdat ook andere kwetsbaarheden al actief misbruikt worden. Zo verklein je de kans dat een “geslaagde schoonmaak” in werkelijkheid slechts een tussenfase was.
Bron: https://thehackernews.com/2026/10/wordpress-backdoor-rebuilds-itself.html
