Heel veel Joomla-websites gehackt door lek in JCE editor

Deze week werd bekendgemaakt dat de editor JCE voor Joomla een lek bevat. Hierdoor kunnen hackers eenvoudig toegang krijgen tot een website met Joomla en een oudere versie van JCE.
De enige veilige versie van JCE is momenteel 2.9.99.6. Dit is de nieuwste release en de versie die elke site moet  gebruiken. Oudere versies bevatten nog steeds de kwetsbaarheid voor het uploaden van profielen zonder authenticatie, die door deze aanval wordt misbruikt.

Het volledige verhaal op één plek: dit is een vertaling van de pagina over de JCE-profielenhack. Dat is dé bron voor deze informatie, met de uitleg van hack en de tool die de hack detecteert en verhelpt.
En onderaan het artikel hebben wij nog twee methodes geplaatst om het handmatig aan te pakken.


JCE (Joomla Content Editor) wordt op meer Joomla-sites gebruikt dan welke andere editor-extensie dan ook. Het staat in de top twee van onze ranglijst van actieve extensies, nek aan nek met Akeeba Backup. Toen de JCE-profielenaanval deze maand op websites begon toe te slaan, werd de vraag "Zijn er sites waar ik verantwoordelijk voor ben gehackt!?" een vraag die elk Joomla-beheerder zich plotseling moest stellen. mySites.guru beantwoordt deze vraag nu automatisch voor je, op elke site die je beheert.

ZIj hebben een nieuwe, speciale controle toegevoegd: 'Controleer op malafide JCE-profielen en backdoors'. Deze controle wordt twee keer per dag uitgevoerd op elke gekoppelde Joomla-site en vindt automatisch de kenmerken van deze aanval: malafide editorprofielen en de webshells die ze plaatsen. Wanneer er iets wordt gedetecteerd, is het oplossen ervan een bewuste actie met één klik die je zelf kunt uitvoeren. Op Joomla 4, 5 en 6 verwijder je de profielen, verwijder je de backdoors en werk je JCE bij naar de gepatchte versie, allemaal vanuit één scherm. Er wordt niets automatisch verwijderd, omdat je eerst wil zien wat er aanwezig is en een back-up wilt maken. In dit bericht wordt beschreven wat er wordt gecontroleerd en hoe je de controle kunt gebruiken, evenals de live hack die mySites.guru ertoe aanzette om deze functie te ontwikkelen.

Ze hebben deze functie ontwikkeld omdat ze steeds weer op de echte versie stuitten. Tijdens ons onderzoek naar de oorzaak van een templatefout op een Joomla-site, ontdekten ze de nasleep van een JCE-profielaanval op de live website: een malafide editorprofiel dat was aangemaakt om het uploaden van bestanden mogelijk te maken, en een reeks webshells die via dat profiel waren geïnstalleerd. De site draaide een JCE-versie die oud genoeg was om de kwetsbaarheid voor het uploaden van profielen zonder authenticatie (CVE-2026-48907) te bevatten. Toen ze de rest van het portfolio controleerden, bleken nog twee andere sites deze kwetsbaarheid ook te hebben. Het handmatig controleren van 40 klantwebsites is precies het soort werk dat vaak niet gedaan wordt, dus hebben ze het geautomatiseerd.

Kort samengevat:

• mySites.guru heeft nu een speciale controle op malafide JCE-profielen en backdoors die twee keer per dag op elke gekoppelde Joomla-site wordt uitgevoerd.
• Het vindt malafide editorprofielen en de webshells die hackers automatisch installeren. Als er iets wordt gemarkeerd, kun je het handmatig oplossen vanuit één scherm: op Joomla 4, 5 en 6 verwijder je dan de profielen, verwijder je de backdoors en werk je JCE bij met één klik.
• De controle is afgestemd op de vingerafdruk van deze aanval, dus een profiel dat slechts permissief is (een profiel met allow_php ingeschakeld om legitieme redenen) wordt niet gemarkeerd. Het onderscheidende criterium is of een profiel het uploaden van een scriptbestand toestaat.
• De aanval zelf misbruikt de niet-geauthenticeerde upload van editorprofielen die is gepatcht in JCE 2.9.99.5 (CVE-2026-48907): importeer een malafide profiel dat php- en txt-uploads toestaat en gebruik dit vervolgens om een webshell te installeren.
• Het begon met drie sites in één portfolio. Ze hebben er sindsdien honderden gezien, en met de werkende exploitcode voor CVE-2026-48907 die op 9 juni op GitHub is gepubliceerd, verwachten ze er de komende dagen duizenden. Eén gecompromitteerde site is zelden de enige.
• Om elke installatie te vinden die nog steeds een kwetsbare build gebruikt, combineer de controle met de zoekfunctie van de mySites.guru-extensie en patch ze in één keer met de massale updater.
• Het verwijderen van de bestanden zonder JCE bij te werken, vergroot de kans op herinfectie: patch het toegangspunt, ruim niet alleen de rommel op.

