Una dirección de correo electrónico con una orden escondida entre comillas invertidas bastó para que los investigadores de Hacktron ejecutaran código en el servidor de GNU Savannah, la forja de la Free Software Foundation (FSF) donde se desarrollan Bash, Coreutils y cientos de proyectos GNU. Desde ahí se hicieron superusuarios, suplantaron al mantenedor de Bash, Chet Ramey, y comprobaron que podían añadir una clave SSH con permiso de escritura en el repositorio oficial del intérprete.
Las claves del fallo de GNU Savannah que expuso el repositorio de Bash en 30 segundos
- Hacktron encontró una inyección de órdenes en Savane, el software de Savannah, al probar claves GPG con un correo manipulado.
- Encadenada con GameOver(lay), un fallo del núcleo de 2023, permitió obtener root y acceso a un servidor de copias de GNU.
- El aviso llegó el 11/05/2026 y la FSF instaló el núcleo corregido el 14/05/2026.
- La FSF no halló indicios de que se tocara código ni credenciales, y Hacktron asegura que no añadió ninguna clave.
El caso lo ha contado Hacktron, una empresa de auditoría de seguridad que usa inteligencia artificial para revisar código, en una entrada firmada por Harsh Jaiswal y Rahul Maini y publicada a finales de octubre. La FSF ya había adelantado una declaración el 19/06/2026 y un informe técnico con los parches el 07/08/2026. No hay constancia de que nadie aprovechara el fallo con fines maliciosos, pero la cadena de explotación describe con bastante precisión cómo se podría haber colado código ajeno en una de las piezas de software más instaladas del mundo.
Un correo con comillas invertidas como puerta de entrada
Savannah funciona con Savane, una aplicación PHP que desciende del código de SourceForge de 2001. Su validador de correos aceptaba caracteres que el estándar permite en la parte local de una dirección, como las comillas invertidas, el símbolo del dólar o las llaves. Los investigadores registraron una cuenta con una dirección que contenía una orden entre comillas invertidas y usaron la variable ${IFS} para sustituir los espacios, que el validador sí rechazaba.
El problema aparecía en la función que permite a cualquier usuario registrado probar su clave GPG. Savane construía una línea de órdenes para GPG concatenando el correo de la cuenta como texto y la entregaba a proc_open() como cadena, de modo que PHP la ejecutaba a través de /bin/sh. El intérprete veía las comillas invertidas y ejecutaba lo que había dentro antes de lanzar GPG. Según Hacktron, bastaba con registrar el correo, abrir la página de gestión de claves, pegar cualquier clave y pulsar el botón de prueba.
Con una shell como usuario del servidor web, los investigadores leyeron la configuración de Savane, que incluía las credenciales de la base de datos, y activaron la marca de superusuario en su propia cuenta. Los superusuarios de Savannah tienen una opción para actuar como cualquier otro usuario sin conocer su contraseña. La usaron con la cuenta de Chet Ramey y llegaron a la página de sus claves SSH, que es la que decide quién puede escribir en bash.git. Hacktron afirma que se detuvo ahí: «We did not add a key and we did not touch the repository».
El salto a root vino después. Savannah usa Trisquel GNU/Linux 11 con un núcleo linux-libre derivado del 5.15 de Ubuntu 22.04, y ese núcleo seguía afectado por GameOver(lay), dos fallos de OverlayFS de 2023 (CVE-2023-2640 y CVE-2023-32629). Canonical los corrigió entonces en las ramas 5.19 y 6.2, pero según el informe de la FSF la rama 5.15 no figuró como corregida hasta el aviso USN-8255-1 del 07/05/2026, con la versión 5.15.0-177.187. Hacktron indica que el exploit público funcionó al primer intento y que, ya como root, encontró una clave para entrar por SSH como usuario gnubackup en un servidor de copias de seguridad de GNU.
Qué corrigió la FSF y dónde no coinciden las fuentes
El aviso llegó a la lista privada de los administradores de Savannah el 11/05/2026 y Corwin Brust lo confirmó al día siguiente. El 14/05/2026 la FSF instaló el núcleo 5.15.0-177.187+11.0trisquel31 y eliminó la cuenta de los investigadores. Su informe explica que trató el incidente como algo más que un parche de aplicación: revisó controles de acceso, bases de datos y registros, y avisó al operador de otra instancia pública de Savane. La inyección se corrigió pasando el correo a GPG como dato y no como texto dentro de una orden de shell, y los fallos de autorización se resolvieron reescribiendo partes del código. Hacktron agradece el trabajo de Ineiev, Corwin Brust y Bob Proulx.
Tras el primer aviso, Hacktron siguió auditando Savane y dice haber enviado 26 vulnerabilidades confirmadas (2 críticas, 6 altas, 16 medias y 2 bajas) después de descartar 7 falsos positivos. La FSF matiza ese recuento: su informe sostiene que varios hallazgos no se aplicaban a sus sistemas, que en algunos casos no pudo reproducirlos y que dos fallos de tipo XSS (inyección de código en páginas web) resultaron ser falsos positivos tras su revisión. Su actualización pública solo detalla los hallazgos HCK-001 a HCK-008.
La mayor discrepancia está en la ventana de exposición. El informe de agosto de la FSF y Hacktron sitúan el origen del fallo en la versión 3.17-c369 de Savane, del 07/03/2026, lo que deja unos dos meses de exposición en savannah.gnu.org y savannah.nongnu.org. En cambio, la declaración de junio de la propia FSF decía que las vulnerabilidades estaban en software publicado unos dos años antes, y algunos medios repitieron entonces que el fallo llevaba dos años abierto. Es posible que la frase se refiriera al conjunto de fallos y no solo a la inyección, pero la FSF no lo aclara. También hay medios que fechan el aviso en mayo de 2025, cuando las fuentes primarias hablan de 2026.
Tampoco está claro el identificador. Ni Hacktron ni la FSF citan un CVE para la inyección de órdenes. El único registro público localizado, CVE-2026-56355, describe un uso de datos no confiables en la autorización de Savane hasta la 3.17, con una puntuación CVSS de 3,7 (baja), y apunta a otro fichero del código, así que no corresponde a la ejecución remota descrita.
Por qué no es otro caso xz y qué deben revisar los administradores
Hacktron compara el hallazgo con la puerta trasera de xz (CVE-2024-3094), descubierta por Andres Freund en marzo de 2024 en las versiones 5.6.0 y 5.6.1. La diferencia es importante: en xz hubo código malicioso publicado, mientras que en Savannah solo hubo una posibilidad demostrada. Además, las versiones de Bash se distribuyen como paquetes firmados por Ramey, así que un cambio introducido en el repositorio tendría que pasar por él antes de llegar a una versión publicada. Eso reduce el riesgo, aunque no lo elimina: un atacante con acceso de root a la forja y a sus copias habría tenido margen para preparar algo menos visible. No es el primer susto reciente en el software de GNU, como mostró el fallo crítico en telnetd de GNU InetUtils a comienzos de año.
Para quien administra sistemas, estas son las comprobaciones prácticas que se desprenden del caso:
- Núcleo 5.15 en Ubuntu 22.04 y derivadas. Con
uname -rse ve la versión en uso. Según la FSF, la primera corregida frente a GameOver(lay) en esa rama es la 5.15.0-177.187 (USN-8255-1). Las derivadas como Trisquel 11 tienen su propia numeración, como la 5.15.0-177.187+11.0trisquel31 que instaló Savannah. - Instancias propias de Savane. Las versiones hasta la 3.17 están afectadas. Conviene aplicar los parches publicados por la FSF el 07/08/2026, revisar los correos registrados en busca de caracteres de shell y, si hay dudas, contactar con la FSF, que ofrece orientación a quien aloje su propia forja.
- Código PHP propio. Pasar a
proc_open()una cadena implica invocar la shell. Desde PHP 7.4 la función acepta un array de argumentos que evita ese paso, y es la forma más segura de llamar a herramientas externas con datos de usuario. - Paquetes de código fuente. Quien compile Bash u otras herramientas GNU debe verificar la firma con
gpg --verifyusando una clave obtenida por más de una vía, y comparar el paquete con la etiqueta correspondiente del repositorio. Los paquetes de las distribuciones y las compilaciones reproducibles añaden otra capa de control.
La FSF también ha dicho que se comunicará directamente con los proyectos alojados en Savannah para indicarles cómo revisar y reforzar su seguridad. Los mantenedores de esos proyectos tienen motivos para repasar las claves SSH y GPG asociadas a sus cuentas, aunque la fundación no ha detectado accesos indebidos.
Preguntas frecuentes
¿Llegó código malicioso a Bash por este fallo?
No hay indicios de ello. Hacktron asegura que no añadió ninguna clave ni modificó el repositorio, y la FSF afirma que no encontró accesos a datos sensibles ni compromiso de la cadena de suministro de Savannah.
¿Qué versiones de Savane estaban afectadas?
La inyección de órdenes entró con la versión 3.17-c369, publicada el 07/03/2026. La FSF publicó los parches de Savane el 07/08/2026 junto a su informe del incidente.
¿Cómo sé si mi servidor Ubuntu 22.04 es vulnerable a GameOver(lay)?
Si usa el núcleo de la rama 5.15, basta con comprobar con uname -r que la versión es igual o posterior a la 5.15.0-177.187, la que el aviso USN-8255-1 marca como corregida según la FSF.
¿Por qué el fallo no habría bastado para distribuir un Bash manipulado?
Porque las versiones de Bash se publican como paquetes firmados por su mantenedor, Chet Ramey. Un cambio en el repositorio tendría que pasar por él antes de llegar a una versión oficial, aunque esa barrera no es infalible.
Fuentes:
- Hacktron: Securing Internet-Critical Software: How We Could Have Backdoored Bash
- FSF: Statement regarding GNU Savannah security reports (19/06/2026)
- FSF: Update on GNU Savannah security issue (07/08/2026, PDF)
- Tenable: CVE-2026-56355
- iTnews: Flaw in GNU’s code forge could have let attackers backdoor Bash
- oss-security: aviso de Andres Freund sobre xz (29/03/2024)
- LinuxGratis: Cómo se pudo meter una puerta trasera en Bash
