We Could Have Backdoored Bash

TL;DR: GNU Savannah hosts Bash, Coreutils, and hundreds of other GNU projects. Using Hacktron, we found that an email address like atouch${IFS}/tmp/savane-rce-proof@attacker.example gave any registered user code execution on its backend. From there, we made our account a superuser, impersonated Bash’s maintainer, and confirmed we could add an SSH key with push access to the upstream Bash repository. An unpatched kernel gave us root access and access to a GNU backup server. We reported it to the FSF on May 11, 2026.

We then ran Hacktron’s pentest across the rest of Savane to find further bugs and reported those too, bringing the total to 26 confirmed vulnerabilities. The FSF fixed them and published an incident report.

Savannah is where much of the GNU userland lives, including Bash and Coreutils, which provides commands such as ls, cp, and rm. It holds the repositories, the maintainer accounts, and the SSH keys that decide who can push. Code that lands there gets packaged by distributions and installed on millions of machines, and the xz backdoor showed what one compromised link in that chain can do.

Like much of the infrastructure free software depends on, it’s run by a handful of volunteers and FSF staff with limited resources. We wanted to put our resources to work there. Savannah runs Savane, a PHP application that is itself free software, so we pointed Hacktron at the source and audited it.

What came back is probably the most impactful bug we’ve ever found.

Savane let us register with this email address:

1

atouch${IFS}/tmp/savane-rce-proof@attacker.example

You know where this is going, right?

Savane’s email validator (frontend/php/include/account.php:275) accepts dot-atom addresses with characters like backticks, $, {}, /, and |. Most of these are technically allowed in the local part of an email address by the RFC, so the address above passes validation. Any user can set it at registration or through the email-change flow (frontend/php/my/admin/change.php:271).

Every logged-in user can manage a GPG key for their account, and Savane offers a “Test GPG keys” button at /my/admin/change.php?item=gpgkey. One of the checks it runs lists key fingerprints for the email address on the account. In frontend/php/include/gpg.php:

1

function test_gpg_command ($temp_dir, $command, &$ret, $in = null)

2

{

3

$cmd = gpg_name () . " --home '$temp_dir' $command";

4

...

5

$res = utils_run_proc ($cmd, $out, $err, $aux);

6

...

7

}

8

9

function test_listing ($temp_dir, $level, &$ret, $test_against_email = false)

10

{

11

...

12

if ($test_against_email)

13

{

14

$email = user_get_email (0);

15

...

16

}

17

$options = '--list-keys --fingerprint';

18

if ($test_against_email)

19

$options .= " $email";

20

$res = test_gpg_command ($temp_dir, $options, $ret);

21

}

The email is appended to $options as plain text, $options is concatenated into $cmd, and utils_run_proc() hands that string to proc_open(). With a string command, PHP runs it through /bin/sh. The shell sees our backticks and runs whatever is between them before gpg even starts. ${IFS} is there because the validator rejects spaces, and the shell expands it to one.

The FSF later traced the vulnerable path to the March 7, 2026, release of Savane (3.17-c369). It affected both savannah.gnu.org and savannah.nongnu.org, so the window was about two months.

To see how far it went, we swapped the payload for a reverse shell and landed on the backend as the web server user.

The web server user can read Savane’s configuration, which includes the database credentials, so there was nothing to crack. We set the superuser flag on our own account, harshjaiswal, and reloaded the page.

Superusers get a “Become this user” box in the sidebar, which lets a site admin act as any account without its password.

We typed chet into that box. Chet Ramey maintains Bash.

That’s his SSH key page, with an empty slot for one more. Savannah’s Git hosting is keyed off these entries, so adding a key here grants push access to bash.git as the maintainer. We confirmed the page accepted edits and stopped there. We did not add a key and we did not touch the repository.

An attacker in this position could have pushed a commit to upstream Bash under Chet’s name and done the same to Coreutils or any other project on Savannah.

The web shell was unprivileged. Savannah runs Trisquel GNU/Linux 11, with a linux-libre kernel built from Ubuntu 22.04’s 5.15 LTS kernel. That kernel was still affected by GameOver(lay), two OverlayFS bugs from 2023 (CVE-2023-2640 and CVE-2023-32629). Canonical fixed the 5.19 and 6.2 kernels back then, but the 5.15 kernel didn’t get a fix until USN-8255-1 on May 7, 2026, four days before our report. The public exploit worked on the first try and gave us root on the Savannah backend.

As root, we found a key that let us SSH to a GNU backup host as the gnubackup user.

At that point, we had root on the forge, access to its backups, and the ability to act as any maintainer. We stopped doing recon and wrote the report.

The RCE was one finding of many. After the initial report, we kept Hacktron running on the Savane codebase, which descends from the 2001 SourceForge code. It produced 33 findings; we threw out 7 false positives and sent the FSF the remaining 26 (2 critical, 6 high, 16 medium, 2 low) with file paths, line numbers, and reproduction steps. The notable ones:

Corwin Brust, a Savannah administrator, replied the same night. The FSF treated it as a full compromise: it patched the kernel, audited access controls, databases, and logs, and warned the operator of the other public Savane instance. The authorization bugs were fixed through a refactor rather than individual patches.

Thanks to Ineiev, Corwin Brust, and Bob Proulx from the Savannah hackers and the FSF sysops for working with us.

Hacktron brings together top CTF researchers, experienced red teamers, and offensive security researchers. We use AI to accelerate security research, finding and eliminating vulnerabilities in widely trusted software before malicious actors do. We’re continuing our research across the infrastructure the world depends on. If you’re responsible for securing some of it, we’d like to work with you through red teaming, pentests, or AI code review. Reach out at hello@hacktron.ai.