CVE-2026-48282-coldfusion-rds-detection

Laborvalidierung von CVE-2026-48282 in Adobe ColdFusion RDS mit beliebigem CFM-Dateischreiben, Codeausführung, auditd/PCAP-Beweisen, Ereigniszeitlinienrekonstruktion und SOC-Erkennungsempfehlungen. Enthält englische und polnische Berichte.

Beide Berichte enthalten die vollständige Testmethodik, Beweisauszüge, Zeitleiste, Prozesskette, Netzwerkindikatoren, Minderungsempfehlungen, Prüfungsempfehlungen und beispielhafte SIEM-Logik.

Repository-Struktur

Es sind kein Exploit-Quellcode, Payload-Quellcode, CFM-Payload, Roh-PCAP oder rohes Host-Beweispaket enthalten.

Testumgebung

Das ColdFusion-Anwendungsverzeichnis /app wurde vom Ubuntu-Host-Pfad /home/user/coldfusion-u9/app als Docker-Bind-Mount eingebunden.

Was validiert wurde

Der Test wurde in einer isolierten und autorisierten Laborumgebung durchgeführt. Die Validierung umfasste die folgende Sequenz:

1. Adobe ColdFusion 2025 Update 9 wurde in Docker bereitgestellt.
2. RDS wurde für den Labortest aktiviert, wobei der Authentifizierungsmodus auf Keine Authentifizierung erforderlich gesetzt wurde.
3. Das in Referenzen aufgeführte öffentliche Projekt wurde verwendet, um zu bestätigen, dass der RDS-Endpunkt erreichbar war und die getestete Instanz anfällig erschien.
4. Ein laborinterner Uploader wurde verwendet, um eine CFM-Datei über die RDS FILEIO-Operation an /app/connect.cfm zu übermitteln.
5. Die Datei wurde über GET /connect.cfm aufgerufen.
6. ColdFusion startete über den Java-Prozessausführungspfad /bin/bash.
7. Die Shell stellte eine ausgehende TCP-Verbindung zur Windows-Workstation her.
8. Es wurden nicht-destruktive Erkennungsbefehle ausgeführt, um den effektiven Benutzer, das Betriebssystem und das Arbeitsverzeichnis zu bestätigen.
9. Beweise von Angreifer- und Opfersystemen wurden in einer einzigen UTC-Zeitleiste korreliert.

Die Berichte dokumentieren absichtlich die Beweise und die Erkennungslogik, ohne den benutzerdefinierten Uploader oder die Payload-Implementierung zu verteilen.

Bestätigtes Ergebnis

Der Labortest bestätigte:

• beliebiges CFM-Dateischreiben über den RDS FILEIO-Endpunkt in der getesteten Konfiguration;
• Ausführung der geschriebenen CFM-Datei durch ColdFusion nach einer HTTP-Anfrage;
• Erstellung der Prozesskette:

• eine ausgehende Shell-Verbindung vom ColdFusion-Container zum Windows-Host;
• Ausführung im Kontext des ColdFusion-Dienstbenutzers, nicht als root.

Im Container war die effektive Identität:

Auf dem Ubuntu-Host wurde UID 999 mithilfe der Host-Kontendatenbank als dnsmasq aufgelöst, was den abweichenden Benutzernamen in Host-Ebene-auditd-Aufzeichnungen und Dateieigentumsausgaben erklärt.

Wichtige Beweise

RDS-Konfiguration

Die für den Test verwendete administrative Konfiguration ist unten dargestellt. Die Option Keine Authentifizierung erforderlich wurde nur für die kontrollierte Laborvalidierung aktiviert.

Erste Schwachstellenprüfung

Die erste Prüfung bestätigte, dass der RDS-Endpunkt erreichbar war und ein beliebiges Dateilesen/-schreiben durch Pfad-Traversal gemeldet wurde.

CFM-Dateischreiben

Der Labor-Uploader übermittelte das lokale CFM-Testartefakt an /app/connect.cfm. Der Server gab die RDS-Antwort 1:2:XX zurück, und die geschriebene Ressource war anschließend über HTTP erreichbar.

Codeausführung und Dienstkonto-Kontext

