Wenn Sie eine E-Mail von mir erhalten haben, die Sie auf diese Seite verweist, liegt das daran, dass Ihre Website anscheinend eine Version von iCagenda ausführt (com_icagenda von JoomliC, eine Veranstaltungskalender-Erweiterung für das Content-Management-System Joomla), die von einem bekannten Sicherheitsproblem betroffen ist. Diese Seite erklärt, worum es sich bei dem Problem handelt, wie Sie überprüfen, ob es auf Sie zutrifft, und wie Sie es beheben.

Dieser Hinweis betrifft CVE-2026-48939, eine kritische, aktiv ausgenutzte Schwachstelle, die einen nicht authentifizierten, beliebigen Datei-Upload mit anschließender Remotecodeausführung über das Front-End-Formular „Submit an Event” der Erweiterung ermöglicht. Sie wurde am 10. Juli 2026 in den Katalog Known Exploited Vulnerabilities der US-amerikanischen Cybersecurity and Infrastructure Security Agency aufgenommen.

Zwei Bedingungen, und beide müssen zutreffen

Ihre Website ist von der Remotecodeausführung betroffen, wenn beide der folgenden Punkte zutreffen:

  1. iCagenda befindet sich auf der 4.0.x-Linie, in einer Version unterhalb von 4.0.8 (das heißt 4.0.0 bis 4.0.7), und
  2. der Joomla-Kern liegt unterhalb von 6.1.2.

Wenn iCagenda 4.0.8 oder neuer ist, sind Sie nicht betroffen. Und wenn Ihr Joomla-Kern 6.1.2 oder neuer ist, sind Sie ebenfalls nicht betroffen, selbst bei einer alten iCagenda-Version, weil der Kern selbst den Upload blockiert. Trifft dies auf Ihre Website zu, können Sie an dieser Stelle aufhören zu lesen, außer um zur Kenntnis zu nehmen, dass sich eine Aktualisierung von iCagenda dennoch lohnt.

Die zweite Bedingung ist der Punkt, an dem diese Seite dem Hinweis des Herstellers selbst widerspricht, der besagt, dass das Problem nur Websites betrifft, die Joomla 6 ausführen. Es erreicht auch vollständig aktualisierte Joomla-4- und Joomla-5-Websites, und ich lege die Belege dafür weiter unten dar, denn der Hersteller behauptet etwas anderes, wenn Sie dem Link folgen.

Wenn Sie eine betroffene Version verwenden, aktualisieren Sie iCagenda, und weil diese Schwachstelle ausgenutzt wurde, bevor ein Fix existierte, prüfen Sie Ihre Website zusätzlich auf Anzeichen dafür, dass jemand bereits zuvor dort war (siehe Wenn Sie eine betroffene Version genutzt haben weiter unten).

Ein Hinweis für alle auf der älteren 3.9.x-Linie. Der veröffentlichte CVE-Bereich schließt 3.9.x mit ein, und der Hersteller hat auch diese Linie gepatcht, in 3.9.15. Nach meiner eigenen Lektüre und meinen eigenen Tests verwendet die 3.9.x-Linie für den Upload einen anderen, geschützten Codepfad, sodass das Ergebnis der Remotecodeausführung dort nicht erreichbar ist: Auf Joomla 4 und 5 wird der Upload vom Kern blockiert, und auf Joomla 6 existiert dieser Codepfad überhaupt nicht mehr, sodass die Funktion schlicht einen Fehler ausgibt. Das ist kein Grund, das Update zu ignorieren. Dieselben Veröffentlichungen beheben eine fehlende Autorisierungsprüfung, die es einem anonymen Besucher ermöglicht, ein nicht genehmigtes Ereignis auf Ihre Website zu schieben (und, auf Joomla 4 und 5, dazu eine Datei eines zulässigen Typs). Geringerer Schweregrad, aber dennoch behebenswert: aktualisieren Sie auf 3.9.15 oder neuer. Beachten Sie außerdem, dass der Hersteller Sicherheitspatches für die 3.9.x-Linie nur bis zum 13. Oktober 2026 bereitstellt.

