Adobe Campaign Classic: APSB26-120 schließt SSRF und RCE ohne Anmeldung
Adobe hat am 3. August 2026 das Bulletin APSB26-120 für Adobe Campaign Classic veröffentlicht. Eine SSRF-Lücke (CVE-2026-48331) und ein RCE-Pfad erlauben Angreifern unter Umständen, ohne Anmeldung auf interne Dienste zuzugreifen oder Code auszuführen. Betroffen ist die On-Premises-Variante ACC v7.4.3 build 9398 und früher.

Adobe hat am 3. August 2026 das Sicherheits-Bulletin APSB26-120 für Adobe Campaign Classic veröffentlicht und stuft das Update mit Priorität 1 ein. Eine ungepatchte Server-Side-Request-Forgery-Lücke (SSRF, CVE-2026-48331) erlaubt es einem nicht angemeldeten Angreifer, den Server dazu zu bringen, beliebige HTTP-Anfragen an interne oder externe Ziele auszulösen. In Kombination mit weiteren Schwachstellen im Bulletin ergibt sich daraus ein Pfad zur Ausführung von beliebigem Code auf dem ACC-Server.
Was ist passiert?
Das Bulletin APSB26-120 bündelt mehrere Schwachstellen in der On-Premises-Version von Adobe Campaign Classic. Im Mittelpunkt steht die SSRF-Lücke CVE-2026-48331, die sich laut Adobe ohne Benutzerinteraktion auslösen lässt und damit das Risiko erhöht, dass automatisierte Scans und Botnetze die Lücke finden, bevor ein Patch ausgerollt ist. Adobe stuft das Bulletin intern mit der höchsten Prioritätsstufe 1 ein, was nur für Lücken vergeben wird, von denen eine reale Gefahr für On-Premises-Installationen ausgeht.
Im Hintergrund steht eine zweite CVE, die in Sekundärquellen genannt wird und im selben Bulletin-Paket behandelt wird. Adobe schweigt sich in der öffentlichen Kurzfassung zu genauen CVSS-Werten aus, die externe Auswertung rechnet jedoch mit einem CVSS-Score im hohen Bereich. Für Administratoren zählt weniger der Einzelpunktwert als die Kombination: SSRF als Einstieg plus eine oder mehrere Folge-Lücken als Wirkung.
Wer ist betroffen?
Betroffen sind ausschließlich On-Premises-Installationen von Adobe Campaign Classic bis einschließlich Version 7.4.3 Build 9398, und zwar auf Windows- und Linux-Servern gleichermaßen. Die gehostete Adobe-Managed-Cloud-Variante ist nach Angaben von Adobe bereits abgesichert, Kunden dort müssen nichts unternehmen. Wer ACC selbst betreibt, in der Regel über ein Tomcat-Frontend mit angeschlossener Datenbank, ist selbst für das Einspielen des Patches verantwortlich.
Nicht betroffen sind Adobe Experience Platform, Adobe Real-Time CDP, Adobe Marketo Engage, Adobe Target und die übrigen Produkte der Experience Cloud. Auch ältere Campaign-Versionen unterhalb von 7.4 sind nach unserem Stand nicht betroffen, weil sie die im Bulletin beschriebene Codebasis nicht mehr enthalten.
Wie kritisch ist das?
Die SSRF-Lücke selbst ist nicht direkt eine RCE, eröffnet aber zwei relevante Folgepfade. Erstens: Ein Angreifer kann den ACC-Server dazu missbrauchen, Anfragen an interne Dienste zu stellen, die sonst nicht aus dem Internet erreichbar sind, etwa eine angebundene Datenbank, einen LDAP-Server oder eine interne Management-Oberfläche. Zweitens: In Verbindung mit einer der weiteren Schwachstellen aus APSB26-120 ergibt sich laut Adobe ein Pfad zur Ausführung von beliebigem Code. Das ist der Punkt, an dem die Priorität 1 gerechtfertigt ist.
Eine öffentliche Ausnutzung in freier Wildbahn ist uns zum Redaktionsstand 5. August 2026 nicht bekannt. Da das Bulletin aber erst seit 48 Stunden öffentlich ist und SSRF-Lücken in Unternehmenssoftware routinemäßig innerhalb von Tagen in Exploit-Kits auftauchen, ist das Zeit Fenster für eine saubere Reaktion begrenzt. Wer ACC mit Internetanschluss betreibt, sollte das Update nicht aufschieben.
Was sollten Admins jetzt tun?
- Inventur: Alle ACC-On-Premises-Server identifizieren, Build-Stand prüfen. Build 9398 oder älter ist patchpflichtig.
- Patch einspielen: Auf den vom Adobe-Support bereitgestellten korrigierten Build aktualisieren. Vorher ein vollständiges Backup der Datenbank und des Applikationsverzeichnisses anlegen.
- Externe Erreichbarkeit prüfen: Solange der Patch nicht eingespielt ist, ACC-Frontends nach Möglichkeit nicht direkt aus dem Internet erreichbar lassen. Ein vorgelagerter Reverse-Proxy mit Authentifizierung verringert die Angriffsfläche.
- Logs prüfen: HTTP-Logs und Tomcat-Zugriffslogs der letzten 30 Tage nach ungewöhnlichen Anfragen an interne Zieladressen durchsuchen, etwa 127.0.0.1, 169.254.169.254 (Cloud-Metadaten), 10.0.0.0/8 oder ungewöhnliche Hostnamen.
- EDR und SIEM: Falls Wazuh oder ein anderes SIEM im Einsatz ist, Regel auf wiederholte SSRF-Muster im Tomcat-Log aktivieren.
Einordnung für Unternehmen
Adobe Campaign Classic ist in vielen mittelständischen Unternehmen im Einsatz, oft an die Marketing- oder CRM-Abteilung angebunden, und wird nicht immer vom IT-Sicherheitsteam aktiv überwacht. Genau hier liegt das Risiko: Der ACC-Server läuft seit Jahren still vor sich hin, niemand prüft Build-Stände, und plötzlich steht eine SSRF-Lücke mit RCE-Folge im Raum. Wer Campaign hostet, sollte den Build-Stand in das reguläre Patch-Reporting aufnehmen und SSRF-Lücken grundsätzlich als priorisiert behandeln, weil sie der häufigste erste Schritt bei Cloud-nahen Angriffen sind.
Praktisch heißt das: Patch-Stichtag diese Woche, nicht im nächsten Wartungsfenster. Wer keinen On-Premises-ACC-Server betreibt, kann das Thema abhaken. Wer einen betreibt, sollte den Build-Stand heute prüfen.
Passende Anleitungen auf S-EDV
- Adobe Campaign Classic: CVE-2026-48449 mit CVSS 10.0 – vorangegangenes Bulletin APSB26-72, gleiche Software, andere CVE.
- Wazuh als SIEM mit Docker einrichten – passende Log-Quelle für SSRF-Erkennung.