FlawOpen

flawopen.com/Incidents/ahsaycbs-auth-bypass-command-injection-october-2026

● Ahsay · CVE-2026-105133 · 2026-10-07 · CVSS 10.0 · Kritisch
Sicherheitsforschung · FlawOpen

AhsayCBS: Authentifizierungsumgehung mit anschließender Befehlseinschleusung

Stand 12. Oktober 2026 meldet Huntress, dass AhsayCBS-Versionen bis 10.3.4 betroffen sind und seit dem 7. Oktober Angriffe beobachtet wurden. Ahsay erklärt nun, dass die früheren Fehlerbehebungen 10.3.4.0 und 9.15.2.59 beide Schwachstellen nicht vollständig behoben haben. Partner mit v10 sollen Hotfix 10.3.4.45, Partner mit v7 bis v9 Hotfix 9.15.2.70 installieren und anschließend neu starten. Die nur Partnern zugänglichen Hotfix-Details wurden nicht unabhängig geprüft; bestätigen Sie den installierten Build und befolgen Sie Ahsays aktuelle Anweisungen.[1], [8], [3], [4]

💡 Einfache Erklärung (ELI5)

Stellen Sie sich vor, jemand passiert die Identitätskontrolle im Backup-Raum und gibt dann dem Bediener einen Zettel. Der Receiver-Endpunkt behandelte vom Angreifer kontrollierte Eingaben als Teil eines Betriebssystembefehls. Dadurch konnte der Zettel als Anweisung statt als Daten interpretiert werden. Das Bild beschreibt die von Huntress berichtete Angriffskette; die genaue Ahsay-Implementierung ist nicht öffentlich.[1], [3], [4]

Kernkonzepte & Begriffe

CVE-2026-105133
Ein Authentifizierungsfehler mittlerer Schwere in der Funktion checkSysPwd von AhsayCBS. Huntress beschreibt ihn als ersten Schritt der beobachteten Kette.[3], [1]
CVE-2026-105134
Eine kritische Betriebssystem-Befehlseinschleusung mit CVSS 10.0 in der Replication-Receiver-API unter /rps/api/json/UpdateReceivers.do. Laut Huntress ermöglichte sie nach der Authentifizierungsumgehung Codeausführung. Der Wert 10.0 gilt nur für diese CVE.[4], [1]
Patch-Status am 12. Oktober 2026
Die CVE-Einträge führten 10.3.4 zunächst als behoben, doch Huntress stellte später fest, dass Versionen bis 10.3.4 betroffen waren. Ahsays Mitteilungen vom 10. und 12. Oktober ersetzen die Position vom 9. Oktober: Die früheren Fehlerbehebungen 10.3.4.0 und 9.15.2.59 behoben beide Schwachstellen nicht vollständig. Ahsay weist v10-Partner an, 10.3.4.45 und v7- bis v9-Partner, 9.15.2.70 zu installieren und anschließend neu zu starten. Dies sind Anbieteranweisungen; Inhalt und Wirksamkeit der Partner-Hotfixes wurden nicht unabhängig geprüft.[1], [8], [3], [4]

Framework-Zuordnungen

  • CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-78 CWE-287

Versionsstatus und Schutzmaßnahmen

Quelle der AngabenAussageMaßnahme für Betreiber
CVE-Einträge (4. Okt.)Führten Version 10.3.4 zunächst als behoben für beide CVEs.Behandeln Sie dies als strittig; bestätigen Sie die Fehlerbehebung direkt bei Ahsay, bevor Sie die Behebung abschließen.
Huntress (8. Okt.)Meldet Ausnutzung und gibt an, dass Versionen bis einschließlich 10.3.4 ebenfalls betroffen waren.Betrachten Sie Systeme bis 10.3.4 als potenziell betroffen; beschränken Sie den Verwaltungszugriff und untersuchen Sie die Systeme.
Ahsay-Versionshinweise v10.3.4 (5. Aug.)Nennen keines der beiden CVEs und keinen Sicherheitsfix für diese Fehler.Leiten Sie aus den Versionshinweisen allein nicht ab, dass 10.3.4 diese CVEs behebt.
Ahsay-Versionshinweise v10.3.2 (20. Juli)Führen ein allgemeines „Ahsay Security Patchset - 2026/Q3“ auf, nennen aber weder diese CVEs noch eine korrigierte Version.Werten Sie die allgemeine Patchset-Bezeichnung nicht als Beleg, dass diese CVEs behoben sind. Huntress meldete später, dass auch v10.3.4 betroffen ist.
Kompromittierung bei beliebiger Version vermutetDie Versionsnummer schließt frühere Ausnutzung oder Persistenz nicht aus.Untersuchen Sie den Host, sichern Sie Beweise, prüfen Sie die Backup-Integrität und nutzen Sie vertrauenswürdige Wiederherstellungsverfahren.
Ahsay-Mitteilungen (10. und 12. Okt.)Die früheren Fixes 10.3.4.0 und 9.15.2.59 behoben beide Schwachstellen nicht vollständig. Ahsay empfiehlt v10-Partnern 10.3.4.45 und v7- bis v9-Partnern 9.15.2.70 sowie einen Neustart.Befolgen Sie die versionsspezifische Anbieteranweisung, starten Sie neu und prüfen Sie den Build über den Partnerkanal; der Hotfix wurde nicht unabhängig untersucht.

