Qué ha pasado
El 11 de septiembre, Simon Willison publicó dos versiones de seguridad de Datasette: la 1.0a39 y la 0.65.4. Datasette es una herramienta de código abierto que coge datos de casi cualquier forma y los convierte en una web consultable. Según su propia página, está pensada para periodistas de datos, conservadores de museo, archiveros, administraciones locales, científicos e investigadores. Y para cualquiera que tenga datos que quiera compartir con el mundo.
El aviso que acompaña a los parches no se anda con rodeos. Quien tenga Datasette funcionando en internet público debería actualizar ya, y con más motivo si usa un complemento de autenticación para proteger datos privados.
Lo interesante es de dónde salieron los fallos que arreglan.
De dónde salieron los fallos
Sevban Dönmez envió al proyecto varios informes de vulnerabilidad hechos con ayuda de inteligencia artificial. Eso les animó a auditar el proyecto entero con una combinación de tres modelos distintos. Willison lo dice con todas las letras: es la primera vez que hacen una auditoría de seguridad a fondo con agentes de código.
Hicieron varias rondas, buscando en el resto del código problemas parecidos a los que ya habían encontrado. De ahí salió, en sus palabras, «un número significativo de problemas».
Cuántos, no lo dice. Y hay una parte del detalle que se están guardando a propósito: retienen del repositorio público algunas de las pruebas automatizadas. Es para dar más tiempo a actualizar antes de que se conozcan los fallos que esas pruebas describen.
El código no ha cambiado; ha cambiado lo que lo mira
Willison escribe que el mundo de la seguridad del software se ha transformado este año por los modelos de lenguaje de última generación y los agentes de código. Y avisa de que piensan seguir auditando Datasette con esas herramientas.
Datasette tiene recorrido: una rama estable en la serie 0.65 y la versión 1.0 todavía en fase alfa. Su código ya se había mirado antes, y el propio anuncio lo dice: parte de los fallos que corrigen los habían reportado investigadores de fuera. Lo que nunca habían hecho era esto, con estas herramientas.
Y conviene mirar cómo empezó todo, porque no fue una decisión de agenda. Lo que les puso a auditar fue que alguien de fuera les llegara con fallos. Las herramientas nuevas están en los dos lados: en el de quien mira tu código desde fuera y en el de quien puede revisarlo antes.
Quién arregla lo que la IA encuentra
La parte que más dice del método es lo que pasó después de los hallazgos.
Willison y Alex Garcia trabajaron juntos en un repositorio privado. Para la mayoría de los problemas se repartieron el trabajo: uno escribía la prueba automatizada que dejaba el fallo a la vista y el otro implementaba la corrección. Con eso, cuentan, cada problema pasó por dos pares de ojos humanos, además de por los agentes, que corrían con modelos diferentes.
La herramienta llega hasta un punto. Un asistente señala algo sospechoso en un archivo, y a partir de ahí hace falta alguien que escriba la prueba que demuestra el fallo y alguien que lo arregle. Aquí eso lo hicieron ellos dos, repartiéndoselo.
La decisión de guardarse parte de las pruebas tiene detrás algo que ya contamos aquí: publicar la corrección de un fallo es publicar la pista para encontrarlo. Quien libera un parche avisa a todo el mundo de dónde estaba el agujero, y entre todo el mundo están los que buscan servidores sin actualizar.
A quién afecta esto, en tu caso
El anuncio dice que la mayoría de los problemas que corrigen afectan a las instalaciones que están en internet público y dan a usuarios autenticados acceso a datos privados. La mayoría, no todos. El aviso de actualizar que encabeza el anuncio es para cualquiera que lo tenga publicado.
Traducido a lo que tienes tú, eso es cualquier sitio donde alguien entra con usuario y contraseña y ve cosas que otros no deben ver. El área de clientes donde cada uno descarga sus facturas. La intranet en la que el equipo consulta precios. El panel donde tu gestoría te deja las nóminas.
La web que solo enseña la carta del restaurante tiene poco que perder ahí. La que tiene detrás las fichas de todos tus clientes, bastante más.
Cuatro preguntas sobre tu propio software
Estas valen tanto si tu web te la lleva una empresa como si la mantiene alguien de la casa.
- ¿Cuándo se revisó por última vez el código, y con qué? No cuándo se actualizaron los programas de base, que es otra cosa. Cuándo se miró el código que se escribió para ti.
- Cuando aparece un fallo, ¿se busca el mismo patrón en el resto? Es lo que hizo Datasette con sus rondas: cada problema encontrado se convierte en algo que buscar en el resto del código.
- ¿Quién arregla y quién comprueba? Si una herramienta propone un cambio en el código y ese cambio se aplica sin que una persona lo entienda, el problema se ha movido de sitio.
- ¿Cómo me entero de que se ha corregido algo? Deberías poder leer en algún papel qué se tocó y cuándo, aunque no entiendas el detalle técnico.
Lo que una revisión así no ve
Conviene saber dónde acaba. Una revisión del código encuentra errores de programación: permisos mal comprobados, entradas que no se validan, rutas que dejan pedir archivos que no tocaban.
Hay riesgos que no tienen esa forma. Si tu web lleva un asistente de inteligencia artificial que lee correos, formularios o documentos, hay un ataque contra él que no es un fallo del programa, es texto. Por eso ningún análisis del código lo encuentra. Son dos revisiones distintas y hacen falta las dos.
Dónde entramos nosotros
En nuestros planes Profesional y Empresarial hay una prestación de esta familia. Está publicada con estas palabras:
Cuando aparece una nueva generación de modelos de inteligencia artificial, revisamos con ella el código de tu proyecto, para detectar errores de programación que puedan afectar a la seguridad, y corregimos los que encontramos. No es una revisión periódica ni una auditoría de seguridad con informe: las correcciones que resulten las verás en las fichas de actualización que ya te enviamos.
Tres acotaciones. En el plan Básico no está incluida. Los planes de mantenimiento cubren los proyectos que desarrollamos nosotros, no una web hecha por otro. Y lo que se revisa es el código: el otro riesgo, el del asistente que se cree lo que lee, es otra cosa y no entra aquí.
Por dónde empezar
Coge las cuatro preguntas de arriba y hazle la primera a quien lleve tu web, seamos nosotros o no. Lo que te interesa es tener una respuesta, sea la que sea: es lo que te dice si alguien está mirando ese código o no lo mira nadie.
Otra cosa distinta, y por si te toca. Si estás dándole vueltas a una aplicación a medida y quieres saber cómo se mantiene una vez entregada, cuéntanos qué necesitas y te lo explicamos antes de que decidas.
Fuente: Simon Willison, «Datasette 1.0a39 and 0.65.4 security releases», blog de Datasette, 11 de septiembre de 2026. datasette.io/blog/2026/september-security-releases