Ist diese Nachricht echt?

Ja. Dies ist ein Hinweis im guten Glauben im Rahmen der verantwortungsvollen Offenlegung eines unabhängigen Sicherheitsforschers. Ich bitte Sie nicht um Geld, Passwörter oder Zugriff auf Ihre Website, und ich habe nicht versucht, in sie einzubrechen, etwas hochzuladen oder etwas auszunutzen.

Was ich gelesen habe, waren zwei öffentliche Dateien, die Ihre Website jedem bereitstellt, der danach fragt: das iCagenda-Komponentenmanifest unter /administrator/components/com_icagenda/icagenda.xml und das Joomla-Kernmanifest unter /administrator/manifests/files/joomla.xml. Beide sind einfache XML-Versionsdateien, und es sind dieselben zwei Dateien, die weiter unten unter Wie Sie Ihre Versionen überprüfen beschrieben werden, sodass Sie genau sehen können, was ich gesehen habe. Das ist alles. Ich habe insbesondere nicht Ihr Veranstaltungsformular abgeschickt, nichts hochgeladen und nicht das Anhänge-Verzeichnis Ihrer Website angefragt. Dieser Pfad erscheint weiter unten auf dieser Seite nur als ein Ort, an dem Sie auf Ihrer eigenen Website nachsehen können. Nichts an dieser Überprüfung berührt Ihre Daten, Ihren Admin-Bereich oder einen privaten Teil Ihrer Website.

Wenn Sie überprüfen möchten, wer ich bin, finden Sie die Kontaktdaten am Ende dieser Seite und auf der Seite Über.

Warum das wichtig ist

iCagenda veröffentlicht einen Veranstaltungskalender auf Joomla-Websites. Eine seiner Funktionen ermöglicht es einem Besucher, über ein Front-End-Formular ein Ereignis einzureichen und dabei optional eine Datei anzuhängen, die unter images/icagenda/frontend/attachments/ landet.

In betroffenen Versionen wird diese Einreichung ohne Anmeldung akzeptiert, und der Anhang wird auf die Festplatte geschrieben, ohne dass geprüft wird, um welche Art von Datei es sich handelt, wobei Name und Erweiterung so übernommen werden, wie der Einreichende sie gewählt hat. Diese Kombination ermöglicht es einem Angreifer, ein Programm seiner Wahl auf Ihrem Server zu platzieren und auszuführen: vollständige Remotecodeausführung, ohne Konto und ohne jede Mitwirkung Ihrerseits erforderlich.

Nichts muss aktiviert werden, damit dies zutrifft. Das Formular muss nicht veröffentlicht oder für Besucher sichtbar sein: In betroffenen Versionen akzeptierte der dahinterliegende Controller die Einreichung unabhängig davon.

Dies ist kein theoretisches Risiko. Sie wird von der NVD mit 9,8 von 10 bewertet (und mit 10,0 durch die zuweisende Stelle nach dem neueren Bewertungssystem), und sie wird aktiv in freier Wildbahn ausgenutzt. Der Hersteller berichtet, dass die Ausnutzung am 15. Juni 2026 um 08:00 UTC begann, bevor der Patch existierte, und beschreibt die Angriffe als automatisiert. Die CISA hat sie am 10. Juli 2026 in den Known-Exploited-Vulnerabilities-Katalog aufgenommen.

Ich beschreibe dies auf einem Niveau, das ein Website-Betreiber zum Handeln benötigt, und nicht weiter. Ich veröffentliche nicht die Details, die es jemandem ermöglichen würden, dies nachzustellen, und ich bitte Sie, dies nicht gegen Ihre eigene Website oder die einer anderen Person zu versuchen. Das Ablesen Ihrer beiden Versionsnummern, wie unten beschrieben, sagt Ihnen alles, was Sie wissen müssen, um zu entscheiden, was zu tun ist.

