Joomla JCE CVE-2026-48907 — PoC-Validierung, Webshell-Artefakte und SOC-Erkennung

Defensiver Validierungsbericht und SOC-orientierte Erkennungshinweise für CVE-2026-48907, das den Joomla Content Editor (JCE) bis Version 2.9.99.4 betrifft.

Zweck des Repositorys

Dieses Repository dokumentiert eine kontrollierte Laborvalidierung von CVE-2026-48907 in Joomla JCE und konzentriert sich auf praktische Erkennungsentwicklung für SOC-Teams.

Das Ziel ist nicht, eine Anleitung zur Ausnutzung zu geben. Ziel ist es zu zeigen, welche Telemetriequellen bei der Validierung nützlich waren, welche Artefakte erstellt wurden und wie Verteidiger diese Aktivität erkennen und darauf reagieren können.

Berichte

• Englischer PDF-Bericht
• Polnischer PDF-Bericht
• Englischer DOCX-Bericht
• Polnischer DOCX-Bericht

Zusammenfassung

Öffentliche Referenzen

• Öffentliches PoC-Repository: JoomlaSniper
• CVE-Eintrag: CVE-2026-48907
• NVD: CVE-2026-48907
• CISA KEV-Katalog: Katalog bekannter ausgenutzter Schwachstellen

Laborumgebung

Beweisscreenshots

Joomla-Lab-Seite

Installierte verwundbare JCE-Version

Joomla zeigt ein verfügbares JCE-Update an

PoC-Validierungsergebnis im Labor

Interaktive Shell und Befehlsausführung als www-data

Dateiartefakte im Joomla-tmp-Verzeichnis

Wichtige defensive Beobachtung

Ein wichtiger betrieblicher Befund ist, dass Joomla-Anwendungsprotokolle nicht ausreichten.

Während des Labortests zeichneten Joomla-Protokolle anwendungsspezifischen Kontext auf, wie z. B. ein joomlafailure-Ereignis, aber sie zeigten nicht die vollständige Ausnutzungskette. Die nützliche Kette war hauptsächlich sichtbar in:

1. Apache access.log
2. Apache/PHP error.log
3. auditd execve-Aufzeichnungen
4. Dateisystemartefakte in joomla_html/tmp

Für das SOC-Monitoring sollten Joomla-Protokolle als unterstützende Telemetrie behandelt werden, nicht als primäre Erkennungsquelle für diese Sicherheitslücke.

Beobachtete Angriffskette

Auf hoher Ebene beobachtete Kette während des kontrollierten Tests:

JCE version discovery
    ↓
POST to Joomla JCE component
    ↓
PHP webshell written to Joomla /tmp
    ↓
HTTP request to /tmp/jce*.xml.php
    ↓
Command execution through webshell
    ↓
auditd confirms /usr/bin/dash and commands executed as www-data

Beobachtete HTTP-Sequenz

Die deutlichsten Beweise fanden sich in Apache access.log:

GET  /plugins/editors/jce/jce.xml
GET  /
POST /index.php?option=com_jce
GET  /tmp/jceolxtshs3.xml.php
GET  /plugins/editors/jce/jce.xml
POST /index.php?option=com_jce
GET  /tmp/jce624jdcfx.xml.php
GET  /tmp/jce624jdcfx.xml.php?c=id%20%26%26%20hostname%20%26%26%20pwd
GET  /tmp/jce624jdcfx.xml.php?c=whoami
GET  /tmp/jce624jdcfx.xml.php?c=hostname
GET  /tmp/jce624jdcfx.xml.php?c=id
GET  /tmp/jce624jdcfx.xml.php?c=pwd

Apache/PHP-Fehlerprotokollindikatoren

Das Apache/PHP-Fehlerprotokoll enthielt wertvolle parserbezogene Spuren:

simplexml_load_string()
administrator/components/com_jce/helpers/profiles.php
RXST
RXEND

Die Markierungen RXST und RXEND waren besonders nützliche Indikatoren für diese spezifische PoC-Familie, da sie im Payload-Handling-Pfad auftauchten.

Einschränkung der Joomla-Protokolle

Joomla-Protokolle bestätigten, dass das Anwendungslogging aktiv war, aber sie rekonstruierten die Ausnutzung nicht:

#Software: Joomla! 5.4.6 Stable [ Kutegemea ] 26-May-2026 16:00 GMT
#Fields: datetime priority clientip category message
2026-06-18T20:37:57+00:00 INFO 172.20.10.2 joomlafailure Username and password do not match or you do not have an account yet.

Das bedeutet, dass die alleinige Erfassung von Joomla-Protokollen möglicherweise die wichtigsten Beweise für die Ausnutzung von CVE-2026-48907 übersieht.

Dateisystemartefakte

Der Test erstellte PHP-Webshell-Dateien im Joomla tmp:

/var/www/html/tmp/jce624jdcfx.xml.php
/var/www/html/tmp/jceolxtshs3.xml.php

Hostseitige Pfade im Labor:

/home/user/joomla-jce-lab/joomla_html/tmp/jce624jdcfx.xml.php
/home/user/joomla-jce-lab/joomla_html/tmp/jceolxtshs3.xml.php

