# How Bash could have been backdoored: the GNU Savannah flaw found by Hacktron - **Published on:** 2026-11-03 - **Category:** Security - **Original page:** https://free-linux.com/articles/hacktron-savannah-bash-supply-chain A command injection hidden in an email address gave two Hacktron researchers code execution on GNU Savannah, then root, and the ability to add an SSH key with push access to the Bash repository. They didn't, and no malicious code reached anyone. What broke, how the FSF responded, and how it compares with the xz backdoor. --- **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](/articles/history-of-bash-shell). Savannah runs on [Trisquel](/trisquel), and the 5.15 kernel advisories apply to [Ubuntu](/ubuntu) 22.04. **Sources:** [Hacktron: Securing Internet-Critical Software: How We Could Have Backdoored Bash](https://www.hacktron.ai/blog/hacking-gnu-savannah) · [FSF: Statement regarding GNU Savannah security reports](https://www.fsf.org/news/statement-regarding-gnu-savannah-security-reports) · [FSF: Update on GNU Savannah security issue (PDF)](https://static.fsf.org/nosvn/security/savannah-20260807.pdf) · [Andres Freund on oss-security about xz](https://www.openwall.com/lists/oss-security/2024/03/29/4) · [Wiz: GameOver(lay)](https://www.wiz.io/blog/ubuntu-overlayfs-vulnerability) · [Bash releases on ftp.gnu.org](https://ftp.gnu.org/gnu/bash/)