Wenn meine E-Mail dieses Problem zitiert hat, bedeutet das, dass die Versionen, die Ihre Website meldet, sie in beiderlei Hinsicht in den betroffenen Bereich einordnen. Ich habe nicht getestet, ob Ihre spezifische Website ausnutzbar oder bereits kompromittiert ist.

Wo diese Seite vom Hinweis des Herstellers abweicht

Der Hinweis des Herstellers ist lesenswert, und ich verlinke ihn weiter unten. Er hat schnell einen Fix veröffentlicht, und seine Anleitung ist gut. Aber ein Satz darin, der den Geltungsbereich absteckt, hält der Prüfung nicht stand, und da es genau der Satz ist, der die meisten Leser dieser Seite zur Entwarnung verleiten würde, möchte ich meine Belege zeigen, statt es nur zu behaupten. Der Hinweis sagt:

Unsichere Datei-Uploads wurden auf allen Joomla-Versionen vor Joomla 6 bereits standardmäßig blockiert. Nur die Installation von iCagenda auf Joomla 6 (6.0.0-6.1.1) wies die kritische Upload-Schwachstelle auf.

Hier ist, was ich auf eigenen, isolierten Installationen gemessen habe. Zu keinem Zeitpunkt war eine Website Dritter beteiligt.

  • iCagenda 4.0.x führt den Upload über die Framework-Klasse Joomla\Filesystem\File aus, die aus dem Paket joomla/filesystem stammt, das der Joomla-Kern mitbringt. Sie verwendet nicht die ältere, gleichnamige Joomla-CMS-Klasse, die schon immer eine Sicherheitsprüfung für Dateien enthielt und vermutlich diejenige ist, die der Hinweis im Sinn hat.
  • Diese Framework-Methode erhielt ihre eigene Sicherheitsprüfung (den Parameter $allowUnsafe und den isSafeFile-Test) erst in joomla/filesystem 4.2.0, der Version, die mit Joomla 6.1.2 ausgeliefert wird.
  • Die Versionen, die tatsächlich mit den von mir geprüften Joomla-Veröffentlichungen ausgeliefert werden: Joomla 4.4.14 liefert filesystem 2.0.2 aus (keine Prüfung), Joomla 5.4.7 liefert 3.2.0 aus (keine Prüfung), und Joomla 6.1.2 liefert 4.2.0 aus (Prüfung vorhanden).

Eine vollständig gepatchte Joomla-4- oder Joomla-5-Website, auf der iCagenda 4.0.0 bis 4.0.7 läuft, ist also gefährdet, und deshalb formuliert diese Seite die Joomla-Bedingung als „unterhalb von 6.1.2” statt „nur Joomla 6”. Weder der veröffentlichte CVE-Eintrag noch der NVD-Eintrag noch der CISA-Katalog schränken dieses Problem überhaupt nach Joomla-Version ein; der Satz im Hinweis des Herstellers ist die einzige Stelle, an der eine solche Einschränkung auftaucht.

Wie Sie Ihre Versionen überprüfen

Sie müssen mir bei keiner der beiden Zahlen aufs Wort glauben, und es gibt zwei davon zu überprüfen.

Ihre iCagenda-Version, aus der Manifest-Datei (keine Anmeldung erforderlich): Öffnen Sie

yourdomain.com/administrator/components/com_icagenda/icagenda.xml

und lesen Sie das darin enthaltene <version>-Element. Das ist eine der beiden Dateien, die ich gelesen habe.

Ihre iCagenda-Version, aus dem Administratorbereich:

  1. Melden Sie sich in Ihrem Joomla-Administrator an (meist unter yourdomain.com/administrator).
  2. Gehen Sie zu System, dann Verwalten, dann Erweiterungen.
  3. Suchen Sie nach iCagenda und notieren Sie die installierte Version.

