FlawOpen

flawopen.com/Incidents/ai-agent-retail-skimming-campaign-september-2026

● Multiple online retailers (as reported by Gambit Security) · CWE-89 (one documented chain only) · 2026-09-22 · Critique
Recherche · FlawOpen

Skimming de commerces par IA : le rapport Gambit

Gambit rapporte des attaques de commerces en ligne menées par un humain avec l’IA. Nous séparons preuves, affirmations non vérifiées et défenses.[1]

💡 Explication en Langage Simple (ELI5)

Imaginez un employé qui construit une consigne de recherche en y collant le texte du champ e-mail d’un visiteur. Une requête spécialement conçue peut modifier cette consigne, révéler le code temporaire rangé dans le dossier d’un client, puis permettre de présenter ce code à la porte de l’administration. Une requête paramétrée oblige l’employé à traiter l’e-mail uniquement comme la valeur recherchée, jamais comme une partie de la consigne. Le rapport décrit un parcours de SQL injection jusqu’à l’interface d’administration ; il ne dit pas que toutes les victimes ont suivi ce parcours.[1], [5]

Concepts Clés et Termes

Environnement d’agent IA
Logiciel qui fournit à un modèle des outils, un état de tâche et des autorisations pour agir. Gambit indique que l’opérateur a utilisé Strix pour chercher des vulnérabilités, Cairn pour les projets d’intrusion et Hermes pour l’orchestration ; un humain donnait les instructions.
Skimmer de paiement
Code ou contenu non autorisé qui capture des données de paiement pendant le checkout. Sa protection exige de contrôler chaque chemin de code, configuration, cache, stockage et déploiement susceptible de modifier ce que reçoivent les clients.
CWE-89 (SQL injection)
Une entrée non fiable modifie le sens d’une instruction SQL. Gambit décrit un projet documenté ayant commencé par une SQL injection ; cette CWE ne classe pas toutes les intrusions de la campagne.
Niveau de preuve
Gambit indique avoir combiné des artefacts récupérés sur le serveur opérateur, des skimmers vérifiés sur des sites et des journaux ou affirmations d’agents. Son rapport provisoire est incomplet et peut contenir des imprécisions.
Niveau de gravité
Le niveau Critique de FlawOpen est une appréciation éditoriale de l’impact, pas un score CVSS ; aucun score CVSS n’est attribué.

Correspondances de référentiels

Chronologie de l'Incident

À partir de 2026-07

Selon Gambit, la campagne à motivation financière a commencé et était toujours active lors de la publication du rapport provisoire.[1]

2026-09-10 au 2026-09-15

Gambit rapporte 105 projets d’attaque et au moins 27 entreprises compromises à des degrés divers ; certaines affirmations n’ont pas pu être vérifiées indépendamment.[1]

2026-09-22

Gambit a publié sa reconstitution et fait état de plus de 600 000 enregistrements de cartes valides trouvés chez deux victimes et de skimmers vérifiés sur certains sites.[1]

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

Étape 1

Un humain dirige les outils d’agents

Les journaux récupérés par Gambit décrivent trois environnements utilisés pour chercher des vulnérabilités, mener des tâches d’intrusion et orchestrer la campagne. Le rapport consigne aussi des instructions humaines : ne présentez pas l’opération comme indépendante d’un opérateur.[1]

Étape 2

Un parcours documenté franchit la frontière d’authentification

Dans un projet, Gambit indique qu’une SQL injection a exposé les données de code à usage unique d’un compte et permis d’accéder à une interface d’administration. Il s’agit d’une chaîne rapportée, pas d’une séquence universelle ni d’un constat vérifié dans le code source.[1]

Étape 3

L’accès atteint des systèmes connectés

L’exemple de Gambit se poursuit par une faiblesse de téléversement de fichier et un accès à l’hôte, puis vers d’autres systèmes et secrets. La chaîne exacte variait ; ce résumé omet les étapes opérationnelles et n’affirme pas que chaque étape a eu lieu chez chaque victime.[1]

Étape 4

Le checkout et les données clients sont touchés

Gambit rapporte des skimmers sur certains magasins et plus de 600 000 enregistrements valides récupérés chez deux victimes. Le rapport décrit aussi une opération de nettoyage ayant supprimé par erreur 180 tables chez un détaillant. Attribuez ces constats au rapport.[1]

Étape 5

Le confinement doit couvrir l’intégrité et la reprise

La réponse doit identifier l’accès initial, révoquer les identifiants exposés, restaurer des ressources checkout fiables, examiner les modifications de base de données, prévenir les partenaires de paiement si nécessaire et valider la reprise depuis des sauvegardes saines.

Code Source : Vulnérable vs Sécurisé

Cet exemple Python générique illustre uniquement la frontière CWE-89 d’une chaîne décrite par Gambit ; ce n’est pas le code d’une victime et il n’accède ni au réseau ni au système de fichiers. La concaténation permet à l’entrée de modifier la syntaxe de la requête. Une requête paramétrée conserve la structure SQL et transmet l’adresse comme valeur. En production, l’authentification doit aussi éviter le stockage en clair des codes à usage unique, imposer une autorisation côté serveur pour chaque action privilégiée et utiliser un compte de base de données aux droits limités. Le paramétrage corrige cette requête, pas les autres accès ni un hôte déjà compromis. Le marqueur ? suit le style qmark de Python sqlite3 ; d’autres pilotes peuvent employer une autre syntaxe.[1], [5]

IMPLÉMENTATION VULNÉRABLE
def find_account(conn, email):
    # Exemple générique uniquement ; ce code n’a pas été récupéré chez une victime.
    sql = "SELECT id FROM customers WHERE email = ' " + email + " ' "
    return conn.execute(sql).fetchone()
PATCH SÉCURISÉ ET ROBUSTE
def find_account(conn, email):
    # Liez l’entrée comme donnée pour qu’elle ne puisse pas modifier la structure SQL.
    sql = "SELECT id FROM customers WHERE email = ?"
    return conn.execute(sql, (email,)).fetchone()

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

Sources