Ninguna máquina puede certificar cualquier programa, pero ya encuentra lo que se nos escapó

El proyecto PHP publicó el 21 de octubre las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 del lenguaje, con las que corrige dos fallas críticas que pueden permitir ejecutar código en un servidor web sin usuario ni contraseña^[1]. Ambas recibieron 9,2 puntos sobre 10 en la escala de gravedad CVSS 4.0^[2][3]. Las encontraron investigadores de Wiz Research, OpenAI y Calif, con la colaboración del equipo de Gemini de Google^[4]. Wiz informó que trabajó con los modelos Wiz Atlas, Gemini 4 Argon y GPT-5.6 Sol^[5]; OpenAI, que Calif identificó una falla crítica con GPT-5.6 Sol^[6]. Según Wiz, hay versiones afectadas desde PHP 5.4 y el código vulnerable «había estado presente durante más de una década»^[5].

Un error escrito a la vista de todos, en un programa abierto, esperó más de diez años a que alguien sacara sus consecuencias. Esta vez, las sacaron máquinas guiadas por personas.

Lo que ninguna máquina puede decidir

En 1936 demostré que no existe un procedimiento general capaz de responder ciertas preguntas sobre cualquier programa. Lo escribí así: «no puede haber ninguna máquina E que, al recibir la descripción estándar de una máquina arbitraria M, determine si M imprime alguna vez un símbolo dado (0, digamos)»^[9]. Preguntar si un servidor llegará alguna vez a ejecutar las órdenes de un extraño es una pregunta de esa misma familia. No habrá, entonces, un examinador universal que reciba cualquier programa y certifique que es seguro.

No es una condena para las máquinas. En 1950 respondí a quienes usaban ese resultado contra las máquinas: está establecido que existen limitaciones a los poderes de cualquier máquina en particular, pero «solo se ha afirmado, sin ninguna clase de prueba, que no se aplican tales limitaciones al intelecto humano»^[10]. El caso de PHP lo ilustra: según la PHP Foundation, en 2024 un desarrollador del proyecto ya había visto los primeros indicios de una de estas fallas, la del manejo de la falta de memoria, y se llegó a teorizar un ataque, pero nadie encontró una forma concreta de explotarlo^[7]. Lo que no se puede decidir en general sigue pudiendo encontrarse caso por caso, y en esa búsqueda una máquina incansable es una aliada formidable.

El trabajo de sacar consecuencias

En aquel mismo artículo señalé una falacia a la que, escribí, «los filósofos y los matemáticos están particularmente expuestos»: suponer que, en cuanto un hecho se presenta a una mente, todas sus consecuencias aparecen en ella al mismo tiempo. De ahí se sigue la idea de que «no hay mérito en el mero trabajo de extraer consecuencias a partir de datos y principios generales»^[10]. El código de PHP estaba publicado; sus consecuencias, no. Hacía falta seguir, paso a paso, qué ocurre cuando el programa se queda sin memoria a mitad de un pedido o cuando un proceso conserva datos de un pedido anterior^[2][3]. Ese trabajo, que parecía no tener mérito, es exactamente el que faltaba.

Y se hizo deprisa. Según la cronología de Wiz, su equipo descubrió la primera falla el 19 de agosto, en los dos días siguientes confirmó ataques sin autenticación contra sitios armados con Drupal y con WordPress, y el 24 lo informó al equipo de seguridad de PHP^[5]. La PHP Foundation cuenta que Calif ya había reportado el 11 de agosto una ejecución remota de código con la misma causa de fondo que aquel problema de memoria, y que OpenAI informó esa misma causa, de manera independiente, ese mismo día^[7]. Que equipos distintos lleguen por separado al mismo defecto indica un método, no suerte.

La máquina busca; la persona decide

En 1949, en Cambridge, propuse que quien escribe un programa deje asentadas afirmaciones sobre los estados que la máquina puede alcanzar, de modo que otro pueda comprobarlas una por una y verificar, además, que el proceso termina^[11]. La división del trabajo que describe la PHP Foundation se le parece: la inteligencia artificial ayuda a validar los reportes y a agrupar los que comparten una misma causa, pero «una persona toma cada decisión y trabaja en cada parche». La fundación advierte que «las herramientas hoy encuentran fallas más rápido que nunca, tanto para los defensores como para los atacantes, y la cantidad de reportes seguirá creciendo»^[7]. Desde el primer reporte de Calif hasta las versiones corregidas pasaron 71 días^[7][1], y la fundación cuenta que, antes de esos reportes, el arreglo del problema de memoria se trabó y se reinició durante meses^[7]. El cuello de botella ya no está en encontrar, sino en corregir bien.

La carrera, por ahora, la ganaron los defensores. Ni el aviso de PHP ni los informes técnicos dicen que las fallas se estén explotando^[1][2][3], y el catálogo de vulnerabilidades explotadas de la agencia de ciberseguridad de los Estados Unidos, en su versión del 21 de octubre, no las incluye^[8]. Para que eso valga de algo, quien administra un servidor con PHP tiene que instalar la versión corregida: el proyecto insiste en que es la única solución completa^[1].

Escribí hace más de setenta años que las máquinas me tomaban por sorpresa «con gran frecuencia»^[10]. Esta sorpresa es de las buenas: máquinas que encuentran en programas escritos por personas lo que a esas personas se les escapó. No darán la certeza que la lógica prohíbe, pero sí una búsqueda incansable. Cerré aquel artículo de 1950 con una frase que hoy repetiría sin cambiar una palabra: «Solo podemos ver un poco hacia adelante, pero podemos ver mucho allí que necesita hacerse»^[10].