Juni 2026 was geen fijne maand als je een Joomla-site draait. In een paar weken tijd kwamen er vijf kritieke lekken naar buiten in extensies die op enorm veel sites staan: de JCE-editor, twee page builders (SP Page Builder en PageBuilderCK) en het evenementencomponent iCagenda en het templateframework Helix3. Alle vijf ongeveer hetzelfde type lek, en alle vijf al actief misbruikt voordat de meeste sitebeheerders doorhadden dat er iets speelde.

Het goede nieuws is dat er voor alle vijf inmiddels een update is. Het minder goede nieuws: een update installeren sluit de deur, maar als er al iemand binnen is gekomen, staat die er na het updaten gewoon nog. Dat onderscheid wordt vaak gemist, en het is precies daar waar sites alsnog de mist in gaan.

Wat er precies misging

Alle vijf de lekken komen op hetzelfde neer. Ergens in de extensie zat een onderdeel dat een geüpload bestand accepteerde zonder te controleren wie de uploader is, dus zonder dat er een login nodig was, en zonder goed te controleren wat voor bestand het is. Daardoor kon een aanvaller een PHP-bestand op de server zetten en dat vervolgens uitvoeren. In de praktijk betekent dat volledige controle over je site: data eruit halen, pagina's aanpassen, een achterdeur plaatsen, of jouw server gebruiken om andere sites aan te vallen. In jargon heet dat remote code execution, en dat is zo ongeveer het ergste wat er met een website kan gebeuren.

Hieronder loop ik de vijf stuk voor stuk langs: wat de extensie is, wat er misging en wat je moet doen.

JCE: ongeauthenticeerde profiel-upload, veilig vanaf versie 2.9.99.6

JCE, voluit Joomla Content Editor, is de meest geïnstalleerde editor voor Joomla. Op heel veel sites vervangt hij de standaardeditor, vaak zonder dat de beheerder er nog bij stilstaat dat het een aparte extensie is. Juist die alomtegenwoordigheid maakt een lek erin zo aantrekkelijk voor aanvallers.

Het lek liet bezoekers zonder login editor-profielen uploaden, en via die omweg kon er een willekeurig bestand op de server worden gezet, inclusief uitvoerbare PHP. De makers reageerden in twee stappen: eerst een spoedupdate (2.9.99.5) die het gat dichtte, en kort daarna 2.9.99.6, het resultaat van een paar dagen waarin de hele extensie is doorgelicht en de invoercontroles zijn aangescherpt. Belangrijk detail: 2.9.99.6 is de versie waar je op moet zitten, niet 2.9.99.5. Stop dus niet halverwege.

Dit is bovendien niet de eerste keer dat JCE een upload-lek heeft. Jaren geleden was er ook al een dat op grote schaal is misbruikt, en precies daarom moet je een nieuw JCE-lek meteen serieus nemen: aanvalsbots weten dat de editor zo'n beetje overal draait. Update naar 2.9.99.6 via de Joomla-updater of rechtstreeks bij de maker, de Pro-versie werkt gewoon op Joomla 3, 4, 5 en 6. Kun je niet updaten, verwijder JCE dan tijdelijk. Controleer daarna of er editor-profielen zijn bijgekomen die jij niet hebt aangemaakt.

SP Page Builder: upload-lek dat verborgen beheerders plant, gedicht in 6.6.2

SP Page Builder van JoomShaper is een van de populairste page builders voor Joomla, waarmee je pagina's in elkaar sleept zonder te coderen. Het lek zat in een upload-functie van de component zelf, de taak die normaal een eigen icoon laat uploaden (asset.uploadCustomIcon). Die accepteerde een bestand zonder enige login, waardoor een aanvaller een PHP-webshell kon plaatsen en uitvoeren.

Wat dit lek extra vervelend maakt, is wat aanvallers er in de praktijk mee deden. Ze gebruikten de controle die ze kregen om een verborgen Super User aan te maken, zodat ze een eigen ingang houden, ook nadat jij netjes hebt geüpdatet. Nog een aandachtspunt: een firewallregel die de JCE-aanval tegenhoudt, blokkeert deze niet automatisch. Het is een andere extensie met een ander patroon, dus leunen op je WAF alleen is hier niet genoeg.

Elke versie tot en met 6.6.1 is kwetsbaar, gedicht in 6.6.2. Update dus naar 6.6.2 en loop daarna je gebruikerslijst na op beheerders die je niet zelf hebt aangemaakt.

PageBuilderCK: bestandsupload naar elke map, gedicht in 3.6.0

