Google arregló 1.072 fallos de seguridad de Chrome en junio, más que en los dos años anteriores juntos. Las 23 versiones publicadas en esos dos años sumaron 1.036 correcciones. Dos versiones de un solo mes las han superado. La causa que da Google es una: los modelos de lenguaje buscando bugs a escala.
Puntos clave
- Chrome 149 y 150, ambos de junio de 2026, corrigieron 1.072 fallos de seguridad entre los dos.
- Las 23 versiones anteriores, publicadas a lo largo de dos años, sumaron 1.036.
- Microsoft parcheó 570 vulnerabilidades en su Patch Tuesday de julio de 2026 y lo atribuye a lo mismo.
- Apple lleva 482 fallos parcheados en 2026, un ritmo similar al que tenía en 2015.
Qué ha cambiado en el descubrimiento de bugs
Encontrar una vulnerabilidad en un navegador ha sido siempre trabajo artesanal. Un investigador con experiencia, semanas de fuzzing, revisión manual de código y suerte. Ese modelo pone un techo natural a cuántos fallos se encuentran al año: el número de gente capaz de hacerlo.
Un modelo que lee código y propone rutas de explotación rompe ese techo. No porque sea mejor que el mejor investigador humano, sino porque puede revisar millones de líneas sin cansarse y proponer candidatos que después alguien verifica.
Doug Turner, director de ingeniería de Chrome, lo dice en una frase: "los LLM han cambiado de raíz la economía de la ciberseguridad". El descubrimiento de vulnerabilidades ha pasado de artesanía a operación industrial.
La diferencia entre los tres grandes
El contraste entre las cifras es lo más informativo del asunto.
Google y Microsoft muestran la misma curva exponencial y los dos apuntan a la IA como causa. Apple no. Sus 482 fallos parcheados en 2026 la dejan en un ritmo parecido al de 2015, once años atrás.
Eso admite dos lecturas y ninguna es tranquilizadora del todo. O el software de Apple tiene muchos menos fallos que el de Google y Microsoft, lo cual sería sorprendente en bases de código de tamaño comparable. O Apple está encontrando bastantes menos de los que tiene.
Lo que este número no dice
Que se arreglen más bugs no significa que hubiera más bugs. Significa que se están encontrando los que ya estaban ahí.
Es decir, Chrome no era más inseguro en junio de 2026 que en mayo. Era exactamente igual de inseguro, solo que ahora conocemos 1.072 problemas más de los que conocíamos.
Y aquí está la parte incómoda: la misma capacidad que permite a Google encontrar mil fallos en un mes permite a cualquiera con acceso a un modelo capaz hacer lo propio con software que no es suyo. La economía del descubrimiento ha cambiado para los dos bandos a la vez.
Por qué importa
Si tu empresa tiene software propio en producción (una web, una API, un ERP tocado a medida), la ventana entre que existe un fallo y que alguien lo encuentra se acaba de acortar mucho.
Dos consecuencias prácticas.
La primera es que el calendario de actualizaciones deja de ser opcional. Si Chrome corrige mil fallos en un mes, cada versión que te saltas acumula riesgo real, no teórico. Lo mismo con el sistema operativo, con el servidor y con las dependencias.
La segunda es que revisar tu propio código con un modelo ya no es un experimento de curioso. Es exactamente lo que hace Google, con las mismas herramientas que tienes tú en la API. No vas a encontrar mil bugs, pero probablemente encuentres los tres que llevaban dos años ahí porque nadie tenía tiempo de mirar.
El coste de esa revisión hoy son unos pocos euros de tokens. El coste de que la haga otro antes que tú no tiene precio de tarifa.
Relacionado
