El 18 de agosto, PrestaShop publicó las versiones 8.2.8 y 9.1.5. Cinco vulnerabilidades corregidas, tres de ellas de severidad alta. Y en los agradecimientos, un detalle que hace dos años no habría estado ahí: una de las cinco, una inyección SQL en los filtros de los listados del back office, la descubrió Claude, el modelo de IA de Anthropic, dentro de su programa de divulgación coordinada. Un investigador humano, Savio, de Doyensec, la verificó y la reportó.
Es la primera vez que leo el nombre de un modelo de IA en las notas de una release de seguridad de PrestaShop. No va a ser la última.
Si sigues mínimamente la actualidad de seguridad, este año habrás visto el titular: 2026 va camino de cerrar con unas 66.000 vulnerabilidades publicadas, un 46% por encima de lo que se había previsto en febrero. Y como el titular viene acompañado de la palabra «IA», la conclusión fácil es que internet se ha vuelto un 46% más peligroso de golpe.
No es eso lo que ha pasado. Y confundir las dos cosas te va a costar dinero, en forma de sustos innecesarios o, peor, en forma de la actualización que sí importaba y que se quedó para el lunes.
De dónde sale el número
El equipo de previsión de FIRST —el organismo que coordina a los equipos de respuesta a incidentes de medio mundo—revisó a mitad de año su estimación para 2026 y la subió a unos 66.000 CVEs, un 46,3% por encima de su propia previsión de febrero. Solo hasta abril se habían registrado 6.420 vulnerabilidades «de más» respecto a lo esperado.
Detrás de esa subida hay tres cosas distintas, y merece la pena separarlas:
- La IA está encontrando fallos de verdad: Modelos apuntados contra bases de código antiguas están sacando a la luz bugs que llevaban ahí una década. Los datos de Epoch AI son claros: en julio se publicaron unos 2.500 CVEs de severidad alta o crítica entre organizaciones relevantes, alrededor de cinco veces el récord mensual anterior.
- Se está catalogando lo que antes no se catalogaba: El volumen de avisos de seguridad de GitHub creció un 449% interanual, y la actividad de VulnCheck como autoridad de último recurso se disparó un 3.119% absorbiendo una cola de vulnerabilidades históricas. Mucho de lo que aparece «nuevo» en 2026 es en realidad viejo, solo que ahora tiene número.
- Hay muchísimo más software que vigilar: El número de productos distintos con vulnerabilidades registradas ha crecido dos órdenes de magnitud. Más código en el mundo, más fallos en el mundo.
La parte que no sale en el titular
Aquí viene el dato que cambia la conversación, y que casi nadie ha puesto en un titular porque no da miedo.
Cuando FIRST filtra esas 66.000 vulnerabilidades y se queda solo con las que tienen riesgo real (las que están confirmadas como explotadas en ataques reales, o las que tienen una probabilidad alta de estarlo pronto), la carga de parcheo no ha crecido de forma significativa. Es la misma de siempre.
Ese filtro tiene nombre y apellidos, y merece la pena conocerlo porque son dos herramientas públicas y gratuitas:
- El catálogo KEV de CISA: La agencia de ciberseguridad estadounidense. Es la lista de vulnerabilidades sobre las que hay constancia de que se están explotando en ataques reales. No teóricos, no una prueba de concepto colgada en un blog: ataques. Entrar ahí es el criterio más alto que existe para dejar lo que estés haciendo.
- EPSS: Una puntuación mantenida por el propio FIRST que estima la probabilidad de que una vulnerabilidad se explote en los próximos treinta días. Es lo más parecido a una previsión meteorológica que tenemos en este oficio.
Y aquí está la distinción que casi nunca se explica y que lo ordena todo: la nota CVSS te dice lo grave que sería si te pasara; el KEV y el EPSS te dicen lo probable que es que te pase. Son cosas distintas y se usan para decisiones distintas. Un 10 sobre 10 que nadie está explotando y un 6,5 que lleva una semana usándose en ataques automatizados no se atienden en el mismo orden, por mucho que el primero luzca más en un titular.
La comparación que usa FIRST es buena: está lloviendo muchísimo, pero lo que amenaza con inundarte la casa sigue siendo una porción muy pequeña de esa lluvia. El problema de 2026 no es que haya más peligro; es que hay muchísimo más ruido alrededor del mismo peligro, y hace falta más criterio para encontrarlo.
Pero a veces sí entra el agua: junio de 2026
Para que no parezca que estoy quitándole hierro a todo, vamos al caso concreto que sí fue una emergencia, y que además fue en PrestaShop.
El 3 de junio se publicó el aviso de CVE-2026-54159, en el módulo `ps_facetedsearch`, el de la navegación por filtros. Un atacante podía colar un objeto PHP malicioso a través del valor de un filtro de rango (precio o peso) en la URL. Ese valor se guardaba serializado en la caché de bloques de filtros y después se leía con un unserialize() nativo, sin ninguna protección. El resultado era un fichero PHP escrito dentro del directorio del módulo y, a partir de ahí, ejecución de comandos en el servidor.
Puntuación CVSS: 10 sobre 10. Versiones afectadas: de la 3.0.0 a la 4.0.3. Corregido en la 4.0.4, y al día siguiente salieron PrestaShop 9.1.4 y 8.2.7.
¿Por qué esto sí era para dejarlo todo? Por tres motivos que no tienen nada que ver con la nota de 10:
- No requiere autenticación: Una sola petición desde internet, sin cuenta, sin nada.
- El punto vulnerable está en el escaparate: En las páginas de categoría, no detrás del login del back office. Y una tienda no puede cerrar el escaparate: vive de ser accesible.
- El módulo viene de serie: Está instalado en la inmensa mayoría de tiendas y, precisamente por venir de serie, mucha gente no lo trata como algo que haya que vigilar aparte.
El criterio: cuatro preguntas
Cuando te llegue un aviso de seguridad (por newsletter, por Twitter o porque te lo reenvía un cliente asustado) estas son las preguntas que hay que responder, en este orden:
- ¿Lo tengo instalado y activo?: Parece obvio. Pero no lo es. Mucha gente desconoce los componentes de su proyecto, la funcionalidad de los mismos o si está relacionado con su web.
- ¿Se explota sin autenticación y desde fuera?: Esta es la pregunta que más pesa. Un fallo que exige una cuenta de empleado del back office y otro que se dispara con una URL no juegan en la misma liga, aunque los dos aparezcan el mismo día.
- ¿Hay parche publicado y hay señales de explotación? Si el desarrollador ya ha sacado actualización de seguridad, la tarea es aplicar las indicaciones facilitadas por el desarrollador. Si además aparece en el KEV o tiene un EPSS alto, el reloj corre. Y si hay empresas de seguridad reportando intentos de explotación en internet contra ese módulo concreto, ya no corre: vuela.
- ¿Se dan las condiciones en mi tienda?: Por ejemplo, en el caso de junio, hacía falta tener activo un filtro de rango. Casi todas lo tienen, pero la pregunta hay que hacérsela igualmente.
El punto ciego de verdad: los módulos de PrestaShop
Aquí quiero ser claro, porque es lo que veo cada semana: el core de PrestaShop no suele ser el problema. Tiene equipo de seguridad, proceso de divulgación coordinada, avisos publicados con detalle técnico y un asistente de actualización. Funciona.
El problema son los otros treinta o cuarenta módulos que hay instalados en tu tienda, muchos de pago, muchos comprados hace años, y de los que nadie ha comprobado la versión desde que se instalaron. Un par de ejemplos reales de este año, sacados de los avisos de Friends of Presta:
- Un módulo de popups con una inyección SQL explotable sin autenticación, de severidad 9.8, corregida en febrero.
- Un módulo de envíos de UPS que dejaba accesibles desde internet, en una ruta predecible, los ficheros de log con credenciales de la API y datos personales de clientes. Severidad 8.6. Y aquí viene lo bueno: el desarrollador ya no existe y no va a haber parche nunca.
Ese último escenario es el que de verdad quita el sueño, y no sale en ningún titular sobre inteligencia artificial. No es un fallo que se arregla actualizando: es un fallo que solo se arregla quitando el módulo y sustituyéndolo, o refactorizando el código del mismo por completo, lo cual supone adaptar un código que no conoces y que puede que no funcione por ir contra el servicio de un tercero.
Con la aceleración de este año, esa deuda va a salir a la superficie mucho más rápido que antes. Si hay herramientas capaces de auditar código a una velocidad que antes no existía, el código PHP de un módulo de 2019 que nadie ha revisado nunca es exactamente el sitio donde van a aparecer cosas.
Qué conviene tener claro antes del próximo aviso
Nada de esto es nuevo ni sofisticado. Es justo lo que separa una mañana movida de una semana horrible:
- Copias de seguridad: Contar con un sistema de backup que permita restablecer el servicio y los datos en caso de que el proyecto se corrompiera.
- Una capa delante (WAF, Cloudflare o similar): Estos sistemas filtran y alertan de patrones de ataque automatizados. Ayuda a ganar horas; pero no sustituye al parche.
- Monitorización de ficheros:En el caso de junio, la comprobación posterior era literalmente buscar ficheros PHP que no deberían estar dentro del directorio del módulo. Esto es más fácil de revisar gracias a herramientas de control de versiones que detecten nuevos ficheros.
- Contar con un equipo especializado: Ya sea tu equipo o tu proveedor, pero que sea de alguien esa tarea. Con 66.000 CVEs al año, «ya me enteraré» no es una estrategia. Necesitas alguien que esté atento a todo lo que surja y actúe en tu proyecto.
- Una ventana de actualización mensual: Contar con un servicio de mantenimiento puede ayudarte a prevenir muchas de estas vulnerabilidades, pues se van actualizando de forma continuada los componentes de tu proyecto.
Sobre este último punto ya escribimos hace unas semanas, y sigue siendo la base de todo: por qué debes actualizar WordPress, PrestaShop y PHP regularmente. Lo que añade 2026 no es una razón nueva para actualizar, sino menos margen para ir con retraso.
En resumen
El número va a seguir subiendo. Es muy probable que 2027 haga que 66.000 parezca poco, y vamos a convivir con titulares cada vez más abrumadores.
Lo que no cambia es el criterio. Antes de la IA, lo que había que mirar era si el fallo se explotaba desde fuera, sin credenciales, en algo que tienes instalado. Después de la IA, exactamente lo mismo. Lo único que ha cambiado es que ahora hay que mirarlo más veces al mes y con menos ruido en la cabeza.