Achten Sie darauf, welche icagenda.xml Sie lesen. Das iCagenda-Paket liefert auch ein gebündeltes Suchplugin mit einem Manifest desselben Namens aus, das seine eigene, unabhängige Versionsnummer trägt. Nur der oben genannte Komponentenpfad zeigt Ihnen, welche Version der Erweiterung tatsächlich läuft.

Ihre Joomla-Kernversion: Gehen Sie im Administrator zu System, dann Systeminformationen. Oder lesen Sie /administrator/manifests/files/joomla.xml und entnehmen Sie das darin enthaltene <version>-Element. Das ist die andere Datei, die ich gelesen habe.

Es gibt keine Möglichkeit, die iCagenda-Version aus Ihrem öffentlichen Seitenquelltext abzulesen, und Sie sollten es nicht versuchen. Die Front-End-Assets der Erweiterung tragen den seitenweiten Medien-Hash von Joomla statt einer Versionsnummer, und die einzige versionsartige Zahl, die tatsächlich im Seitenquelltext erscheint, gehört zum Asset-Bundle des Kalendermoduls (eine niedrige Zahl wie 1.0.4) und hat nichts mit der Komponente zu tun. Die Manifest-Datei oder der Administrator-Bildschirm sind die einzige verlässliche Überprüfung.

Wenden Sie dann die Regel vom Anfang dieser Seite an: Die 4.0.x-Linie unterhalb von 4.0.8 und ein Kern unterhalb von 6.1.2 bedeutet betroffen.

Wie Sie aktualisieren

Der sicherste Weg ist die Aktualisierung über Joomla selbst, und zwar nach vorheriger Sicherung:

  1. Sichern Sie Ihre Website (Dateien und Datenbank), bevor Sie Änderungen vornehmen. Die meisten Hosting-Anbieter bieten Ein-Klick-Sicherungen an, oder verwenden Sie eine Joomla-Backup-Erweiterung.
  2. Öffnen Sie im Joomla-Administrator Erweiterungen, dann Verwalten, dann Aktualisierung, und klicken Sie auf Updates suchen. Wenn ein iCagenda-Update aufgeführt ist, installieren Sie es von hier aus.
  3. Wenn dort kein Update erscheint, laden Sie die aktuelle Veröffentlichung direkt beim Hersteller herunter, JoomliC, und installieren Sie sie über Erweiterungen, dann Installieren.
  4. Welche Version Sie installieren sollten: 4.0.8 ist die Veröffentlichung, die dieses Problem behebt, aber die aktuelle Veröffentlichung zum Zeitpunkt der Erstellung dieser Seite ist 4.0.11, und die Veröffentlichungen nach 4.0.8 fügen für dieselbe Funktion weiteren Schutz hinzu, einschließlich der Blockierung von Codeausführung aus dem iCagenda-Medienordner. Gehen Sie auf 4.0.11, statt bei 4.0.8 stehen zu bleiben. Auf der älteren Linie gehen Sie auf 3.9.15 oder neuer.
  5. Alternativ schließt auch eine Aktualisierung des Joomla-Kerns auf 6.1.2 oder neuer dieses spezielle Problem, ersetzt aber nicht die Aktualisierung der Erweiterung: Die fehlende Autorisierungsprüfung befindet sich in iCagenda selbst, und nur ein iCagenda-Update behebt sie.
  6. Bestätigen Sie nach der Aktualisierung die neue Versionsnummer anhand der oben genannten Schritte, und prüfen Sie, ob Ihr Kalender weiterhin angezeigt wird und die Ereigniseinreichung weiterhin wie erwartet funktioniert.

Während Sie ohnehin dort sind, lohnt es sich zu bestätigen, dass Joomla selbst und Ihre übrigen Erweiterungen auf dem neuesten Stand sind, denn dasselbe Prinzip gilt für alle.

Wenn Sie eine betroffene Version genutzt haben