Vorfall-Zeitstrahl

2026-10-04

Die CVE-Einträge zu den beiden AhsayCBS-Schwachstellen wurden veröffentlicht und nannten zunächst 10.3.4 als behoben.[3], [4]

2026-10-07 23:20:15 UTC

Huntress begann, Angriffe auf die Schwachstellen gegen exponierte Systeme zu beobachten.[1]

2026-10-08

Huntress meldete fünf betroffene Organisationen und korrigierte die frühere Versionsbewertung: Auch 10.3.4 sei verwundbar.[1]

2026-10-09

Zum Veröffentlichungszeitpunkt am 9. Oktober war keine vom Anbieter bestätigte fehlerbereinigte Version bekannt.[5]

2026-10-10

Ahsay teilte mit, dass v10.3.4.0 beide Schwachstellen nicht vollständig behob, und verwies v10-Partner auf Hotfix 10.3.4.45.[8]

2026-10-12

Ahsay aktualisierte die Anleitung: v10-Partner sollen 10.3.4.45 installieren, v7- bis v9-Partner 9.15.2.70. Starten Sie nach dem Hotfix neu.[8]

Schritt-für-Schritt Angriffsablauf

Schritt 1

Die exponierte Verwaltungsoberfläche ist erreichbar

Huntress zufolge richtete sich die beobachtete Aktivität gegen über das Internet erreichbare AhsayCBS-Weboberflächen. Das Produkt wird von Managed-Service-Anbietern und Systemintegratoren eingesetzt.[1]

Schritt 2

Die Authentifizierungsgrenze wird umgangen

Huntress führt die erste Stufe auf CVE-2026-105133 und checkSysPwd in ApiStructsAction.java zurück. Das ist die Beschreibung des Incident-Response-Teams; die geprüften Quellen veröffentlichen keinen verwundbaren Herstellerquelltext.[1], [3]

Schritt 3

Der Replication-Receiver-Fehler ermöglicht Codeausführung

Huntress verbindet CVE-2026-105134 mit Befehlseinschleusung in /rps/api/json/UpdateReceivers.do. Dem Bericht zufolge richteten Angreifer einen Receiver ein und legten JSP-Webshells im von der Anwendung ausgelieferten Verzeichnis ab. Anfrage-Syntax oder Payloads werden hier nicht wiedergegeben.[1], [4]

Schritt 4

Behandle den Host als möglicherweise kompromittiert

In betroffenen Fällen beobachtete Huntress Kindprozesse des Dienstes, Webshells, getarnte Mining-Software und Persistenz. Beschränke den Verwaltungszugriff, untersuche Host und Backups und nutze bei bestätigter Kompromittierung ein vertrauenswürdiges Wiederherstellungsverfahren.[1], [6]

Quellcode: Verwundbar vs. Sicher

Das sichere Beispiel verwendet eine feste ausführbare Datei, eine explizite Positivliste und getrennte ProcessBuilder-Argumente; es startet keine Shell und fügt Benutzereingaben nicht in eine Befehlszeichenfolge ein. Dies ist ein allgemeines Verteidigungsmuster, das zeigt, wie die Interpretationsgrenze für Betriebssystembefehle geschlossen wird, nicht Ahsay-Quellcode oder dessen Patch. Die geprüften öffentlichen Quellen legen Implementierung und Korrektur des Anbieters nicht offen.[1], [3], [4]

VERWUNDBARE IMPLEMENTIERUNG
// Nur ein allgemeines Anti-Muster, kein Ahsay-Quellcode.
void updateReceiver(Request request) {
    String receiver = request.parameter("receiver");
    String command = commandBuilder.forReceiverUpdate(receiver);
    operatingSystem.execute(command); // unsafe command-string boundary
}
GEHÄRTETER SICHERHEITS-PATCH
// Nur ein allgemeiner Verteidigungsentwurf, kein Ahsay-Patch.
private static final Set<String> ALLOWED_RECEIVERS = Set.of("primary", "archive");

void updateReceiver(Principal principal, ReceiverInput input) throws IOException {
    authorization.require(principal, Permission.MANAGE_RECEIVERS);
    String receiver = input.receiverId();
    if (!ALLOWED_RECEIVERS.contains(receiver)) {
        throw new IllegalArgumentException("Unsupported receiver");
    }
    new ProcessBuilder("/usr/local/bin/replication-tool", "update", "--receiver", receiver)
        .start(); // fixed executable; separate arguments; no shell
}

Checkliste für Engineering & Systemsicherheit

Quellen