Joomla / RSFiles!: Unauthenticated File Upload – Webshell-Befall erkennen und bereinigen

Im Sommer 2026 wurde für die Joomla-Erweiterung RSFiles! eine kritische Sicherheitslücke bekannt, über die nicht angemeldete Besucher Dateien hochladen konnten. Besonders problematisch: Dadurch konnten auch PHP-Dateien in den Downloadbereich gelangen und anschließend über den Webserver ausgeführt werden.

In einer von mir administrierten Joomla-Installation war diese Schwachstelle tatsächlich ausgenutzt worden.

Dieser Beitrag dokumentiert die wichtigsten Spuren, die Bereinigung und einige Erkenntnisse aus dem Vorfall.

Die Sicherheitslücke

RSJoomla veröffentlichte am 10. Juli 2026 RSFiles! 1.17.12 und schloss damit eine Schwachstelle im Frontend-Upload.

Nach Angaben des Herstellers konnte die fehlerhafte Upload-Funktion von nicht angemeldeten Besuchern verwendet werden und erlaubte dabei auch Dateitypen, die dort niemals hätten landen dürfen – einschließlich PHP-Dateien.

Die Schwachstelle wurde mit RSFiles! 1.17.12 behoben.

Wer eine ältere Version eingesetzt hat, sollte deshalb nicht nur aktualisieren, sondern auch prüfen, ob die Lücke bereits ausgenutzt wurde.

Das erste sichtbare Symptom

Die Webseite selbst wirkte zunächst weitgehend normal.

Auffällig wurde der Vorfall unter anderem durch ungewöhnliche, von Google indexierte URLs. Eine davon sah beispielsweise so aus:

/component/rsfiles/details?path=Nx_164.php&Itemid=...

Eine PHP-Datei mit einem Namen wie Nx_164.php hat in einem normalen Downloadbestand nichts verloren.

Bei der anschließenden Untersuchung fanden sich tatsächlich zahlreiche verdächtige PHP-Dateien im RSFiles-Downloadbereich.

Gefundene Dateien

Unter den Funden waren unter anderem Namen wie:

Nx_*.php
shell.php
shell.PHP
sh.phtml
se.phar
se.inc
rsfiles_cache.php
bob_ipob4.php
bob_ipob4.php5
bob_ipob4.php7

Daneben existierten weitere PHP-, PHTML- und PHAR-Dateien mit zufällig wirkenden Namen.

Wichtig: Ein verdächtiger Dateiname allein beweist noch nicht, was eine Datei tut.

In diesem Fall zeigte die Inhaltsanalyse jedoch eindeutig Funktionen, die in einem normalen Downloadverzeichnis nichts zu suchen haben, darunter Datei-Uploads, Base64-Verarbeitung, PHP-Informationen und Möglichkeiten zur Ausführung von PHP-Funktionen.

Damit war klar: Es handelte sich nicht nur um erfolglose Angriffsversuche. Auf dem Webspace lagen tatsächlich Webshells.

Was ein solcher Fund bedeutet – und was nicht

Eine ausführbare Webshell unter dem Benutzer des Webservers ist ein ernstzunehmender Sicherheitsvorfall.

Sie bedeutet in diesem Fall:

Fremder PHP-Code konnte mit den Rechten des Joomla-/Webspace-Benutzers ausgeführt werden.

Das ist allerdings nicht automatisch gleichbedeutend mit:

Der gesamte Server wurde als root kompromittiert.

Diese Unterscheidung ist wichtig.

Ein PHP-Prozess kann beispielsweise:

Ob darüber hinaus Root-Rechte erlangt wurden, muss separat untersucht werden.

In meinem Fall gab es Belege für eine Kompromittierung des Webspace-Benutzers, aber keinen belastbaren Nachweis einer erfolgreichen Root-Kompromittierung.

Die Access-Logs waren besonders hilfreich

In den Webserver-Logs ließen sich Upload-Versuche nachvollziehen.

Auffällig waren unter anderem Requests auf:

index.php?option=com_rsfiles&task=upload

bzw.

index.php?option=com_rsfiles&task=rsfiles.upload

Der Hersteller selbst empfiehlt nach Bekanntwerden der Schwachstelle, insbesondere nach entsprechenden POST-Requests zu suchen.

Eine einfache Suche kann beispielsweise so aussehen:

grep -Rni \
'option=com_rsfiles.*task=.*upload' \
/var/www/vhosts/system/DOMAIN/logs/

Dabei sollte man beachten:

Eine IP-Adresse im Log bezeichnet zunächst nur die Quelle eines Requests. Daraus lässt sich nicht ohne Weiteres ableiten, welche reale Person hinter einem Angriff stand.

Nicht einfach alles löschen

Bei einem solchen Vorfall ist die Versuchung groß, verdächtige Dateien sofort zu löschen.

Für eine spätere Analyse ist es sinnvoller, sie zunächst außerhalb des Webroots zu sichern.

Beispielsweise:

mkdir -p /root/incident-quarantine
chmod 700 /root/incident-quarantine

Verdächtige Dateien können anschließend dorthin verschoben und nur für root lesbar gemacht werden.

Vor dem Verschieben sollte man – sofern möglich – mindestens festhalten:

stat DATEI
sha256sum DATEI
file DATEI

So bleiben Dateigröße, Zeitstempel, Dateityp und kryptographischer Hash dokumentiert.

Ein SHA256-Hash ist beispielsweise hilfreich, um später festzustellen, ob mehrere unterschiedlich benannte Dateien tatsächlich identisch waren.

Weitere Kopien außerhalb des Downloadordners

Die Untersuchung sollte nicht beim offensichtlichen Fundort enden.

In meinem Fall fanden sich weitere verdächtige PHP-Dateien außerhalb des ursprünglichen Upload-Verzeichnisses, unter anderem in Bereichen wie:

administrator/cache/
modules/
templates/

Das ist ein typisches Problem bei Webshell-Befall: Eine zunächst hochgeladene Datei kann dazu verwendet werden, weitere Kopien oder Backdoors anzulegen.

Deshalb wurde anschließend der gesamte Joomla-Dateibaum nach bekannten Mustern und den bereits gefundenen Dateinamen durchsucht.

Beispielsweise:

grep -RIl \
'DataBase_Cache_\|Nx-' \
/var/www/vhosts/DOMAIN/httpdocs \
2>/dev/null

Solche Suchmuster sind immer nur Indikatoren. Ein Treffer muss geprüft werden, bevor eine Datei entfernt wird.

Auch temporäre Verzeichnisse prüfen

Besonders interessant wurden außerdem:

/tmp
/var/tmp
/dev/shm

Dort fanden sich in diesem Fall mehrere versteckte ausführbare Dateien unter harmlos klingenden Namen.

Beispiele für solche Tarnnamen waren sinngemäß:

.dbus-session-temp-runtime
.firefox-browser-profile-cache
.libreoffice-auto-save-tmp
.nautilus-metadata-cache

Mehrere dieser Dateien waren binär identisch.

Sie lagen in einem privaten temporären Verzeichnis des Apache-Dienstes und gehörten dem Webspace-Benutzer.

Vor der Quarantäne wurde geprüft, ob sie aktuell ausgeführt oder von einem Prozess geladen wurden, beispielsweise mit:

lsof

sowie über /proc.

Zum Zeitpunkt der Untersuchung gab es dafür keine Hinweise.

Auch das ist eine wichtige sprachliche Unterscheidung:

Keine laufende Instanz gefunden

ist nicht dasselbe wie:

Diese Datei wurde niemals ausgeführt.

SSH-Schlüssel des Webspace-Benutzers

Im Home-Verzeichnis des Webspace-Benutzers fand sich außerdem ein privater SSH-Schlüssel.

Er war nicht mit einer Passphrase geschützt.

Da die Webshell mit den Rechten dieses Benutzers lief, musste davon ausgegangen werden, dass dieser private Schlüssel ausgelesen worden sein könnte.

Der Schlüssel wurde deshalb aus dem Webspace entfernt und in die Root-Quarantäne verschoben.

Das ist ein Punkt, der bei Webshell-Vorfällen leicht übersehen wird:

Nicht nur Joomla-Passwörter können betroffen sein. Alles, was der kompromittierte Benutzer lesen konnte, muss als potentiell bekannt betrachtet werden.

Zugangsdaten nach der Bereinigung ändern

Nach der Dateibereinigung wurden deshalb unter anderem folgende Zugangsdaten rotiert:

Zusätzlich wurden bestehende Joomla-Sitzungen invalidiert.

Beim Datenbankpasswort ist wichtig, dass Passwortänderung und Joomla-Konfiguration zusammenpassen. Wird nur das Datenbankkonto geändert, kann Joomla anschließend keine Verbindung mehr herstellen.

Nach der Änderung sollte deshalb sowohl eine direkte Datenbankverbindung als auch die Webseite getestet werden.

RSFiles! aktualisieren

