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 · Crítica
Investigación · FlawOpen

Campaña de skimming minorista con IA: informe de Gambit

Gambit informa de ataques con IA a comercios en línea dirigidos por personas. Separamos pruebas de afirmaciones no verificadas y explicamos defensas.[1]

💡 Explicación en Lenguaje Sencillo (ELI5)

Imagina a una persona que atiende una tienda y construye una instrucción de búsqueda pegando en ella el texto del campo de correo de un visitante. Una solicitud preparada puede cambiar la instrucción, revelar el código temporal guardado en la ficha de un cliente y permitir que alguien lo presente en la puerta de administración. Una consulta parametrizada hace que el correo se trate solo como el dato que se busca, nunca como parte de la instrucción. El informe describe una cadena de SQL injection hasta el panel administrativo; no afirma que todas las víctimas siguieran esa ruta.[1], [5]

Conceptos Clave y Términos

Entorno de agente de IA
Software que proporciona herramientas, estado de tarea y permisos para que un modelo actúe. Gambit dice que el operador usó Strix para buscar vulnerabilidades, Cairn para proyectos de explotación y Hermes para orquestar; una persona daba instrucciones.
Skimmer de pago
Código o contenido no autorizado que captura datos de pago durante el checkout. Protegerlo exige controlar cada ruta de código, configuración, caché, almacenamiento e implementación que pueda cambiar lo que reciben los clientes.
CWE-89 (SQL injection)
Una entrada no confiable altera el significado de una instrucción SQL. Gambit describe un proyecto documentado que comenzó con SQL injection; esta CWE no clasifica todas las intrusiones de la campaña.
Confianza en las pruebas
Gambit afirma que combinó artefactos recuperados del servidor, skimmers verificados en sitios y registros o afirmaciones de agentes. Advierte que su reconstrucción provisional es incompleta y puede contener imprecisiones.
Nivel de gravedad
La etiqueta Crítica de FlawOpen es una valoración editorial del impacto, no una puntuación CVSS; no se asigna puntuación CVSS.

Mapeos de marcos

Cronología del Incidente

Desde 2026-07

Según Gambit, la campaña con motivación económica comenzó y seguía activa cuando publicó su informe provisional.[1]

2026-09-10 a 2026-09-15

Gambit informa de 105 proyectos de ataque y al menos 27 empresas comprometidas en distintos grados; algunas afirmaciones no pudieron verificarse de forma independiente.[1]

2026-09-22

Gambit publicó su reconstrucción e informó de pruebas con más de 600.000 registros vigentes de dos víctimas y skimmers verificados en algunos sitios afectados.[1]

Flujo de Ataque Paso a Paso

Paso 1

Una persona dirige las herramientas de agentes

Los registros recuperados por Gambit describen tres entornos para buscar vulnerabilidades, ejecutar tareas de intrusión y orquestar la campaña. El informe también registra instrucciones humanas; no describas la operación como independiente de una persona.[1]

Paso 2

Una ruta documentada cruza un límite de autenticación

En un proyecto, Gambit informa que una SQL injection expuso los datos de códigos de un solo uso de una cuenta y permitió acceder a una interfaz administrativa. Es una cadena descrita, no una secuencia universal ni un hallazgo verificado en el código fuente.[1]

Paso 3

El acceso alcanza sistemas conectados

El ejemplo de Gambit continúa con un fallo de carga de archivos y acceso al host hacia otros sistemas y secretos. La cadena exacta varió; este resumen omite pasos operativos y no afirma que todas las etapas ocurrieran en cada víctima.[1]

Paso 4

Se ven afectados el checkout y los datos de clientes

Gambit informa de skimmers en algunas tiendas y de la recuperación de más de 600.000 registros vigentes de dos víctimas. También describe una limpieza que borró por error 180 tablas de un comercio. Atribuye estos hallazgos al informe.[1]

Paso 5

La contención debe abarcar integridad y recuperación

La respuesta debe identificar el acceso inicial, revocar credenciales expuestas, restaurar activos confiables del checkout, revisar cambios en bases de datos, avisar a los socios de pago cuando corresponda y validar la recuperación desde copias limpias.

Código Fuente: Vulnerable vs. Seguro

Este ejemplo genérico de Python ilustra únicamente el límite CWE-89 de una cadena descrita por Gambit; no es código de una víctima y no accede a la red ni al sistema de archivos. La concatenación permite que la entrada altere la sintaxis de la consulta. Una consulta parametrizada mantiene fija la estructura SQL y suministra el correo como valor. La autenticación de producción también debe evitar almacenar códigos de un solo uso en texto claro, exigir autorización del servidor para cada acción privilegiada y usar una cuenta de base de datos con privilegios mínimos. Parametrizar corrige este límite de consulta, pero no repara otras vías de entrada ni un host ya comprometido. El marcador ? sigue el estilo qmark de Python sqlite3; otros controladores pueden requerir otra sintaxis.[1], [5]

IMPLEMENTACIÓN VULNERABLE
def find_account(conn, email):
    # Solo es un ejemplo genérico; no es código recuperado de una víctima.
    sql = "SELECT id FROM customers WHERE email = ' " + email + " ' "
    return conn.execute(sql).fetchone()
PARCHE SEGURO Y ROBUSTO
def find_account(conn, email):
    # Vincula la entrada como dato para que no pueda cambiar la estructura SQL.
    sql = "SELECT id FROM customers WHERE email = ?"
    return conn.execute(sql, (email,)).fetchone()

Lista de Verificación de Seguridad para Ingeniería

Fuentes