Anmerkung der Redaktion: Dieser Artikel wurde aktualisiert, um neue vom Anbieter veröffentlichte Informationen zu berücksichtigen.
Eine kritische Schwachstelle in der AI-Bolit-Komponente von Imunify360, ImunifyAV+ und ImunifyAV wurde kürzlich offengelegt und vom Anbieter behoben, wobei der Fix automatisch auf die große Mehrheit der Server ausgerollt wurde.
Der Fehler, der in Versionen vor 32.7.4-1 vorhanden war, ermöglichte aufgrund unsicherer Deobfuskierungslogik die Ausführung von Code aus der Ferne (RCE) während der Malware-Scans.
Laut dem Sicherheitsbulletin des Anbieters gibt es keine Hinweise auf eine aktive Ausnutzung und keine Kundenmeldungen über verdächtige Aktivitäten.
Wie Angreifer Imunify360 zur Ausführung von Systembefehlen nutzen
Vor der Behebung der Schwachstelle konnten Angreifer potenziell bösartige Payloads erstellen, die eine unbeabsichtigte Codeausführung innerhalb des AI-Bolit-Scanprozesses auslösten.
Da der Scanner vom Benutzer bereitgestellte Dateien und Datenbankinhalte analysiert – darunter obfuskiertes PHP, JavaScript und HTML –, konnte ein Angreifer Zeichenfolgen einbetten, die internen Deobfuskierungsmustern entsprachen.
Diese Zeichenfolgen wurden in Kontexten verarbeitet, in denen der Scanner möglicherweise mit erweiterten Berechtigungen lief, wodurch potenziell beliebige PHP-Funktionsaufrufe möglich waren.
In Umgebungen, in denen der Scanner mit Root-Zugriff betrieben wurde, hätte dies theoretisch zur vollständigen Übernahme des Systems führen können.
Obwohl eine solche Ausnutzung bislang nicht in freier Wildbahn beobachtet wurde, verdeutlicht die Schwachstelle die besonderen Risiken von Scan-Engines, die sowohl nicht vertrauenswürdige Eingaben verarbeiten als auch in privilegierten Kontexten betrieben werden.
Ursache: Unsichere Deobfuskierungslogik
Die Schwachstelle hatte ihren Ursprung in den Deobfuskierungsroutinen von AI-Bolit, insbesondere in Funktionen wie deobfuscateDeltaOrd und deobfuscateEvalHexFunc.
Diese Funktionen extrahierten Daten aus den gescannten Dateien und übergaben sie direkt an Helpers::executeWrapper(), einen Wrapper um call_user_func_array().
Da die extrahierten Zeichenfolgen nicht validiert oder auf sichere Funktionen beschränkt wurden, konnten Angreifer bösartige Funktionsnamen einbetten, die später während des Scans ausgeführt wurden.
Sowohl die Pfade für Datei- als auch für Datenbankscans waren betroffen. Der Patch vom 23. Oktober 2025 behob das Problem durch die Implementierung einer strikten Positivliste zulässiger Funktionen, sodass nicht vertrauenswürdige Werte gar nicht erst zur Ausführung gelangten.
Verdeckte Payloads erschweren die Erkennung
Da AI-Bolit für die Verarbeitung stark obfuskierten Inhalts ausgelegt ist, hätte sich eine bösartige Nutzung dieser Schwachstelle nur schwer erkennen lassen.
Angreifer konnten Techniken wie Hex-Kodierung, Delta-/Ord-Transformationen, verschachtelte Base64-Ketten oder komprimierte Payloads einsetzen – Formate, die der Scanner absichtlich zu dekodieren versucht.
Durch diese komplexen Kodierungen können bösartige Funktionszeichenfolgen verborgen bleiben, bis die anfällige Deobfuskierungslogik sie verarbeitet.
Obwohl keine Ausnutzung gemeldet wurde, unterstreicht die Art der Schwachstelle, wie schwierig eine forensische Identifizierung ohne zuverlässige Überwachungs- und Auditkontrollen für Sicherheits-Tools gewesen wäre.
So sichern Sie Ihre Umgebung gegen RCE in Imunify360 ab
Angesichts der jüngsten Imunify360-AV-Schwachstelle sollten Organisationen sofort Maßnahmen ergreifen, um ihre Hosting-Umgebungen abzusichern und das Ausnutzungsrisiko zu senken.
- Installieren Sie umgehend die Imunify360-AV-Updates (v32.7.4.0 oder höher) und überprüfen Sie die Serverintegrität, insbesondere bei Systemen, die seit Ende Oktober 2024 nicht vertrauenswürdige Dateien verarbeitet haben.
- Führen Sie den AI-Bolit-Scanner in einer streng isolierten Umgebung (Container/VM) mit minimalen Berechtigungen, ohne Netzwerkzugriff und mit eingeschränkter Sichtbarkeit des Dateisystems aus.
- Verringern Sie die Risiken durch Berechtigungen durch strikte Benutzertrennung und verpflichtende Zugriffskontrollen (MAC), um zu verhindern, dass der Scanner oder kompromittierte Prozesse nicht autorisierte Befehle ausführen oder kritische Systembereiche verändern.
- Härten Sie Ausführungspfade und temporäre Verzeichnisse durch Deaktivieren der tiefgehenden Deobfuskierung, wo möglich, und hängen Sie /tmp und ähnliche Verzeichnisse mit noexec/nosuid/nodev ein.
- Überwachen Sie ungewöhnliches Verhalten des Scanners und führen Sie rückblickendes Threat Hunting durch, einschließlich der Suche nach unerwarteten Prozessen, verdächtigen Artefakten in temporären Verzeichnissen, veränderten PHP-Dateien oder Persistenzmechanismen.
- Überprüfen und verschärfen Sie die Berechtigungsgrenzen zwischen Website-Benutzern, Hosting-Umgebungen und Scandiensten und setzen Sie Netzwerksegmentierung ein, um laterale Bewegungen oder eine Rechteausweitung aus gemeinsam genutzten Hosting-Umgebungen zu verhindern.
- Implementieren Sie umfassendere Erkennungs- und Telemetrie-Kontrollen, darunter die Überwachung der Dateiintegrität (FIM), die Überprüfung der WAF-Telemetrie sowie eine erweiterte Protokollierung von Scanprotokollen und ausgeführten Befehlen.
Durch die Umsetzung dieser Gegenmaßnahmen können Organisationen die durch diese Imunify360-Schwachstelle geschaffene Angriffsfläche verringern und ihre allgemeine Widerstandsfähigkeit stärken.
Diese Schwachstelle zeigt die Gefahren der Ausführung nicht vertrauenswürdiger Inhalte während der Malware-Analyse, insbesondere innerhalb von Diensten mit hohen Berechtigungen.
Die weite Verbreitung von Imunify360 in gemeinsam genutzten Hosting-Umgebungen verstärkt das Risiko und macht schnelles Patchen und Eindämmung unverzichtbar.
Solche Schwachstellen unterstreichen die Notwendigkeit von Zero-Trust-Prinzipien, die Verifizierung und Kontrolle in den Mittelpunkt stellen.