Este 2025 ha dejado claro que el manual clásico de ciberseguridad ya no sirve para proteger aplicaciones y sitios web modernos.
Los ataques impulsados por IA, las inyecciones de JavaScript a escala industrial y los compromisos en la cadena de suministro han demostrado que ya no basta con poner un firewall, un WAF y cruzar los dedos.
En este artículo repasamos las cinco amenazas que han marcado este año y, sobre todo, qué cambios prácticos puedes aplicar desde ya para llegar mejor preparado a 2026.
#1. Vibe coding
El vibe coding o programación en lenguaje natural ha pasado de curiosidad a realidad en producción: cerca de una cuarta parte de las startups de Y Combinator (aceleradora de startups más importante del mundo) ya dependen de asistentes de IA para generar buena parte de su código base.
Un ejemplo ilustrativo fue el de un desarrollador que montó un simulador de vuelo multijugador en pocas horas y lo escaló a decenas de miles de jugadores, pero con una base de código que nadie había revisado realmente a nivel de seguridad.
El problema es que la IA genera exactamente lo que se le pide, no lo que se debería pedir desde el prisma de la seguridad.
Esto produce aplicaciones que funcionan pero que vienen cargadas de fallos explotables, huecos en la lógica de autenticación, falta de controles de entrada y configuraciones peligrosas por defecto.
Estudios recientes apuntan a que una proporción muy significativa del código generado por estas herramientas contiene vulnerabilidades aprovechables, especialmente en lenguajes complejos como Java.
En 2025 ya se han visto incidentes graves: un asistente de IA llegó a borrar una base de datos de producción con información de cientos de ejecutivos, ignorando las políticas internas de congelación de cambios.
Además, varias herramientas de desarrollo asistido por IA han recibido CVE por permitir ejecución arbitraria de comandos, acceso indebido al sistema de archivos o exfiltración de datos a través de técnicas de inyección en los prompts y en el canal DNS.
A esto se suman fallos menos vistosos pero igualmente críticos: formularios de login generados por IA que omiten validaciones básicas, APIs que no comprueban autorización a nivel de recurso, o serializaciones inseguras que abren la puerta a ataques de deserialización.
En plataformas de vibe coding como Base44 se llegó a encontrar un bypass de autenticación que permitía a cualquier atacante acceder a aplicaciones privadas alojadas en la infraestructura compartida, afectando a sistemas con datos personales, RRHH y asistentes internos.
El caso de Base44 dejó una lección clara: si la seguridad de la plataforma falla, todos los proyectos construidos encima caen de golpe.
Aunque el proveedor parcheó en menos de 24 horas, el incidente evidenció lo delicado que es confiar ciegamente en entornos gestionados por terceros cuando se trabaja con aplicaciones que manejan información sensible.
La respuesta de las organizaciones está siendo tratar todo el código generado por IA como código no confiable: se imponen revisiones humanas obligatorias, se integran escáneres de seguridad en los pipelines CI/CD y se añaden pruebas de caja negra y de lógica de negocio antes de desplegar.
Cada vez se habla más de security-first prompting: diseñar los prompts pensando explícitamente en validaciones, control de errores, límites y auditoría, y no solo en que el código funcione.
También se están implantando mecanismos de monitorización de comportamiento para detectar llamadas inesperadas a APIs, patrones de serialización anómalos o tiempos de respuesta que delatan intentos de explotación.
El marco regulatorio empieza a ponerse al día: el Reglamento de IA de la UE ya clasifica ciertos usos de IA en desarrollo de software como sistemas de alto riesgo, lo que obliga a aplicar controles rigurosos y a poder demostrar que se han tomado medidas de seguridad razonables.
Si tu equipo ya está usando copilotos o plataformas de generación de código, merece la pena definir una política clara: qué tipo de componentes se pueden generar automáticamente, quién los revisa, cómo se rastrea su origen y qué evidencias guardas de los controles realizados.
En entornos críticos, muchas empresas están optando por restringir el uso de IA a plantillas, utilidades y prototipos, dejando las partes sensibles (auth, pagos, cifrado, lógica de negocio clave) bajo desarrollo manual con revisión exhaustiva.
#2. Inyección de JavaScript: el navegador como campo de batalla
En marzo de 2025 se detectó una campaña masiva de inyección de JavaScript que comprometió unas 150.000 webs para redirigir tráfico a plataformas de juego online vinculadas con operadores chinos.
Los atacantes insertaban scripts e iframes que imitaban sitios de apuestas conocidos, usando capas CSS a pantalla completa para sustituir el contenido legítimo por páginas falsas que capturaban datos y empujaban a los usuarios a acciones fraudulentas.
Esta campaña no surgió de la nada: reutilizaba patrones de ataques previos como el incidente de Polyfill.io, donde se aprovechó la confianza en una librería muy extendida para inyectar código malicioso en más de cien mil sitios de marcas conocidas.
Con alrededor del 98 % de las webs modernas dependiendo de JavaScript en el lado del cliente, el navegador se ha convertido en un punto de ataque casi universal.
Lo más preocupante es que incluso marcos con defensas XSS integradas, como React, no han sido inmunes.
Los atacantes combinan técnicas como la contaminación de prototipos, XSS basado en DOM y hasta inyecciones asistidas por IA para encontrar rutas poco evidentes hacia la ejecución de código en el cliente.
El impacto va mucho más allá de simples redirecciones: se han reportado decenas de miles de sesiones bancarias secuestradas, en campañas que detectan en tiempo real la estructura del DOM para localizar formularios críticos y extraer credenciales o datos sensibles.
El número de vulnerabilidades registradas relacionadas con este tipo de ataques ha crecido de forma notable respecto a años anteriores, lo que refleja tanto una mayor superficie como una profesionalización clara de los atacantes.
Para defenderse, muchas organizaciones están cambiando la forma en que gestionan los datos en el frontend.
En lugar de mezclar contenido y lógica, se guarda la información en bruto y se aplica el tipo de codificación adecuado según el contexto: codificación HTML para contenido en elementos, escape específico para JavaScript dentro de scripts y codificación de URLs para parámetros en enlaces.
Las herramientas de monitorización en tiempo de ejecución se centran ahora en detectar comportamientos inesperados: bibliotecas estáticas que de repente hacen peticiones POST a dominios desconocidos, scripts que intentan leer más allá de lo previsto o cambios en el flujo de datos que no corresponden con las actualizaciones de código oficiales.
Además de esto, empiezan a extenderse servicios externos especializados en inventariar todos los scripts que se cargan en una web, indicando su origen, permisos efectivos y cambios entre versiones para poder reaccionar rápido ante un compromiso de terceros.
Si administras un sitio o una aplicación web, conviene limitar al máximo la carga de recursos desde dominios que no controlas directamente, fijar versiones concretas de librerías, activar políticas estrictas de Content Security Policy y combinarlo con validaciones de comportamiento.
También es clave incorporar auditorías periódicas de seguridad de front-end, incluyendo pruebas de XSS, revisión de dependencias y escaneo de scripts externos.
#3. Magecart y e-skimming 2.0: el robo silencioso en los pagos online
Los ataques de tipo Magecart, centrados en robar datos de tarjetas y de pago en tiempo real desde el navegador, han experimentado un crecimiento de más del 100 % en apenas medio año.
En lugar de atacar directamente la infraestructura del servidor, los delincuentes se camuflan como scripts aparentemente legítimos, muchas veces cargados desde CDNs o proveedores de funcionalidades externas.
Estos skimmers modernos son mucho más complejos que los de hace unos años.
Emplean técnicas como la manipulación del DOM en la sombra, conexiones WebSocket para exfiltrar datos en canales de larga duración y geofencing para activar el robo solo en determinados países o rangos de IP, reduciendo el riesgo de ser detectados en pruebas internas.
Se han documentado variantes que se desactivan automáticamente si detectan que el desarrollador ha abierto las herramientas de Chrome, lo que dificulta aún más su análisis en entornos de desarrollo o auditoría manual.
A lo largo de los últimos años, grandes marcas como aerolíneas, empresas de entradas o comercios electrónicos han sufrido este tipo de incidentes con pérdidas de millones en multas, reembolsos y daño reputacional.
Una de las tácticas más preocupantes ha sido el uso de librerías populares como Modernizr para introducir cargas maliciosas que solo se activan en páginas de pago.
De esta forma, el resto del sitio parece funcionar con normalidad, y los cortafuegos de aplicaciones web o las soluciones de seguridad tradicionales no detectan ningún comportamiento fuera de lugar hasta que ya es demasiado tarde.
En 2025 también se ha descubierto una campaña particularmente sofisticada vinculada al dominio cc-analytics.com, con JavaScript fuertemente ofuscado que llevaba al menos un año robando datos de tarjetas en cientos o miles de comercios online.
Este tipo de infraestructura maliciosa suele reciclar dominios que suenan a herramientas de analítica o monitorización, lo que favorece que pasen desapercibidos durante largo tiempo.
Las empresas han comprobado que confiar únicamente en Content Security Policy puede dar una falsa sensación de seguridad, porque si un atacante compromete un dominio ya autorizado, sus scripts pasan todos los filtros.
Por ese motivo, la tendencia es validar el código por lo que hace, no solo por su origen declarado.
En el ámbito normativo, PCI DSS 4.0.1 incluye requisitos específicos para la monitorización continua de todos los scripts que acceden a datos de pago, con obligatoriedad a partir de marzo de 2025.
Esto implica llevar un inventario vivo de scripts, registrar cambios, validar quién tiene acceso a ellos y analizar si su comportamiento se mantiene dentro de lo esperado.
Para tu propia tienda online o la de tus clientes, esto se traduce en varias buenas prácticas: reducir al mínimo los scripts de terceros en las páginas de checkout, revisar regularmente qué código se carga allí, activar alertas por cambios inesperados y segmentar al máximo los sistemas que procesan datos de pago.
También conviene emplear herramientas que verifiquen de forma continua el contenido de las páginas de pago desde el punto de vista del usuario final, no solo del servidor.
#4. Ataques a la cadena de suministro de IA y open source
Los repositorios de código abierto se han convertido en un objetivo prioritario, con un aumento muy notable de paquetes maliciosos subidos a registros públicos en 2025.
La novedad es que muchos de estos ataques se apoyan en la IA para generar malware polimórfico que se reescribe de una instalación a otra y se adapta al entorno que detecta.
Tradicionalmente, un ataque a la cadena de suministro implicaba credenciales robadas o paquetes fake con nombres parecidos a los legítimos.
Ahora se ven variantes que incluyen documentación, tests automatizados y hasta un historial de commits aparentemente razonable, diseñados para superar revisiones superficiales y para engañar a herramientas de análisis automatizado.
En este contexto, las firmas basadas en patrones fijos han perdido mucha eficacia, ya que el código dañino cambia constantemente y puede ocultarse entre funciones legítimas.
Informes recientes indican que, de media, las brechas tardan muchos meses en detectarse y otro buen tramo en contenerse, lo que multiplica el impacto real sobre datos y operaciones.
Un ejemplo de lo que está en juego fue la puerta trasera en una biblioteca vinculada al ecosistema de Solana, que permitió robar entre 160.000 y 190.000 dólares en criptomonedas en una ventana de solo unas horas.
El ataque se apoyaba en la confianza automática que muchos desarrolladores depositan en actualizaciones aparentemente menores de librerías que llevan tiempo usando.
Entre septiembre y diciembre de 2025 se identificó además un gusano conocido como Shai-Hulud, que aprovechaba scripts bash generados por IA para infectar cientos de paquetes de npm y decenas de miles de repositorios en GitHub en apenas unos días.
El malware estaba específicamente diseñado para engañar tanto a analistas humanos como a modelos de IA defensivos, que clasificaban el código como seguro o inofensivo, mientras robaba credenciales de entornos de desarrollo y publicaba versiones troyanizadas usando tokens comprometidos.
Para hacer frente a este escenario, las organizaciones están combinando varias estrategias: desde mecanismos de detección específicos para IA hasta análisis de procedencia del código, pasando por defensas en tiempo de ejecución basadas en principios de confianza cero.
También se están introduciendo sistemas de prueba de humanidad para validar quién está detrás de determinados paquetes o contribuciones críticas, intentando reducir el riesgo de que identidades automatizadas o usurpadas cuelen código malicioso.
El marco legal, especialmente en Europa, contempla sanciones importantes para quienes no gestionen adecuadamente los riesgos asociados al uso de sistemas de IA, incluyendo porcentajes elevados de la facturación global de la compañía.
En la práctica, esto obliga a reforzar procesos de aprobación de dependencias, auditorías de código de terceros y controles sobre cómo se integran modelos y herramientas de IA en la cadena de desarrollo.
Si trabajas con ecosistemas como npm, PyPI o similares, es fundamental fijar versiones concretas en lugar de rangos amplios, revisar con lupa paquetes poco conocidos y limitar quién puede introducir nuevas dependencias en un proyecto.
También tiene sentido montar espejos internos, aplicar firmas digitales verificables y ejecutar los paquetes de terceros en entornos muy segmentados antes de darles acceso a datos o infraestructuras sensibles.
#5. Validación de privacidad web: de la teoría al riesgo legal real
En paralelo a los ataques puramente técnicos, la privacidad web se ha convertido en un frente igual de crítico.
Investigaciones recientes muestran que un porcentaje elevado de las principales webs de Estados Unidos instala cookies de publicidad incluso cuando el usuario ha rechazado expresamente ese tipo de seguimiento.
El problema no suele ser un único script malicioso, sino una combinación de píxeles de marketing, etiquetas de analítica y código de terceros que se comportan de forma distinta a lo declarado en las políticas de privacidad.
Con cada actualización de la web, cambio de proveedor o nueva campaña, se producen pequeños desajustes que, con el tiempo, se convierten en un incumplimiento sistemático difícil de detectar con auditorías puntuales.
Se han documentado casos de scripts de fidelización que envían direcciones de correo de clientes a dominios externos sin registro formal, o de herramientas de analítica que acaban recopilando datos de pacientes en entornos sanitarios sin el consentimiento adecuado.
Este tipo de situaciones no solo mina la confianza del usuario, sino que expone a las organizaciones a sanciones significativas bajo marcos como GDPR, CCPA o normativas sectoriales como HIPAA.
En 2025, una resolución judicial en Estados Unidos concluyó que el uso conjunto de determinadas etiquetas de seguimiento para compartir información de solicitudes de crédito, empleo y datos bancarios constituía una forma de exfiltración de datos bajo la legislación de privacidad vigente.
Esto abrió la puerta a reclamaciones económicas por cada incidente, equiparando en la práctica ciertos abusos de seguimiento con brechas de seguridad clásicas.
Como respuesta, ha ganado peso el concepto de validación continua de privacidad en producción: no basta con tener una política bien redactada y un banner de cookies, hay que comprobar de forma automatizada qué datos salen realmente del navegador y hacia qué destinos.
Las soluciones que se están implantando incluyen mapeo dinámico de datos, alertas en tiempo real cuando se detectan nuevos receptores de información y sistemas que verifican que los cambios aplicados desde desarrollo se reflejan en el comportamiento real.
Al inicio del año, muy pocas empresas se sentían seguras de cumplir con todas sus obligaciones en materia de privacidad web, pero aquellas que han adoptado monitorización continua han visto simplificadas sus auditorías y han logrado integrar seguridad y privacidad en un mismo flujo de trabajo.
Este enfoque reduce notablemente la brecha entre lo que la empresa declara en su web y lo que técnicamente ocurre bajo el capó.
Si gestionas sitios con formularios sensibles, áreas de clientes o productos de salud y finanzas, merece la pena revisar qué terceros cargan código en tus páginas y qué datos pueden recolectar.
La combinación de inventario de scripts, escaneos de comportamiento y revisiones legales periódicas puede marcar la diferencia entre un simple ajuste de configuración y un incidente público costoso.
#Cómo prepararse para 2026
Las cinco amenazas anteriores tienen un hilo común: la seguridad reactiva ya no es suficiente.
Cuando una alerta tradicional salta, es muy probable que el atacante lleve tiempo moviéndose dentro de tu entorno o explotando a tus usuarios desde el navegador.
Las organizaciones que mejor están resistiendo este nuevo escenario han adoptado tres principios básicos: asumen que el fallo de seguridad es cuestión de tiempo, se centran en detección y contención rápidas, y han dejado atrás la mentalidad de auditoría puntual para pasar a la validación continua.
Además, tratan la IA con una doble perspectiva: como herramienta clave para automatizar defensas, pero también como una nueva superficie de ataque y un origen potencial de vulnerabilidades.
De cara a 2026, hay cinco líneas de trabajo prioritarias que cualquier equipo de seguridad debería abordar: inventariar todas las dependencias de terceros (scripts, librerías, APIs), desplegar monitorización de comportamiento en producción, auditar con rigor todo el código generado por IA, validar la privacidad real del sitio web y establecer mecanismos de supervisión continua en lugar de revisiones trimestrales aisladas.
Cuanto antes se integren estos cambios en el ciclo de vida del desarrollo y la operación, más fácil será adaptarse a las amenazas que seguirán evolucionando en los próximos años.