En het bleef niet bij één page builder. PageBuilderCK van JoomlaCK is een van de populairste gratis page builders voor Joomla, een sleep-en-neerzet-tool die duizenden sites gebruiken voor hun landingspagina's en content. Op 27 juni bracht maker Cédric Keiflin versie 3.6.0 uit met een changelog die in zijn geheel luidde: "IMPORTANT : Fix security issue". Geen uitleg, geen toeters en bellen. Achter die ene regel zit een serieus lek.

In elke versie tot en met 3.5.10 zat een front-end endpoint dat een geüpload bestand accepteerde zonder login en zonder rechtencontrole. Dit lek is bovendien een graadje erger dan de rest: de aanvaller mag zelf kiezen in welke map het bestand belandt. Een PHP-webshell kan dus overal terechtkomen waar de server mag schrijven, in /images, /media, /templates, /administrator, waar dan ook. Het enige wat in de weg stond was een CSRF-token, en dat kan elke bezoeker gewoon van de pagina aflezen. Echte bescherming was het dus niet.

Belangrijk: de extensie of de betreffende pagina depubliceren helpt niet. Het kwetsbare endpoint blijft gewoon bereikbaar. Alleen updaten (of het endpoint op firewallniveau blokkeren) sluit het echt. Let bij het updaten op de juiste versie voor jouw Joomla: 3.6.0 voor de huidige Joomla, 3.4.10 als back-port voor Joomla 4 en 3.1.1 voor Joomla 3. Controleer daarna op achtergelaten PHP-bestanden, en kijk juist niet alleen op de voor de hand liggende plekken, want bij dit lek kan het bestand letterlijk overal staan.

iCagenda: bestandsupload in het evenementencomponent, opgelost in 4.0.8

iCagenda van JoomliC is een agenda- en evenementencomponent, gebruikt op sites die activiteiten of een evenementenkalender publiceren. Het lek was een ongeauthenticeerde bestandsupload in de map waar het component zijn uploads bewaart, met opnieuw remote code execution als gevolg.

Dit was een echte zero-day: het werd al misbruikt voordat er een fix bestond. De maker had nog dezelfde dag 4.0.8 klaar. Wil je in je logs nagaan of jouw site is geprobeerd, let dan op een patroon waarbij een bot eerst iets naar de site post en vervolgens meteen een .php-bestand opvraagt in de uploadmap van het component. Dat is de vorm van een aanval die er al van uitgaat dat hij binnen is.

Update naar 4.0.8 en controleer de uploadmap van het component op PHP-bestanden die daar niet thuishoren.

Helix3: ongeauthenticeerd bestanden schrijven en verwijderen, gedicht in 3.1.1

Helix3 is het templateframework van JoomShaper, de basis waarop een groot deel van de Joomla-templates is gebouwd. Het is dus geen losse functie op één pagina, maar het fundament onder je hele site-ontwerp. En het is dezelfde maker als SP Page Builder, dus dit is de tweede JoomShaper-extensie in deze reeks.

Het lek zat in de ajax-plugin van Helix3. Die was bereikbaar via de com_ajax-dispatcher van Joomla en voerde een aantal acties uit nog voordat er een token- of rechtencontrole plaatsvond. Daardoor kon een aanvaller zonder login in één request bestanden in je template wegschrijven, willekeurige bestanden op je server verwijderen en je template-instellingen overschrijven. Een weggeschreven bestand betekent opnieuw mogelijke code-uitvoering, en het verwijderen van bestanden kan je site zo onderuithalen. Dit raakt trouwens niet alleen oude installaties: het geldt voor de huidige Joomla 4, 5 en 6. Het lek kwam aan het licht tijdens onderzoek naar een gehackte site en is via responsible disclosure gemeld.

De fix is Helix3 3.1.1. Draait een van je sites op Helix3, update dan naar 3.1.1 via de Joomla-updater. Controleer daarna of er bestanden zijn bijgekomen of juist verdwenen in je template- en mediamappen, en of je template-instellingen nog kloppen.

"Security update" is geen changelog

Helix3 legt meteen een tweede probleem bloot. JoomShaper deed op zich netjes wat hoort: ze mailden gebruikers en zetten een changelog-regel neer. Eerlijk is eerlijk, heel veel lekken worden in volledige stilte gepatcht, dus dat is al beter dan niets. Het probleem is wat er in die aankondigingen stond. De changelog bestond uit precies twee woorden: "Security Update". De mail ging iets verder met een gerichte beveiligingsupdate die ze alle gebruikers aanraadden zo snel mogelijk te installeren, maar ook daar lees je niet wat er is opgelost, hoe ernstig het is, of dat het al wordt misbruikt.