De snelste manier om deze hack op te lossen

• De snelste manier om een gehackte website weer schoon te krijgen is te controleren of er sinds 8 juni geen aanpassingen meer zijn gedaan in de inhoud van de website.
• Als dat zo is, plaats dan de meest recente backup terug die je misschien zelf hebt gemaakt met Akeeba Backup of die beschikbaar is via het beheerportaal van de provider.
• Zorg ervoor dat direct na het terugplaatsen van de backup zowel Joomla als alle extensies, en vooral de JCE-editor, worden geüpdatet naar de meest recente versie.
• En wijzig de wachtwoorden van de superadministrator- en administratoraccounts.

Zelf handmatig controle uitvoeren en opschonen

Het is natuurlijk ook mogelijk dat je probeert het zelf handmatig op te lossen.
Begin altijd eerst met het maken van een volledige website-backup met Akeeba Backup.
Ga daarna in het backend-gedeelte van je website naar het component JCE en open daar Profielen.

De JCE-profielen.
Daarin zie je de machinaal gegenereerde profielna(a)m(en) die overeenkomen met een J gevolgd door zes cijfers 'J940401' of een standaard naam met een nummer erachter 'Default(2)' of labels zoals 'Pwned' met een beschrijving van RCE via JCE. Deze profielen moet je handmatig verwijderen.

Geplaatste backdoors (bestanden) verwijderen
Controleer de locaties die deze hack gebruikt. Dat zijn de mappen: tmp, images, media/system/js, libraries/joomla. Controleer daar op verborgen .xml.php bestanden.
In deze mappen horen bestanden met .xml en .php niet thuis. Die moet je daar dus handmatig verwijderen.

Aanvullende controle (op basis van praktijkervaring bij meerdere sites):
Naast de genoemde .xml.php-bestanden in tmp, images, media/system/js en libraries/joomla, zijn bij meerdere getroffen sites ook extra backdoor-bestanden aangetroffen in de map images/ (en submappen direct daaronder), met namen volgens een vast patroon:

up_XXXX.php, up_XXXX.phtml, up_XXXX.pht (XXXX = willekeurige cijfers) - uploader-shells
cmd_XXXX.php, cmd_XXXX.phtml, cmd_XXXX.pht - command-execution shells

Deze bestanden horen daar net zo min als de .xml.php-bestanden en kunnen op dezelfde manier handmatig verwijderd worden.

Let ook op .htaccess-bestanden met de volgende inhoud, die de aanvaller soms zelf in deze mappen plaatst (waarschijnlijk om eigen sporen voor anderen te verbergen):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule \.(php|phtml|php3|php4|php5|php7|php8|phar|shtml|cgi|htaccess)$ - [F,L]
</IfModule>

Check of een eventuele .htaccess in images, tmp, media, administrator/tmp deze regel bevat en hoort daar normaal niet — als je twijfelt of deze door de hack is toegevoegd, vergelijk de aanmaakdatum met je laatste bekende-goede backup.

Tip: controleer ook de mappen administrator/tmp/ en libraries/joomla deze bestaan normaal niet in een standaard Joomla-installatie en kunnen eveneens gedropte bestanden bevatten.

Maak, zoals al aangegeven, altijd eerst een volledige backup vóórdat je iets verwijdert.

Verander de wachtwoorden op je website.
Verander de wachtwoorden van de superadministrators en administrators op je website, zodat de hacker er geen gebruik meer van kan