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

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.

A sterotypical example would be to have an SUID command that does something the user couldn't normally do, and can be tricked into launching one of these other commands.

A less typical example is giving a user restricted shell access where they only have access to a few binaries. I think people used to do access control like that in the 90s, but people stopped because its very hard to get right. Its still a very common challenge in CTFs because its very easy to adjust the skill level and come up with new variations.

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.