Der entscheidende erste Schutz ist selbstverständlich die Aktualisierung von RSFiles!.

Die konkrete Upload-Schwachstelle wurde mit:

RSFiles! 1.17.12

behoben.

Bei einer späteren Bereinigung sollte jedoch nicht gezielt auf 1.17.12 aktualisiert werden, sondern auf die jeweils aktuelle vom Hersteller bereitgestellte Version.

Nach einem Update sollte außerdem geprüft werden, ob wirklich der neue Code ausgeführt wird und ob nicht alte Kopien der Erweiterung im Webroot liegen.

Frontend-Upload zusätzlich blockieren

In meinem Fall wurde der öffentliche RSFiles-Upload überhaupt nicht benötigt.

Deshalb habe ich zusätzlich auf Webserver-Ebene den öffentlichen Upload-Endpunkt gesperrt.

Die Regel wurde vor den normalen Joomla-Rewrite-Regeln in .htaccess eingefügt:

# Block public RSFiles frontend upload
RewriteCond %{REQUEST_URI} !^/administrator/ [NC]
RewriteCond %{QUERY_STRING} (^|&)option=com_rsfiles(&|$) [NC]
RewriteCond %{QUERY_STRING} (^|&)task=(rsfiles\.)?upload(&|$) [NC]
RewriteRule ^ - [F,L]

Danach wurden unter anderem folgende Varianten getestet:

task=rsfiles.upload
task=upload

und mussten mit HTTP 403 beantwortet werden.

Die normale Startseite musste gleichzeitig weiterhin HTTP 200 liefern.

Wichtig

Diese Regel ist nur sinnvoll, wenn Frontend-Uploads tatsächlich nicht benötigt werden.

Wer RSFiles! bewusst dafür einsetzt, darf den Endpunkt natürlich nicht einfach sperren.

Die Aktualisierung der Erweiterung ersetzt diese zusätzliche Schutzmaßnahme ebenfalls nicht.

Downloadverzeichnis gegen direkte Ausführung schützen

RSJoomla empfiehlt außerdem, Download- und Briefcase-Verzeichnisse zu schützen.

Je nach Serverkonfiguration wird dafür beispielsweise eine .htaccess verwendet, die direkten Zugriff verhindert.

Auf dem untersuchten System existierte im Downloadverzeichnis bereits eine entsprechende Schutzdatei.

Trotzdem war die Schwachstelle zuvor ausnutzbar gewesen.

Daraus folgt:

Ein geschützter Downloadordner ersetzt kein Sicherheitsupdate.

Mehrere Schutzschichten sind sinnvoll, aber die verwundbare Anwendung selbst muss trotzdem aktualisiert werden.

Joomla- und RSFiles-Datenbank ebenfalls prüfen

Die Untersuchung beschränkte sich nicht auf das Dateisystem.

Auch die RSFiles-Datenbank enthielt Einträge zu den hochgeladenen Dateien.

Dabei konnten verdächtige Einträge identifiziert und nach vorheriger Sicherung entfernt werden.

Wichtig ist auch hier die Trennung:

Verdächtig aussehende Zeichenketten in einer Datenbank beweisen nicht automatisch eine erfolgreiche SQL-Injection.

Sie können beispielsweise einfach Eingaben eines Angreifers sein, die eine Anwendung gespeichert hat.

Prüfen, ob noch PHP-Dateien in schreibbaren Bereichen liegen

Nach der Bereinigung wurde gezielt nach PHP-Dateien in typischerweise schreibbaren Verzeichnissen gesucht.

Besonders relevant sind beispielsweise:

images/
cache/
tmp/
downloads/

Ein möglicher Check:

find \
images cache tmp downloads \
-type f \
\( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \) \
-print

Ein leerer Treffer ist beruhigend.

Er beweist allerdings nicht mathematisch, dass ein System vollständig sauber ist.

Prozesse kontrollieren

Auch nach der Dateibereinigung sollte geprüft werden, ob noch Prozesse unter dem Webspace-Benutzer laufen, die dort nicht hingehören.

Beispielsweise:

ps aux

und gezielter:

ps -u WEBUSER -f

Außerdem lohnt sich ein Blick auf Netzwerkverbindungen und offene Ports.

Bei einer beobachteten SSH-Verbindung ist allerdings Vorsicht bei der Interpretation nötig:

Eine bestehende TCP-Verbindung auf Port 22 beweist noch keinen erfolgreichen SSH-Login.

Im konkreten Fall zeigte die anschließende Prüfung der Authentifizierungslogs lediglich fehlgeschlagene Loginversuche.