En dat is nu net de informatie die je nodig hebt. Beheer je sites voor klanten, dan is de enige vraag die telt: patch ik dit vanavond nog, of kan het wachten tot het volgende onderhoudsmoment? "Er is een update" zonder context laat je gokken, en gokken is precies wat je bij beveiliging niet wilt. Bijhouden wát een update repareert is daarom net zo belangrijk als de update zelf binnenhalen.

Waarom dit bij Joomla-extensies blijft gebeuren

Dit is geen toeval, en het ligt ook niet aan Joomla zelf. Het patroon is steeds hetzelfde. Een populaire extensie heeft ergens een onderdeel dat bestanden mag ontvangen, een mediabeheerder, een icoon-upload, een bijlage bij een evenement, en ergens in die keten ontbreekt een controle. Hoe meer sites zo'n extensie draaien, hoe waardevoller dat ene gaatje wordt, want een aanvaller hoeft het maar één keer te vinden.

Daarna gaat het automatisch. Bots scannen massaal het internet af op sites die de kwetsbare extensie draaien en vuren overal hetzelfde trucje af. Jouw site hoeft daarvoor niet interessant te zijn. Het is genoeg dat je de verkeerde extensie in de verkeerde versie draait. Dat is meteen waarom losse extensies, hoe handig ook, je grootste risico-oppervlak vormen: de Joomla-kern wordt streng bewaakt, maar elke extensie die je installeert is code van iemand anders die je er gewoon bij vertrouwt.

De inbreker is misschien al binnen

Hier zit de eigenlijke boodschap. Is een van deze lekken op jouw site misbruikt voordat je updatte, dan heeft de aanvaller in die periode iets achtergelaten om binnen te blijven. Updaten dicht het gat waardoor hij naar binnen kwam, maar het verwijdert niet wat hij in de tussentijd heeft geplaatst. Drie dingen die je dan kunt aantreffen:

• Een verborgen beheerder. Een extra Super User met een geloofwaardige naam, denk aan iets als "Web Editor" of "Admin Backup", en vaak een mailadres dat nergens op slaat. Dat account staat gewoon in je gebruikerslijst. Je moet er alleen even kijken om het te zien.
• Een webshell. Een geüpload PHP-bestand waarmee de aanvaller later opnieuw commando's kan uitvoeren, ook als je het oorspronkelijke lek al hebt gedicht. Die bestanden staan meestal op plekken waar je ze niet verwacht, in uploadmappen of verstopt tussen legitieme bestanden.
• Een kwaadaardige instelling in de extensie zelf. Bij JCE bijvoorbeeld een editor-profiel dat veel meer mag dan het zou moeten.

Tegelijk geldt het omgekeerde ook: niet alles wat verdacht oogt, is een hack. Haal je een scanner over je site, dan krijg je vaak een lijst met bestanden die als "verdacht" worden gemarkeerd omdat ze op een patroon lijken. Dat is iets om naar te kijken, niet iets om in paniek te verwijderen. Het verschil zit tussen "dit bestand lijkt qua opbouw op iets kwaadaardigs" en "dit bestand is aantoonbaar aangepast of geïnjecteerd". Het eerste vraagt om een blik, het tweede om actie. Wie dat onderscheid niet maakt, sloopt of zijn eigen site, of mist juist de echte achterdeur.

Wat je nu het beste kunt doen

1. Op dit moment ben je waarschijnlijk al te laat. Als je de onderstaande stappen niet op dezelfde dag (16 juni 2026) hebt uitgevoerd. Nu kun je het beste een een backup terugzetten van begin juni.
2. Update meteen als je een van deze extensies draait. JCE naar 2.9.99.6, SP Page Builder naar 6.6.2,PageBuilderCK naar 3.6.0 (of 3.4.10 op Joomla 4, 3.1.1 op Joomla 3), iCagenda naar 4.0.8, Helix3 naar 3.1.1. Doe dat via de Joomla-updater of rechtstreeks bij de maker. Kun je echt niet updaten, schakel de extensie dan uit tot het wel kan.
3. Controleer daarna of er al iets gebeurd is. Loop je lijst met Super Users na op accounts die je niet zelf hebt aangemaakt, en kijk in de uploadmappen van de betreffende extensie naar PHP-bestanden die daar niet horen. Bij PageBuilderCK kan zo'n bestand trouwens overal staan, dus beperk je niet tot de voor de hand liggende mappen.
4. Vergeet je andere sites niet. Draai je meer Joomla-sites, of beheer je ze voor klanten, ga ze dan allemaal langs. Een aanvalsbot maakt geen onderscheid, dus jij moet dat ook niet doen. Controleer tevens je ontwikkel- en testwebsites. Ook al worden deze niet geïndexeerd, ze zijn voor bots makkelijk vindbaar.
5. Houd een back-up van vóór de update achter de hand, voor het geval je iets moet terugzetten of wilt vergelijken.