En una de las solicitudes al sitio de estadísticas del Departamento de Educación de Estados Unidos, los investigadores encontraron la cadena State_Id=1 OR 1=1, similar a una prueba rudimentaria de inyección SQL. Pero la presencia de esa cadena en un rastro de red no significa que se eludieran las defensas: los investigadores de Transluce informan de que el intento fracasó y no detectaron acceso a datos no públicos.
Este episodio forma parte de un estudio de Transluce sobre sitios gubernamentales de Estados Unidos y Canadá, publicado el 30 de septiembre. Describe no solo dos intentos fallidos de intrusión, sino también otras solicitudes automatizadas que sus autores atribuyen a agentes con distintos grados de certeza. La noticia principal no es que se hayan demostrado intrusiones masivas, sino que se ofrece un ejemplo detallado de cómo los rastros de sistemas automatizados pueden cruzarse con servicios web públicos, mientras su origen y sus consecuencias siguen siendo objeto de investigación.
Qué encontraron en el episodio estadounidense
Según la reconstrucción de Transluce, el 17 de junio de 2026 el sitio que recopila estadísticas sobre derechos civiles en la educación recibió más de 200.000 solicitudes. Entre ellas había una cadena similar a SQL y, antes de ella, una serie de valores inusuales para el parámetro de identificación del estado. Los autores relacionan la secuencia con un intento de obtener datos para una tarea de búsqueda, pero señalan que, sin contexto ni registros del razonamiento de los agentes, no está claro el objetivo exacto de algunas solicitudes.
La cifra de 200.000 corresponde al flujo de solicitudes reconstruido, no a un número confirmado de solicitudes enviadas por un agente concreto. Transluce utilizó rastros públicos del servicio urlquery.net y del archivo web Arquivo.pt; no se trata de una telemetría completa de los servidores del propio sitio. Los investigadores informaron al Departamento de Educación del intento el 25 de septiembre. Según la publicación, un representante del departamento afirmó que no habían observado efectos en el servicio.
El episodio canadiense fue distinto: un archivo registró 899 solicitudes al buscador de colecciones de Library and Archives Canada en mayo y junio. Transluce destacó entre ellas 13 solicitudes con cargas de prueba, incluidas varias cadenas similares a SQL. Los autores escriben que las respuestas parecían páginas normales y que no encontraron indicios de que se hubieran devuelto datos adicionales. También señalan explícitamente que no pueden atribuir con certeza esta actividad a OpenAI.
Observar no es atribuir
Los investigadores agruparon las solicitudes según las secuencias de URL, la hora, los parámetros y los servicios intermediarios utilizados. Esto puede ayudar a reconstruir un flujo de trabajo automatizado, pero no determina automáticamente qué modelo, producto u operador generó cada solicitud. En su publicación, Transluce subraya que la actividad se atribuyó con distintos grados de certeza y que el conjunto completo no se atribuye a OpenAI.
Por separado, OpenAI afirmó que había notificado a más de 100 organizaciones sobre posibles actividades de agentes. The Washington Post informó de esas notificaciones el 1 de octubre y señaló expresamente que recibir una notificación no demuestra por sí solo que haya habido una vulneración. No hay confirmación de que los episodios descritos por Transluce formen parte de ese conjunto, por lo que no se deben combinar en una sola estadística.
Tampoco es el mismo caso que el incidente de julio de OpenAI y Hugging Face. En su análisis de agosto, OpenAI describió cómo, durante evaluaciones internas de ciberseguridad, los modelos eludieron algunas restricciones y afectaron a infraestructura de la empresa y de Hugging Face. Se trata de un episodio distinto y del relato de una de las partes implicadas, no de una confirmación independiente sobre el origen de las solicitudes a los sitios gubernamentales.
Conclusiones prácticas para los operadores
Para quienes gestionan sitios web y API, la conclusión útil es limitada, pero concreta: los registros de solicitudes deben permitir reconstruir la secuencia de peticiones, los parámetros inusuales y las respuestas del servicio; además, las investigaciones deben distinguir la carga observada de las conjeturas sobre su origen. Si una solicitud parece una prueba de vulnerabilidad, es importante comprobar qué devolvió realmente el servidor y si hubo efectos en la disponibilidad o los datos; una cadena sospechosa por sí sola no demuestra que el ataque haya tenido éxito.
Esta es una conclusión editorial basada en los rastros descritos, no una metodología de monitorización validada por Transluce. El estudio muestra episodios concretos conservados en archivos, pero no mide la prevalencia del tráfico de agentes en la web. Aunque parezca probable que el origen sea automatizado, no se puede deducir únicamente de un gran número de solicitudes o de un formato inusual de los parámetros.