FlawOpen

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

● Ahsay · CVE-2026-105133 · 2026-10-07 · CVSS 10.0 · Critique
Recherche · FlawOpen

AhsayCBS : contournement d’authentification suivi d’une injection de commandes

Au 12 octobre 2026, Huntress indique que les versions d’AhsayCBS jusqu’à la 10.3.4 sont vulnérables et avoir observé des attaques depuis le 7 octobre. Ahsay précise désormais que les correctifs antérieurs 10.3.4.0 et 9.15.2.59 ne traitaient pas complètement les deux failles ; l’éditeur demande aux partenaires v10 d’appliquer le hotfix 10.3.4.45 et aux partenaires v7 à v9 le 9.15.2.70, puis de redémarrer. Les détails des hotfixes réservés aux partenaires n’ont pas été vérifiés indépendamment ; confirmez la version installée et suivez les instructions actuelles d’Ahsay.[1], [8], [3], [4]

💡 Explication en Langage Simple (ELI5)

Imaginez qu’un visiteur franchisse le contrôle d’identité de la salle de sauvegarde, puis remette une note à l’opérateur. Le point de terminaison de réception a traité une donnée contrôlée par l’attaquant comme une partie d’une commande du système d’exploitation : la note pouvait donc être interprétée comme une instruction plutôt que comme une donnée. Cette analogie décrit la chaîne rapportée par Huntress ; l’implémentation exacte d’Ahsay n’est pas publique.[1], [3], [4]

Concepts Clés et Termes

CVE-2026-105133
Défaut d’authentification de gravité moyenne signalé dans la fonction checkSysPwd d’AhsayCBS. Huntress le décrit comme la première étape de la chaîne observée.[3], [1]
CVE-2026-105134
Injection de commandes du système d’exploitation critique, CVSS 10.0, signalée dans l’API Replication Receiver à /rps/api/json/UpdateReceivers.do. Selon Huntress, elle a permis l’exécution de code après le contournement d’authentification. Le score 10.0 concerne cette CVE, pas les deux failles.[4], [1]
État des correctifs au 12 octobre 2026
Les fiches CVE indiquaient initialement que la 10.3.4 corrigeait les failles, mais Huntress a ensuite trouvé des versions vulnérables jusqu’à la 10.3.4. Les annonces d’Ahsay des 10 et 12 octobre remplacent sa position du 9 octobre : les correctifs 10.3.4.0 et 9.15.2.59 ne traitaient pas complètement les deux failles. Ahsay demande aux partenaires v10 d’utiliser la 10.3.4.45 et aux partenaires v7 à v9 la 9.15.2.70, puis de redémarrer. Il s’agit des consignes du fournisseur ; le contenu et l’efficacité des hotfixes réservés aux partenaires n’ont pas été vérifiés indépendamment.[1], [8], [3], [4]

Correspondances de référentiels

  • Référence CWE pour la faiblesse décrite dans ce guide : CWE-78 CWE-287

État des versions et mesures défensives

Source des élémentsCe qu’elle indiqueDécision opérationnelle
Fiches CVE (4 oct.)Indiquaient initialement que la version 10.3.4 corrigeait les deux CVE.Considérez cette information comme contestée ; confirmez le correctif directement auprès d’Ahsay avant de clore la remédiation.
Huntress (8 oct.)Signale des exploitations et indique que les versions jusqu’à 10.3.4 étaient également touchées.Considérez les systèmes jusqu’à 10.3.4 comme potentiellement vulnérables ; restreignez l’accès de gestion et enquêtez.
Notes de version Ahsay v10.3.4 (5 août)Ne mentionnent ni l’un ni l’autre CVE, ni de correctif de sécurité pour ces failles.Ne déduisez pas des seules notes de version que la 10.3.4 corrige ces CVE.
Notes Ahsay v10.3.2 (20 juil.)Indiquent un « Ahsay Security Patchset - 2026/Q3 » générique, sans identifier ces CVE ni une version corrigée.Ne considérez pas ce nom générique comme la preuve que ces CVE sont corrigés. Huntress a ensuite indiqué que la v10.3.4 était également touchée.
Compromission suspectée, quelle que soit la versionLe numéro de version n’exclut ni une exploitation antérieure ni une persistance.Enquêtez sur l’hôte, préservez les preuves, évaluez l’intégrité des sauvegardes et suivez une procédure de reprise fiable.
Annonces d’Ahsay (10 et 12 oct.)Les correctifs 10.3.4.0 et 9.15.2.59 ne traitaient pas complètement les deux failles. Ahsay demande aux partenaires v10 la 10.3.4.45 et aux partenaires v7 à v9 la 9.15.2.70, puis un redémarrage.Suivez la consigne correspondant à votre version, redémarrez et vérifiez la version installée via le canal partenaire ; le hotfix n’a pas été examiné indépendamment.

