GNU Savannah hosts Bash, Coreutils, and hundreds of other GNU projects. Using Hacktron, we found that an email address like a`touch${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.

The full chain, step by step:

Why Savannah

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 serious bug we’ve ever found: a route from a registered account to push access on upstream Bash.

The bug: an email address that runs commands

Savane let us register with this email address:

a`touch${IFS}/tmp/savane-rce-proof`@attacker.example

You know where this is going, right?

The validator

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).

The sink

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.

Exploiting it takes four steps:

1. Register with the payload above as your email address, or change an existing account’s email address to it. The app accepts it.

2. Open /my/admin/change.php?item=gpgkey.

3. Paste any GPG key and click “Test GPG keys”.

4. The command inside the email runs on the server as the web server user.

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.

From a shell to superuser

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:

Savannah home page with the sidebar reading harshjaiswal logged in as superuser, above a Become this user box

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

Becoming Bash’s maintainer

We typed chet into that box. Chet Ramey maintains Bash. This is his SSH key page, with an empty slot for one more:

Change Authorized Keys page logged in as chet, with key slots 1 to 4 blurred and slot 5 empty

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.

Root and a backup server

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:

gnubackup@terror:~ $ cat .ssh/authorized_keys
cat .ssh/authorized_keys
<REDACTED>
gnubackup@terror:~ $ exit
exit

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 rest of Savane

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, which left 26 (2 critical, 6 high, 16 medium, 2 low), including the RCE. We sent the FSF the other 25 with file paths, line numbers, and reproduction steps. The notable ones:

Working with the FSF

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.

Disclosure timeline

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

Work with the team behind this research

Hacktron’s team includes CTF researchers, red teamers, and offensive security researchers. We use AI to find vulnerabilities in widely used software before attackers do, and we’re continuing that work across other infrastructure. If you’re responsible for securing infrastructure like this, we’d like to work with you through red teaming, pentests, or AI code review. Reach out at hello@hacktron.ai.