But you would already have to have shell access to the system to execute those commands, right?

But that sort of access is only a social engineer away. People still click on stuff in emails, or run commands because a computer says so.

...or something that runs CGI commands. Bash scripts are like the glue of the internet, and many of them are poorly-written. Tons of stuff still runs on PHP or relies on little Python cron jobs behind the scenes. A lot of the way this stuff works depends on being able to chain vulns together...an unescaped query to a database that gets piped to a nightly cron job to sync or backup something becomes an attack vector.

You might have WiFi access to mtr, allowing you to traceroute as root but not launch a shell or read files. But with these tools you can escalate.

Like it says in the preamble on the site, don't think of this as a collection of exploits, but rather as a compendium of knowledge about escalation techniques for use in emergencies.

I can't tell you how many times I burned my fingers as a young Unix developer in the 80's by untar'ing things wrongly, or fat-fingering an 'rm -rf /' and thus having a running system that will be catastrophic if I don't fix it before reboot, shell still active and .. what do? Consult this list of great advice and use it to rebuild the system and/or do things that need to be done that otherwise wouldn't be possible ..

GTFOBins is not just for hacking. Its also for system repair and recovery. I'd be as likely to consult this knowledge base after a hacker attack as before, if not more ..

[dead]

Not just shell access, but the server would need to be configured to also enable your user to run any of these binaries as root (such as an administrator putting them in the sudoers file).

So they're a pretty niche attack vector, and oftentimes crop up as a result of lazy/incompetent sysadmins.