Chronologie de l'Incident

2026-10-04

Publication des fiches CVE des deux failles AhsayCBS ; elles indiquaient initialement que la version 10.3.4 était corrigée.[3], [4]

2026-10-07 23:20:15 UTC

Huntress commence à observer l’exploitation des failles contre des systèmes exposés.[1]

2026-10-08

Huntress signale cinq organisations ciblées et corrige son évaluation précédente : la version 10.3.4 est également touchée.[1]

2026-10-09

À la date de publication, le 9 octobre, aucune version corrigée confirmée par le fournisseur n’avait été identifiée.[5]

2026-10-10

Ahsay a annoncé que la v10.3.4.0 ne traitait pas complètement les deux failles et a indiqué aux partenaires v10 le hotfix 10.3.4.45.[8]

2026-10-12

Ahsay a mis à jour ses consignes : les partenaires v10 doivent appliquer la 10.3.4.45 ; ceux des v7 à v9, la 9.15.2.70. Redémarrez après chaque hotfix.[8]

Déroulement de l'Attaque Étape par Étape

Étape 1

L’interface d’administration exposée est accessible

Huntress indique que l’activité observée visait des interfaces Web AhsayCBS accessibles depuis Internet. Le produit est utilisé par des fournisseurs de services managés et des intégrateurs système.[1]

Étape 2

La frontière d’authentification est contournée

Huntress attribue la première étape à CVE-2026-105133 et à checkSysPwd dans ApiStructsAction.java. Il s’agit du récit de l’équipe d’intervention ; les sources examinées ne publient pas le code vulnérable du fournisseur.[1], [3]

Étape 3

La faille Replication Receiver permet l’exécution de code

Huntress relie CVE-2026-105134 à l’injection de commandes dans /rps/api/json/UpdateReceivers.do. Son rapport indique que les attaquants ont configuré un receiver et déposé des webshells JSP dans le répertoire servi par l’application. Aucune syntaxe de requête ni payload n’est reproduit ici.[1], [4]

Étape 4

Traitez l’hôte comme potentiellement compromis

Dans les cas touchés, Huntress a observé des processus enfants du service, des webshells, un logiciel de minage déguisé et de la persistance. Restreignez l’accès d’administration, examinez l’hôte et les sauvegardes, puis suivez une procédure de reconstruction fiable si la compromission est confirmée.[1], [6]

Code Source : Vulnérable vs Sécurisé

L’exemple sécurisé utilise un exécutable fixe, une liste d’autorisation explicite et des arguments distincts dans ProcessBuilder ; il ne lance pas de shell et ne concatène pas l’entrée utilisateur dans une chaîne de commande. Il s’agit d’un modèle défensif générique qui montre comment fermer la frontière d’interprétation des commandes du système d’exploitation, et non du code source ou du correctif d’Ahsay. Les sources publiques consultées ne révèlent ni l’implémentation ni le correctif du fournisseur.[1], [3], [4]

IMPLÉMENTATION VULNÉRABLE
// Anti-modèle générique uniquement ; ce n’est pas du code source d’Ahsay.
void updateReceiver(Request request) {
    String receiver = request.parameter("receiver");
    String command = commandBuilder.forReceiverUpdate(receiver);
    operatingSystem.execute(command); // unsafe command-string boundary
}
PATCH SÉCURISÉ ET ROBUSTE
// Conception défensive générique uniquement ; ce n’est pas un correctif d’Ahsay.
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
}

Liste de Contrôle de Sécurité pour l'Ingénierie

Sources