← Terug naar kennisbank JOOMLA

Joomla JCE-editor kritiek beveiligingslek — update én controleer op backdoors

CVE-2026-48907 in de populaire JCE-editor heeft een CVSS-score van 10.0 (maximaal) en wordt actief misbruikt. Updaten alleen is niet genoeg: backdoors die voor de patch zijn geplaatst blijven gewoon staan. Dit stappenplan legt uit wat er speelt, hoe je updatet en hoe je controleert of je site al geraakt is.

Actief misbruik — handel direct. CISA en CSIRT Italia waarschuwen actief voor misbruik van dit lek (16–17 juni 2026). Aanvallers exploiteren het geautomatiseerd. Als jouw Joomla-site de JCE-editor draait en nog niet geüpdatet is, ga dan nu naar stap 1.

Wat is er aan de hand?

De JCE-editor (Joomla Content Editor) is één van de meest geïnstalleerde extensies voor Joomla — actief op meer dan 1% van alle websites wereldwijd. Op 3 juni 2026 bracht de ontwikkelaar een beveiligingsupdate uit voor een kritiek lek: CVE-2026-48907.

Tot 12 juni leek het stil. Toen meldde de ontwikkelaar dat het lek actief werd misbruikt. Sindsdien waarschuwen meerdere nationale CERT-organisaties voor geautomatiseerde aanvallen. De timing is verraderlijk: er zit een gat van bijna tien dagen tussen de patch en het bekende begin van actief misbruik. Sites die in die periode niet geüpdatet zijn, hebben een serieuze kans dat er al iemand binnen is geweest.

Wat kan een aanvaller doen?

Het lek stelt een niet-ingelogde bezoeker in staat een nieuw editor-profiel aan te maken via de JCE-component. Vanuit dat profiel kan een aanvaller vervolgens een PHP-bestand uploaden naar de server. Eén HTTP-request is genoeg om PHP-code op jouw server uit te voeren — zonder wachtwoord, zonder account.

Wat dat concreet betekent:

  • Volledige toegang tot alle bestanden op de hostingomgeving
  • Database-dump van alle klantgegevens, inloggegevens en bestellingen
  • Plaatsen van een backdoor die ook na een update of wachtwoordwijziging actief blijft
  • Gebruik van jouw server voor het versturen van spam of als onderdeel van een botnet
  • SEO-sabotage via verborgen spam-links (pharma hack, casino-injecties)

De CVSS-score van 10.0 is het absolute maximum. Er is geen drempel om het lek te activeren — geen account, geen speciale configuratie nodig.

Stap 1 — Controleer of je JCE draait

Log in op je Joomla-backend en ga naar Extensions → Manage → Manage. Filter op "JCE" of zoek naar "content editor". Als JCE in de lijst staat, noteer dan de versienummer.

Kwetsbaar zijn alle versies van JCE vóór de update van 3 juni 2026. De precieze versienummers staan in het officiële beveiligingsadvies op joomlacontenteditor.net.

JCE niet gevonden? Dan ben je niet kwetsbaar via dit specifieke lek. Kijk toch even of je andere editors hebt staan (TinyMCE is de standaard en heeft dit lek niet, maar check de VEL — vel.joomla.org — altijd even voor andere extensies).

Stap 2 — Update JCE onmiddellijk

Ga naar Extensions → Update in je Joomla-backend. Als de update beschikbaar is, verschijnt JCE in de lijst. Klik op de checkbox en kies "Update". Klaar.

Als de update niet verschijnt:

  1. Klik op "Refresh Cache" bovenaan de updatepagina
  2. Download de nieuwste versie handmatig van joomlacontenteditor.net
  3. Installeer via Extensions → Install → Upload Package File

Controleer na de update het versienummer onder Extensions → Manage → Manage. De update mag je verifiëren, maar ga daarna direct door naar stap 3 — een update verwijdert geen bestaande backdoors.

Stap 3 — Controleer op backdoors (verplicht)

Dit is de stap die de meeste mensen overslaan. Een beveiligingsupdate sluit het lek voor nieuwe aanvallen, maar verwijdert niets van wat er al op je server staat. Als een aanvaller vóór jouw update een PHP-bestand heeft geüpload, staat dat er nog steeds.

Aanvallers plaatsen doorgaans backdoors in mappen waar PHP-bestanden niet thuishoren maar wel te bereiken zijn. Controleer deze locaties:

/images/ map

De standaard upload-map voor Joomla. Via het JCE-lek is dit de meest voor de hand liggende doellocatie. Zoek naar PHP-bestanden die daar niet thuishoren:

find /pad/naar/joomla/images -name "*.php" -o -name "*.php5" -o -name "*.phtml"

Elk resultaat is verdacht. Afbeeldingen zijn .jpg, .png, .gif, .webp — geen .php.

/tmp/ map

find /pad/naar/joomla/tmp -name "*.php" -o -name "*.php5"

/cache/ map

find /pad/naar/joomla/cache -name "*.php" -o -name "*.php5"

Recente bestanden in de webroot (afgelopen 30 dagen)

Kijk welke bestanden recentelijk zijn aangemaakt of gewijzigd — dit geeft context over wanneer een aanvaller actief was:

find /pad/naar/joomla -name "*.php" -newer /pad/naar/joomla/index.php -not -path "*/administrator/*" -not -path "*/components/*" -not -path "*/modules/*" -not -path "*/plugins/*"