Weil diese Schwachstelle ausgenutzt wurde, bevor ein Fix verfügbar war, sollte eine Website, auf der eine betroffene Version lief, nicht davon ausgehen, dass eine Aktualisierung ausreicht. Die Aktualisierung schließt die Tür, sagt Ihnen aber nicht, ob jemand bereits hindurchgegangen ist. Das ist es wert, in Ruhe überprüft zu werden, statt vom Schlimmsten auszugehen: Die meisten Websites werden nichts finden. In den eigenen Worten des Herstellers:

Das Update schließt den Einstiegspunkt und schützt die Funktion für Datei-Anhänge, bereinigt aber keine bereits kompromittierte Website. […] Bewahren Sie Kopien verdächtiger Dateien als Beweismittel auf, löschen Sie sie, ändern Sie Ihre Joomla-Passwörter und Zugangsdaten, und überprüfen Sie Ihre gesamte Website, nicht nur den iCagenda-Ordner.

Hier ist, wonach Sie (oder Ihr Webmaster) auf Ihrer eigenen Website suchen können:

  • PHP-Dateien unter images/icagenda/frontend/attachments/. Dieser Ordner sollte ausschließlich Ereignis-Anhänge enthalten. Auf einem Linux-Host lautet die Prüfung:

    find images/icagenda/frontend/attachments -name '*.php' -type f
  • Nicht genehmigte, anonyme Ereignisse in Ihrer Moderationswarteschlange, die Sie nicht erwarten würden, wenn Sie die Ereigniseinreichung nie für die Öffentlichkeit geöffnet haben.
  • Treffer in Ihren Zugriffsprotokollen von einem Scanner, der sich als icagenda-batch/1.0 identifiziert.

Ab 4.0.8 prüft iCagenda auch selbst auf Anzeichen einer Kompromittierung und gibt nach der Aktualisierung eine Warnung aus, falls es welche findet. Der Hersteller macht unmissverständlich klar, dass das Ausbleiben dieser Warnung keine Garantie ist; sie ist daher ein nützliches Signal, aber keine Entwarnung.

Wenn Sie eines dieser Anzeichen finden, behandeln Sie die Website als kompromittiert: Bewahren Sie Kopien der verdächtigen Dateien als Beweismittel auf und entfernen Sie sie anschließend, erneuern Sie alle Zugangsdaten (Joomla-Administrator, Datenbank, FTP/SSH, Hosting-Panel), überprüfen Sie Ihre Joomla-Benutzerkonten und die Gruppen, denen sie angehören, und überprüfen Sie die gesamte Website statt nur den iCagenda-Ordner. Die Wiederherstellung aus einer Sicherung, die vor dem 15. Juni 2026 erstellt wurde, ist oft sicherer als eine Bereinigung vor Ort, weil eine zurückgelassene Hintertür die Bereinigung wieder rückgängig machen kann. Wenn Ihre Organisation über ein IT-Sicherheitsteam oder ein nationales CERT verfügt, binden Sie diese ein.

Ich möchte das klarstellen: Ich habe Ihre Website nicht auf eines dieser Anzeichen hin überprüft, und ich weiß nicht, ob Ihre Website betroffen war. Diese Liste ist hier, damit Sie selbst nachsehen können.

Ich habe keinen Webmaster / ich komme nicht weiter

Wenn Sie nicht die Person sind, die die Website wartet, leiten Sie diese Seite bitte an diejenige Person weiter, die dies tut (Ihr Webentwickler, Agentur oder Hosting-Anbieter). Sie werden die oben genannten Schritte schnell erkennen.

Wenn Sie die Website selbst warten und feststecken, helfe ich Ihnen gerne kostenlos in die richtige Richtung. Kontaktieren Sie mich über die unten stehenden Kontaktdaten.

Kontakt

Evan Harris, Sicherheitsforscher

Ich kontaktiere Sie bezüglich solcher Probleme ausschließlich, um Betreibern bei der Sicherung ihrer Websites zu helfen. Wenn Sie nicht erneut kontaktiert werden möchten, teilen Sie mir dies einfach mit, und ich werde dies respektieren.

Quellen

Offizielle Meldungen und Nachverfolgung

Hersteller (JoomliC)