Beobachtete SHA256-Hashes:

b6fa303daef8aa8cb39566c73d2cb4a458efb2b1fba48052dd039d45c3beb0aa  jce624jdcfx.xml.php
f8bcc802ab56b845c968ed6727228f200f8f4bcd332b8ce82c6980d93ac228fd  jceolxtshs3.xml.php

Hash-basierte Erkennung sollte als wenig belastbar betrachtet werden, da Dateinamen und Payloads variieren können. Pfad, Erweiterung, Eigentümer und Verhaltenskorrelation sind nützlicher.

auditd-Beweise

auditd bestätigte, dass der Webserver-Benutzer Befehle aus dem Joomla-Verzeichnis tmp ausführte:

CWD=/var/www/html/tmp uid=www-data comm=sh exe=/usr/bin/dash
CWD=/var/www/html/tmp uid=www-data comm=id exe=/usr/bin/id
CWD=/var/www/html/tmp uid=www-data comm=hostname exe=/usr/bin/hostname
CWD=/var/www/html/tmp uid=www-data comm=whoami exe=/usr/bin/whoami

Dies ist die stärkste Bestätigung, dass es sich bei der Aktivität nicht nur um Scans, sondern um tatsächliche Remote-Codeausführung handelte.

Erkennungslogik

Die stärkste Erkennung ist korrelationsbasiert:

GET /plugins/editors/jce/jce.xml
    followed by
POST /index.php?option=com_jce
    followed by
GET /tmp/jce*.xml.php
    followed by
GET /tmp/jce*.xml.php?c=
    and/or
auditd: www-data executes /usr/bin/dash from /var/www/html/tmp

Erkennungspriorität

Indikatoren und Jagdmuster

HTTP-Muster

/plugins/editors/jce/jce.xml
/index.php?option=com_jce
/tmp/jce[a-z0-9]{8}\.xml\.php
/tmp/.*\.(php|phtml|phar)(\?| )
cs-uri-query contains "c="

Dateisystemmuster

joomla_html/tmp/jce*.xml.php
/var/www/html/tmp/jce*.xml.php
RXST
RXEND
shell_exec
system
passthru
exec
$_GET['c']

Beispielhafte Triage-Befehle

Verwenden Sie diese nur auf Systemen, die Ihnen gehören oder für deren Untersuchung Sie autorisiert sind.

grep -RniE "com_jce|profiles\.import|task=profiles|/tmp/.*\.php|RXST|RXEND" apache_logs joomla_html/administrator/logs 2>/dev/null

find ./joomla_html/tmp ./joomla_html/images ./joomla_html/media \
  -type f \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.phar" -o -iname "*.xml.php" \) -ls

sudo ausearch -k wwwdata_exec -i | grep -E "uid=www-data|comm=sh|/usr/bin/dash|/var/www/html/tmp|whoami|hostname| id |pwd"

Sigma-Regeln

Separate Sigma-Regeldateien sind in rules/sigma verfügbar:

• joomla_jce_webshell_tmp_access.yml
• joomla_jce_component_exploit_attempt.yml
• web_user_shell_from_joomla_tmp_auditd.yml

Empfohlene Reaktion

Empfehlungen zur Eindämmung

Beispielhafte Apache-Härtungsrichtlinie

Die genaue Konfiguration hängt vom Apache/PHP-Bereitstellungsmodell ab. Ziel ist es, die PHP-Ausführung in Verzeichnissen zu verhindern, die niemals Skripte ausführen sollten.

<Directory "/var/www/html/tmp">
    php_admin_flag engine off
    Options -ExecCGI
    RemoveHandler .php .phtml .phar
    <FilesMatch "\.(php|phtml|phar)$">
        Require all denied
    </FilesMatch>
</Directory>

<Directory "/var/www/html/images">
    php_admin_flag engine off
    Options -ExecCGI
    RemoveHandler .php .phtml .phar
    <FilesMatch "\.(php|phtml|phar)$">
        Require all denied
    </FilesMatch>
</Directory>

MITRE ATT&CK-Zuordnung

Risikobewertung

Das Labor bestätigte die praktische Ausnutzung von JCE 2.9.99.4. Eine Authentifizierung gegenüber Joomla war im beobachteten Ablauf nicht erforderlich, und der öffentliche PoC automatisierte die Versionserkennung und die Webshell-Erstellung.

Für reale Umgebungen ist das Risiko hoch bis kritisch, wenn Joomla internetfähig oder von weniger vertrauenswürdigen internen Netzwerken aus erreichbar ist. Ein erfolgreicher Angriff kann eine persistente Webshell hinterlassen, sodass das Patchen ohne Artefaktüberprüfung nach einem mutmaßlichen Vorfall nicht ausreicht.

Haftungsausschluss

Dieses Repository ist für defensive Forschung, SOC-Erkennungsentwicklung und Schwachstellenmanagement gedacht. Es enthält keinen Exploit-Code. Tests dürfen nur auf Systemen durchgeführt werden, die Ihnen gehören oder für deren Bewertung Sie ausdrücklich autorisiert sind.