Filter het resultaat op bestanden in onverwachte locaties. Namen als shell.php, c99.php, cmd.php, up.php of willekeurige strings als bestandsnaam (aB3xK.php) zijn duidelijke rode vlaggen. Maar aanvallers camoufleren backdoors ook als legitieme bestanden — configuration.php in een submap, of iets als cache.php in /images/.

Controleer ook de database

Via het JCE-profiel dat aanvallers aanmaken, kunnen aanvullende wijzigingen in de database zijn gedaan. Kijk in phpMyAdmin of via WP-CLI (voor Joomla: gebruik de Joomla CLI) naar:

  • Onbekende beheerdersaccounts in de #__users tabel
  • Wijzigingen in #__extensions (nieuwe extensies toegevoegd)
  • Verdachte inhoud in #__content (verborgen spam-links)

Stap 4 — Reset inloggegevens

Als een aanvaller actief is geweest op je server, moet je ervan uitgaan dat gevoelige gegevens zijn buitgemaakt. Reset in elk geval:

  • Joomla Super User wachtwoord — via Users → Manage Users in de backend
  • Database wachtwoord — via je hostingpanel en daarna ook bijwerken in configuration.php
  • FTP/SFTP wachtwoord — via je hostingpanel
  • Hostingpanel wachtwoord (cPanel, Plesk, DirectAdmin) — dit staat los van Joomla maar is minstens zo belangrijk
  • E-mailwachtwoord gekoppeld aan het domein — aanvallers gebruiken gecompromitteerde e-mailaccounts voor spam

Stap 5 — Overweeg een backup terug te zetten

Als je een goede backup hebt van vóór begin juni 2026, overweeg die terug te zetten op een schone omgeving. Dit is de enige manier om met zekerheid te weten dat er geen backdoors meer aanwezig zijn — handmatig zoeken vindt de meeste gevallen, maar niet per definitie alle.

Wat "schone omgeving" betekent: niet gewoon de bestanden terugzetten op dezelfde server. Als een aanvaller servertoegang heeft gehad, kunnen ze ook bestanden buiten de webroot hebben gewijzigd (cron jobs, .bashrc, SSH authorized_keys). Bij twijfel: contact opnemen met de hoster voor een volledig server-herstel, of verhuizen naar een nieuwe hostingomgeving.

Geen backup? Dan is grondig handmatig onderzoek de enige optie. Dat is tijdrovend maar wel uitvoerbaar. Stap 3 hierboven geeft de startpunten. Als je daar zelf niet uitkomt, neem dan contact op — ik heb dit proces voor meerdere gehackte Joomla-sites doorlopen.

Stap 6 — Bescherm /images/ en /tmp/ tegen toekomstige aanvallen

Ongeacht of je nu geraakt bent, is dit een goede preventieve maatregel die je nu meteen kunt doorvoeren. Plaats een .htaccess bestand in je /images/ map (en in /tmp/ als die in de webroot staat) dat PHP-uitvoering blokkeert:

<FilesMatch "\.(php|php5|phtml|pl|py|jsp|asp|sh|cgi)$">
    Require all denied
</FilesMatch>

Hiermee kan een aanvaller nog steeds een PHP-bestand uploaden als er een nieuw lek is, maar het aanroepen via een URL zal altijd een 403 geven. Zie ook het uitgebreide Joomla beveiligen stappenplan voor meer maatregelen in dezelfde lijn.

Hoe weet ik of mijn site al aangevallen is?

Een paar signalen die kunnen wijzen op misbruik via dit lek:

  • De site is trager dan normaal zonder aanwijsbare oorzaak (extra processen draaien op de server)
  • Bezoekers klagen over doorverwijzingen naar andere sites
  • Google Search Console meldt "Hacked content" of geeft een veiligheidsmelding
  • Je ontvangt meldingen dat jouw domein spam verstuurt
  • Er staan onbekende bestanden in /images/ of /tmp/ (zie stap 3)
  • Er zijn onbekende gebruikers aangemaakt in de Joomla-backend
  • Je hostingprovider blokkeert de site wegens verdacht verkeer of malware

Geen van deze signalen aanwezig? Dat betekent niet per se dat er niets is. Veel backdoors zijn ontworpen om stil te blijven tot de aanvaller ze nodig heeft. Grondig checken (stap 3) is hoe dan ook de juiste aanpak als je JCE had draaien zonder de update van begin juni.

Tijdlijn van dit lek

  • 3 juni 2026 — JCE-ontwikkelaar brengt beveiligingsupdate uit voor CVE-2026-48907
  • 12 juni 2026 — Ontwikkelaar meldt dat actief misbruik van het lek is waargenomen
  • 16–17 juni 2026 — CISA (VS) en CSIRT Italia waarschuwen publiek voor actieve aanvalsgolven

Het tijdvenster van 3 tot 12 juni is de periode waarin aanvallers al actief konden zijn, terwijl beheerders mogelijk nog niet wisten dat er haast bij was. Als jouw site in die periode niet geüpdatet was, is een grondige controle essentieel.

Wanneer schakel je hulp in?

  • Je hebt PHP-bestanden gevonden in /images/ of /tmp/ maar weet niet wat je er mee moet doen
  • Er staan onbekende beheerdersaccounts in de database
  • Je hebt geen bruikbare backup van vóór begin juni
  • Google, Sucuri of je hoster heeft de site al als gehackt gemarkeerd
  • Je wilt zekerheid dat de site schoon is maar wil dat niet zelf uitzoeken
  • De site is zakelijk kritiek en je wilt een forensisch overzicht van wat er is gebeurd