Una IA encontró una falla crítica en PHP: el parche pasó a ser urgente
El jueves pasado se filtró que una IA había detectado una falla crítica en PHP antes de que existiera el arreglo, y buena parte de internet salió a buscar parches; varios gobiernos bajaron sus sitios por un tiempo, según Tyler Cowen en The Free Press. Zvi Mowshowitz lo llamó "probablemente el peor día en la historia de la ciberseguridad. Hasta ahora". Si tenés un sitio o un servidor propio, lo que importa es cuánto tardás en enterarte y en actualizar.
El jueves pasado se filtró la noticia de que una IA había detectado una falla crítica en PHP, el lenguaje con el que se construye buena parte de los sitios web, antes de que el arreglo estuviera disponible. Según Tyler Cowen, que lo cuenta en The Free Press, buena parte de internet salió a buscar parches, varios gobiernos bajaron sus sitios por un tiempo para limitar el riesgo de un ataque y es probable que muchos sitios viejos queden inutilizables para siempre. El comentarista Zvi Mowshowitz lo resumió así: "Fue probablemente el peor día en la historia de la ciberseguridad. Hasta ahora".
La lectura nuestra es que lo nuevo no es la falla sino el orden de los hechos: primero se supo, después hubo arreglo. Cowen cree que este episodio se supera sin que la economía se caiga, pero advierte que vendrán otros problemas, y que pueden ser bastante más serios. Para quien tiene un sitio, una tienda o un servidor, el riesgo ya no está solo en el error de programación: está en el tiempo que pasa entre que alguien lo encuentra y vos lo cerrás, y esa ventana ahora la marca la velocidad de una máquina.
Señal 01 · El hecho
Qué pasó con la falla de PHP y por qué te toca aunque no programes
Los datos concretos, según la columna de Cowen publicada el 26 de octubre: una IA detectó una falla crítica en PHP, la noticia se filtró antes de que existiera el arreglo, buena parte de internet salió a parchear y varios gobiernos desconectaron sus sitios por un tiempo. Cowen agrega que muchos sitios más viejos probablemente queden permanentemente disfuncionales, porque nadie los va a actualizar.
Por qué importa: PHP suele estar adentro del sitio que te armó un proveedor o de la web de un cliente, sin que nadie lo tenga presente. Cuando algo así se rompe, el afectado es quien lo sigue usando sin saber que está ahí.
Nuestra lectura: lo que quedó expuesto es una dependencia silenciosa. Un sitio que nadie mantiene se vuelve un riesgo en el momento en que alguien, humano o máquina, encuentra el error. Saber qué tenés publicado y quién lo mantiene es hoy una tarea de rutina, no un lujo de empresa grande.
Criptografía e IA: qué dice Cowen y qué no conviene sacar de ahí
Cowen cuenta que sigue con especial interés un tema: la criptografía. Según él, en la industria crece de a poco la preocupación por avances de la IA que, en teoría, podrían abrir la puerta de cada correo, transacción y cuenta bancaria. Cita dos titulares: "Vitalik Buterin advierte que la IA podría romper la criptografía de retículos en dos años" y "Claude AI resuelve en 30 minutos un misterio de criptografía de la NSA de 25 años". Cowen aclara que es asesor económico de Anthropic, la empresa detrás de ese modelo, un dato que conviene tener presente al leerlo.
Por qué importa: la columna plantea que, si un modelo atravesó una barrera que ninguna persona había superado, la pregunta de si alguna barrera está a salvo dejó de ser teórica. Son titulares citados por el autor, no pruebas que verificamos por separado.
Nuestra lectura: nadie que trabaja solo o con un equipo chico va a rediseñar la criptografía. Lo que sí controlás es lo que está en la capa de arriba: qué software tenés desactualizado, qué cuentas tienen más permisos de los que necesitan y qué tan rápido te enterás de un aviso de seguridad. El argumento de Cowen sobre defensas es justamente que apoyarse en las mejores disponibles compra tiempo y evita una crisis.
Accesos amplios e identidades de máquina: dónde se está moviendo el gasto en seguridad
Dos lecturas del mismo día apuntan a los accesos. La primera es una publicación de ErickSky en X: afirma que quien usa Tailscale SSH con reglas amplias queda expuesto, porque un solo equipo comprometido permitiría a un atacante llevarse acceso root de toda la flota, y que todavía no hay parche. Es una afirmación de una sola cuenta que no pudimos contrastar con otra fuente, así que la tomamos como alerta y no como hecho confirmado.
La segunda es un resumen de la llamada de resultados del cuarto trimestre fiscal 2026 de Palo Alto Networks, publicado por TheValueist. Concluye que el gasto en seguridad ligado a la IA se está expandiendo, pero que sus beneficios se reparten de manera despareja, y señala una demanda más fuerte de control de red y de gobierno de identidades de máquina, es decir, de decidir qué programas y agentes pueden entrar adonde.
Nuestra lectura: son dos ángulos de una misma pregunta que ya veníamos registrando, la de quién y qué tiene llaves. Una regla de acceso amplia no necesita un parche para corregirse: se revisa hoy, y conviene hacerlo antes de la próxima falla.
Esta semana se suma a un hilo que venimos registrando: cuando un agente o un sistema trabaja por vos, la pregunta es con qué accesos cuenta y quién responde por cada acción. Lo vimos primero en la edición sobre las llaves que ya tienen los agentes, y después en la de los sitios que no los dejan entrar. La falla de PHP muestra el mismo problema desde el otro lado: lo que tenés publicado también necesita dueño. La guía de agentes de IA para emprendedores ordena cómo delegar sin perder el control de los permisos.
Si tu sitio, la tienda de un cliente o alguna herramienta que mantenés está hecha en PHP, el lunes pedile a quien la mantiene, o a un agente con acceso de lectura a tu hosting, tres cosas por escrito: qué versión corre, si ya hay un arreglo publicado para la falla de la semana pasada y quién es la persona responsable de aplicarlo. Si la respuesta a la tercera es "nadie", ese es el hallazgo del día, y vale más que cualquier lista de herramientas.
El segundo frente es el de los accesos. Armá una lista corta con cada sistema donde alguien puede entrar con permisos de administrador y anotá quién, desde qué cuenta y con qué alcance. Si una sola cuenta comprometida abre todo, esa regla es demasiado amplia y se acota sin esperar ningún parche. Sabés que sirvió cuando podés contestar en una línea, por cada sistema, quién tiene acceso total y quién se entera si sale un aviso de seguridad. Si hoy esa línea no se puede escribir, ya sabés por dónde empezar.
La movida del día
Elegí hoy un solo sitio o servidor que dependa de vos y averiguá qué versión corre y quién lo actualiza. Después anotá cada cuenta con permisos de administrador y recortá la que tenga más alcance del necesario. Dejá la lista en un lugar donde la encuentres en diez segundos.
¿Una IA puede encontrar fallas de seguridad en el código?
Según Tyler Cowen en The Free Press, sí: una IA detectó una falla crítica en PHP y la noticia se filtró antes de que existiera el arreglo. Cowen cita además un titular donde un modelo de Anthropic resuelve en 30 minutos un misterio de criptografía de la NSA de 25 años. Son hechos que se leen en su columna, y la consecuencia práctica es que el tiempo entre que se descubre una falla y se arregla importa más que antes.
La edición abierta lee el mundo. La tuya lee TU mundo — tu industria, tus proyectos, tus objetivos — y llega a tu casilla cada mañana. Nadie más recibe tu edición.