Cronjobs und Persistenz

Ein Angreifer könnte versuchen, Schadcode über Cronjobs oder andere Autostartmechanismen dauerhaft zu machen.

Deshalb wurden unter anderem geprüft:

root-Crontab
Crontab des Webspace-Benutzers
systemweite Cron-Verzeichnisse

Dort fanden sich keine offensichtlichen Hinweise auf eine zusätzliche Persistenz.

Weitere sinnvolle Prüfstellen sind:

systemd-Units und Timer
/etc/rc.local
Shell-Startdateien

Was man aus einem leeren Malware-Scan nicht ableiten darf

Nach der Bereinigung ergaben verschiedene Suchläufe keine Treffer mehr auf die bekannten Indikatoren.

Das ist wichtig – aber die Formulierung sollte korrekt bleiben.

Richtig ist:

In den untersuchten Verzeichnissen wurden keine weiteren Dateien gefunden, die den bekannten Suchmustern entsprachen.

Nicht richtig wäre:

Der Server ist damit garantiert sauber.

Insbesondere nach einer bestätigten Webshell-Kompromittierung bleibt eine Neuinstallation bzw. Migration auf ein frisches System die robusteste langfristige Lösung.

Root-Kompromittierung nicht ohne Beleg behaupten

Ein weiterer wichtiger Punkt aus diesem Vorfall:

Die Existenz einer Webshell beweist eine erfolgreiche Codeausführung im Kontext des Webservers.

Sie beweist nicht automatisch, dass ein Angreifer Root-Rechte hatte.

In meinem Fall gab es:

Es gab jedoch keinen belastbaren Beleg dafür, dass Root-Rechte erlangt wurden.

Für die Entscheidung über eine spätere Neuinstallation ist der Vorfall trotzdem ernst genug.

Meine Kurzfassung des Vorgehens

Bei einem bestätigten RSFiles-Webshell-Befall würde ich heute in ungefähr dieser Reihenfolge vorgehen:

  1. RSFiles! auf die aktuelle sichere Version bringen bzw. den verwundbaren Upload sofort unterbinden.
  2. Verdächtige Dateien nicht blind löschen, sondern zunächst dokumentieren und außerhalb des Webroots quarantänisieren.
  3. Access-Logs auf RSFiles-Upload-Requests untersuchen.
  4. Joomla-Webroot vollständig nach weiteren Backdoors durchsuchen.
  5. /tmp, /var/tmp und /dev/shm prüfen.
  6. Prozesse und Netzwerkverbindungen kontrollieren.
  7. Cronjobs und weitere Persistenzmechanismen untersuchen.
  8. Alle für den kompromittierten Webuser lesbaren Zugangsdaten als potentiell offengelegt behandeln.
  9. Joomla-Admin-, Datenbank- und Hosting-Zugangsdaten rotieren.
  10. Sitzungen invalidieren.
  11. Downloadbereiche absichern.
  12. Wenn Frontend-Upload nicht gebraucht wird, ihn zusätzlich auf Webserver-Ebene blockieren.
  13. Nach der Bereinigung erneut nach den bekannten Indikatoren suchen.
  14. Langfristig eine Migration auf ein frisches, unterstütztes System erwägen.

Fazit

Der wichtigste Punkt dieses Vorfalls war für mich, einen zunächst relativ unauffälligen Joomla-Hack nicht nur als „ein paar PHP-Dateien im Downloadordner“ zu behandeln.

Sobald eine ausführbare Webshell vorhanden war, musste davon ausgegangen werden, dass der Angreifer alle Möglichkeiten des Webspace-Benutzers hatte.

Gleichzeitig ist es wichtig, bei der Analyse nicht weiterzugehen, als die Belege tragen: Eine kompromittierte Joomla-/PHP-Umgebung ist noch kein Beweis für einen kompromittierten Root-Account.

Die Kombination aus Log-Auswertung, Dateisystemanalyse, Quarantäne, Credential-Rotation und zusätzlichem Hardening hat den konkreten Vorfall bereinigt.

Langfristig ersetzt das jedoch nicht die Überlegung, ein kompromittiertes Altsystem auf einer frischen und unterstützten Plattform neu aufzubauen.

Quellen

Die Herstellerinformation bestätigt, dass RSFiles! 1.17.12 die unauthenticated-file-upload-Schwachstelle behebt und empfiehlt ausdrücklich, Download- und Briefcase-Verzeichnisse sowie die Webserver-Logs auf verdächtige Uploads zu kontrollieren.