Die resultierende Shell-Sitzung bestätigte die Ausführung als ColdFusion-Dienstkonto. Die im Screenshot gezeigten Befehle waren auf die Identifikation der Umgebung beschränkt.

Datei auf dem Ubuntu-Bind-Mount

Die Datei erschien in /home/user/coldfusion-u9/app, dem Host-Pfad, der als /app in den Container eingebunden wurde.

Rekonstruierte Zeitleiste

Die vollständige Zeitleiste ist in beiden PDF-Berichten verfügbar. Die wichtigsten Ereignisse waren:

Methodik der Beweiserhebung

Linux und Docker

Der Opfer-Host sammelte:

• auditd-Ereignisse für execve, execveat und connect, bei denen die effektive UID 999 war;
• Überwachungen auf das ColdFusion-Webroot und das Protokollverzeichnis;
• tcpdump-Verkehr für die HTTP- und Callback-Ports;
• periodische Prozess- und Socket-Snapshots;
• Docker-Container-Metadaten, Protokolle, Ereignisse, Prozesslisten und Dateisystemunterschiede;
• ColdFusion-Anwendungs- und Administrationsprotokolle;
• SHA-256-Hashes und Metadaten-Baselines.

Der endgültige auditd-Status meldete lost=0, was darauf hinweist, dass das Kernel-Audit-Subsystem während des erfassten Testfensters keine verlorenen Ereignisse meldete.

Windows

Die Erfassung auf der Angreifer-Workstation wurde absichtlich auf berichtsrelevante Artefakte beschränkt:

• Betriebssystem- und Netzwerkdetails;
• Ereignis-ID 4688 Prozesserstellungsaufzeichnungen;
• Prozesse im Zusammenhang mit Python und Ncat;
• relevante TCP-Verbindungsdaten;
• Hashes der Labordateien;
• Microsoft Defender-Status und Erkennungen;
• Tool-Versionen.

Wichtigste Erkennungsmöglichkeiten

1. RDS FILEIO-Anfrage

Überwachen Sie HTTP-, Reverse-Proxy-, WAF- oder Netzwerktelemetrie auf folgende Kombination:

Die Kombination ist deutlich stärker als jeder einzelne Indikator für sich.

2. Dateischreiben gefolgt von Ausführung

Korrelieren Sie:

1. eine FILEIO WRITE-Anfrage an eine serverausführbare Erweiterung;
2. eine nachfolgende GET-Anfrage an die neu geschriebene Ressource;
3. einen neuen Kindprozess von ColdFusion Java oder jspawnhelper innerhalb eines kurzen Zeitfensters.

3. Verdächtiger ColdFusion-Kindprozess

Hochwertige Prozessindikatoren umfassen:

Zusätzliche Kommandozeilenindikatoren umfassen /dev/tcp, interaktive Shell-Flags, Umleitungsoperatoren, codierte Befehle und unerwartete Verwendung von cfexecute.

4. Ausgehende Verbindung vom Anwendungsdienstkonto

Alarmieren Sie, wenn eine von ColdFusion gestartete Shell oder ein Interpreter eine ausgehende Verbindung zu einer Workstation oder einem ungewöhnlichen Zielport initiiert. Das Laborereignis verwendete TCP-Port 4444, aber die Erkennung in der Produktion sollte nicht von einem einzelnen Port abhängen.

5. RDS-Konfigurationsänderungen

Überwachen Sie ColdFusion-Administrationsprotokolle auf Nachrichten mit folgendem Inhalt:

Jede RDS-Konfigurationsänderung in der Produktion sollte überprüft werden, insbesondere wenn die Authentifizierung abgeschwächt oder der Dienst aus zusätzlichen Netzwerken erreichbar wird.

6. Dateiüberwachung im Anwendungsverzeichnis

Der Test identifizierte eine wichtige Einschränkung der Container-Überwachung: /app war ein Bind-Mount. docker diff zeigte /app an, bot jedoch keine vollständige Transparenz über einzelne Dateien, die innerhalb des host-gemounteten Verzeichnisses erstellt wurden.

Die Überwachung der Dateiintegrität, auditd, eBPF oder EDR-Abdeckung sollte daher den echten Host-Pfad überwachen, der den Mount unterstützt, zum Beispiel:

Die ausschließliche Überwachung des Container-Overlays oder von /opt/coldfusion/cfusion/wwwroot hätte die vollständigen Dateierstellungsbeweise für diesen Test nicht erfasst.

SOC-Triage-Anleitung

Wenn der HTTP-Indikator erkannt wird, sollte das SOC sofort Folgendes korrelieren:

• die Quell-IP und den User-Agent;
• die RDS-Authentifizierungs- und -Expositionskonfiguration;
• den im FILEIO-Körper enthaltenen Zielpfad;
• neue oder geänderte .cfm-, .cfc-, .jsp- oder Archivdateien;
• HTTP-Zugriff auf dieselbe Datei kurz nach der Erstellung;
• ColdFusion Java-Kindprozesse;
• ausgehende Verbindungen vom Dienstkonto;
• nachfolgende Erkennungsbefehle wie whoami, id, uname, hostname, pwd, ip, ifconfig, netstat oder ss;
• Persistenzversuche, Zugriff auf Anmeldeinformationen oder laterale Bewegungen nach der ersten Prozessausführung.

Eine einzelne GET-Anfrage an eine CFM-Datei reicht allein nicht aus. Der stärkste Alarm kombiniert Dateischreib-, Dateizugriffs-, Prozesserstellungs- und Netzwerkverbindungstelemetrie innerhalb desselben kurzen Zeitfensters.

Empfohlene Maßnahmen

1. Wenden Sie das in APSB26-68 referenzierte Adobe ColdFusion-Sicherheitsupdate an.
2. Deaktivieren Sie RDS, wenn es betrieblich nicht erforderlich ist.
3. Wenn RDS aktiviert bleiben muss, erzwingen Sie die Authentifizierung und beschränken Sie den Zugriff auf explizit autorisierte administrative Systeme.
4. Verhindern Sie, dass RDS- und CFIDE-Administrationsendpunkte ungeschützten Netzwerken ausgesetzt werden.
5. Überwachen und beschränken Sie Schreibzugriffe auf Verzeichnisse, aus denen ColdFusion serverseitige Inhalte ausführen kann.
6. Beschränken Sie die Fähigkeit des ColdFusion-Dienstkontos, Betriebssystemprozesse zu starten, wenn dies für die geschäftliche Funktionalität nicht erforderlich ist.
7. Überwachen Sie die Host-Pfade hinter Docker-Bind-Mounts, nicht nur das Container-Overlay-Dateisystem.
8. Überprüfen Sie die Umgebung auf unerwartete CFM-/CFC-/JSP-Dateien und von ColdFusion gestartete Shells.

Umfang und Einschränkungen

• Die Validierung wurde an einer einzigen ColdFusion 2025 Update 9 Docker-Instanz durchgeführt.
• RDS wurde für den kontrollierten Test absichtlich auf Keine Authentifizierung erforderlich konfiguriert.
• Die beobachtete Auswirkung war eine Codeausführung als ColdFusion-Dienstkonto; es wurde keine Privilegienausweitung zu root beobachtet.
• Das Ergebnis bestätigt den getesteten Pfad und die getestete Konfiguration. Es beweist nicht, dass sich jede Bereitstellung, jeder Authentifizierungsmodus, jeder Reverse-Proxy oder jedes Betriebssystem identisch verhält.
• Roh-Exploit-Code, der benutzerdefinierte Uploader und die CFM-Payload werden in diesem Repository nicht verteilt.
• Die Berichte enthalten ausgewählte Beweisauszüge anstelle vollständiger Rohdaten, um das Material lesbar und auf die Erkennung fokussiert zu halten.

Referenzen

• Adobe Security Bulletin APSB26-68
• NVD — CVE-2026-48282
• CVE.org — CVE-2026-48282
• Öffentliches Projekt, das als erste Validierungsreferenz verwendet wurde

Hinweis zur verantwortungsvollen Nutzung

Dieses Material wird für defensive Sicherheitsforschung, Schwachstellenmanagement, Erkennungsentwicklung, Incident-Response-Vorbereitung und autorisierte Tests bereitgestellt. Verwenden Sie es nicht gegen Systeme ohne ausdrückliche Genehmigung.