How Bash could have been backdoored: the GNU Savannah flaw found by Hacktron

GNU Savannah is the forge behind Bash, Coreutils and hundreds of other GNU projects. It holds the repositories, the maintainer accounts and the SSH keys that decide who can push. On 30 October 2026, Harsh Jaiswal and Rahul Maini of the security firm Hacktron described how they went from a freshly registered account to holding write access to the upstream Bash repository. The title of their write-up, How We Could Have Backdoored Bash, sums it up: they could have, and they chose not to.

An email address that ran commands

Savannah runs Savane, its own web application. Version 3.17-c369, released on 7 March 2026, introduced a vulnerable path in the feature that checks a user’s GPG key against the email address on the account. The code built a command line containing that address and ran it through proc_open(), which goes via /bin/sh. Because the email validator let shell metacharacters through, registering with something like a`touch${IFS}/tmp/savane-rce-proof`@attacker.example and clicking the button to test a GPG key was enough to make the server run whatever sat between the backticks. The irony is hard to miss: the hole was in a tool meant to strengthen trust in signatures.

From there the chain was short:

1. With a shell as the web server user, they read the configuration and the database credentials.
2. They flagged their own account as a Savannah superuser.
3. Using the “become this user” feature, they opened the account of Chet Ramey, who has maintained Bash for more than three decades, and confirmed that the SSH key page, which controls push access to bash.git, accepted edits.
4. Separately, the server’s kernel was still exposed to GameOver(lay) (CVE-2023-2640 and CVE-2023-32629), two OverlayFS bugs with a public exploit. That gave them root, and with it an SSH key for the gnubackup user on a GNU backup host.

Savannah runs Trisquel 11 with a linux-libre kernel derived from Ubuntu 22.04’s 5.15. Canonical fixed GameOver(lay) for the 5.19 and 6.2 series back in 2023, but 5.15 wasn’t marked fixed until USN-8255-1 on 7 May 2026, four days before Hacktron’s report.

The repository was never touched

The researchers stopped at the key page. In their words: “We did not add a key and we did not touch the repository.” The FSF reached the same conclusion after reviewing access controls, databases and logs: it found no reason to believe sensitive project data or credentials were accessed, “nor that there has been any compromise of Savannah’s software supply chain”. No malicious code made it into Bash or into any release. The web flaw was exposed for roughly two months, from March to May 2026.

How the FSF responded

The report reached Savannah’s private list on 11 May 2026. Corwin Brust acknowledged it the next day, and on 14 May the FSF installed the fixed kernel (5.15.0-177.187+11.0trisquel31) and removed the researchers’ account. The foundation treated it as a full compromise rather than a simple application patch: it reviewed the systems, warned the operator of another public Savane instance and, instead of fixing bugs one by one, volunteers Ineiev, Corwin Brust and Bob Proulx rewrote the affected code. The injection fix passes the email address to GPG as a data argument instead of pasting it into a shell string.

Hacktron kept auditing Savane with its AI-assisted tooling and reported 26 vulnerabilities (2 critical, 6 high, 16 medium, 2 low), including authorisation bypasses in site configuration, mailing-list administration and private file access. The FSF issued a statement on 19 June and published its incident report and patches on 7 August. That report notes that some findings couldn’t be reproduced on the live system and that two of the XSS reports were false positives, because the input was sanitised elsewhere.

How it compares with xz

Hacktron points to the xz-utils backdoor (CVE-2024-3094) as an example of what one compromised link can do. The comparison holds, with caveats.

In xz, the attacker, posting as Jia Tan, spent about two years earning the project’s trust until becoming a co-maintainer. Releases 5.6.0 and 5.6.1 carried a payload hidden in test files in the repository plus a modified build-to-host.m4 that only existed in the release tarballs, not in git. Since the tarballs were signed by someone with legitimate rights, the signatures checked out. It reached development branches of Debian, Fedora and openSUSE before Andres Freund caught it on 29 March 2024 while chasing why sshd logins were taking half a second longer.

The Bash scenario was different: a quietly added SSH key to write to git, without Ramey’s GPG key. A rogue commit doesn’t reach users by itself, since Bash ships as tarballs signed by Ramey himself on ftp.gnu.org, so the change would have had to slip into his work before a release. That’s a real barrier, though not a perfect one: a small change can go unnoticed, and anyone building Bash straight from git would have pulled it unfiltered. Root on Savannah and on a backup host is also, on its own, a position from which more patient attacks can be prepared.

Takeaways for sysadmins

There’s nothing to update in Bash because of this. It does reinforce a few habits:

• Verify tarball signatures. For any GNU package: gpg --verify bash-5.3.tar.gz.sig bash-5.3.tar.gz, using a maintainer key obtained through more than one channel (the gnu-keyring.gpg keyring, a previously verified release or the fingerprint the project publishes), not just the same server as the download.
• Compare the tarball with the git tag. The xz lesson is that what’s released may not match the repository. A diff between the tarball and a git archive of the tag, ignoring autotools output, exposes files that shouldn’t be there.
• Lean on your distro’s packaging. Debian checks signatures with uscan and the key in debian/upstream/signing-key.asc; Fedora has the %gpgverify macro for spec files. Reproducible Builds lets you confirm a binary really comes from the declared sources.
• Check kernels on Ubuntu 22.04. Any machine still on 5.15 without USN-8255-1 leaves GameOver(lay) open to anyone with an unprivileged shell, exactly as on Savannah.
• Update Savane if you run your own instance.

For background on the shell at stake, see our history of Bash and the Unix shell. Savannah runs on Trisquel, and the 5.15 kernel advisories apply to Ubuntu 22.04.

Sources: Hacktron: Securing Internet-Critical Software: How We Could Have Backdoored Bash · FSF: Statement regarding GNU Savannah security reports · FSF: Update on GNU Savannah security issue (PDF) · Andres Freund on oss-security about xz · Wiz: GameOver(lay) · Bash releases on ftp.gnu.org