There’s a category of technical discovery I find genuinely hard to shake. Not the kind where you learn a new tool or a better pattern. I mean the kind where something you’ve been working with for years reveals a whole other dimension to itself that nobody mentioned when they handed it to you.
GTFOBins is that, times about three hundred binaries.
It hit the front page of Hacker News this week with over 300 points and 80-plus comments, and the discussion was one of the more interesting security threads I’ve seen in a while. But let me back up.
What GTFOBins actually is
GTFOBins stands for “Get The F*** Out Binaries.” It’s a curated project on GitHub that has been cataloging something specific since 2018: standard Unix executables that can be abused to bypass security controls in misconfigured systems. Not new exploits. Not vulnerabilities in the traditional sense. Just… what these tools are capable of, documented carefully, organized by technique.
The site is careful about this framing. From their own description: “This is not a list of exploits, and the programs listed here are not vulnerable per se. Rather, it is a list of programs that can be used to get things done from a limited or restricted environment.”
That qualifier – “not vulnerable per se” – is the part I keep coming back to.
The categories GTFOBins documents are: shell escape, file read, file write, command execution, reverse shell, bind shell, privilege escalation, and file transfer. And each technique is mapped to different privilege contexts: running as an unprivileged user, running under sudo, running as a SUID binary, or running with Linux capabilities. Hundreds of binaries. All of them standard Unix tools you almost certainly have installed right now.
Some scenarios worth sitting with
Let me walk through a few of these, because the abstract description doesn’t quite communicate how quietly alarming this gets once you see it applied.
The vim sudo trap. You’re a sysadmin. A junior engineer needs to edit the nginx config. You add a sudo rule: they can run vim /etc/nginx/nginx.conf as root. Specific file, specific binary. Looks contained. Except, as GTFOBins documents, once you’re inside vim you can run :!/bin/bash. That drops you into a root shell. The nginx config file was irrelevant. less is the same story – sudo less /var/log/nginx/error.log, then type !bash at the prompt, same result. Any editor with a shell escape has this property.
This is one of those things that, once you see it, you start auditing every sudo rule you’ve ever written.
The tar checkpoint. Someone on your team needs to run backups. You add tar to the sudo allowlist. Reasonable. GTFOBins documents that tar cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec=/bin/sh produces a shell. The --checkpoint-action flag is a legitimate tar feature – it runs a command at progress checkpoints. It exists for good reasons. It also means that if tar runs under sudo without explicit argument restrictions, you’ve effectively handed someone a root shell wrapped in a backup utility.
The tcpdump -z scenario. This one came up specifically in the HN discussion, and it’s a good example of how these things get past even careful reviewers. You add tcpdump to the sudo allowlist so your team can capture traffic for debugging. Someone reviewing that sudo rule sees “network capture tool” and approves it. What they might not notice is that tcpdump has a -z flag for post-rotation compression: when a capture file rotates, it runs an external command on the old file. If an attacker can write to the path being passed to -z, they can execute arbitrary code. The tool is behaving exactly as designed. The security model just didn’t account for what “exactly as designed” included.
You could go through this list for a while. python can execute shell commands. perl can spawn processes. awk can write files. nmap has a scripting engine that runs Lua. Each of these is a feature. Each of these can be the difference between a limited foothold and full system compromise.
There’s something new happening in 2026
I want to flag something that surfaced in this week’s HN thread, because I think it matters.
Multiple people noted that LLM agents – things like Claude and similar tools given restricted access to a system – are independently rediscovering GTFOBins-style techniques. One commenter described watching an agent automatically write a PowerShell script when blocked from using a preferred tool directly. The script achieved the same outcome. Another person described a case where chmod was blocked, so a python -c "import os; os.chmod(...)" workaround was used instead. That exact technique now appears in LLM-generated code.
The point isn’t that AI is malicious. The point is that allow-lists and block-lists are running into their fundamental limit: a sufficiently capable system, human or otherwise, will navigate toward the path that works. GTFOBins is, in some sense, already a map of that path. The attackers have read it. And now, apparently, so have the models.
I myself have witnessed our own AI bots work very creatively to circumvent some very purposely placed guardrails in order to eagerly answer a question or find a solution. AI’s eagerness, while mostly positive, also breeds this type of creative circumvention behaviour. “Rules” and “RULES” and “MUST FOLLOW AT ALL TIMES RULES” help, but never eliminate.
Security is genuinely hard, and I think that’s worth saying plainly
I’ve been running production infrastructure since 2009. I’ve had customers get breached despite doing almost everything right. And the thing I keep coming back to is that the attack surface isn’t just your exposed services or your unpatched packages. It’s every tool you’ve installed, every permission you’ve granted, every binary on the path.
GTFOBins is a useful reminder that trust is not binary. “I gave them access to this one thing” needs to account for what that one thing is actually capable of. Granting someone access to tar is not the same as granting them a shell – until the configuration says otherwise, and sometimes the configuration says otherwise in ways that weren’t obvious when you wrote it.
What this doesn’t mean is that you should panic or try to strip your servers down to nothing. You can’t run meaningful infrastructure that way. What it means is that the mental model of minimal, contained permissions is harder to achieve in practice than it looks on paper. Every tool that does multiple things is a potential bypass for a control that was only thinking about one of those things.
The 2021 HN thread on GTFOBins had a commenter who put it well: “sudo is a great tool for limiting coworker access and a terrible tool for limiting adversarial access.” That’s not a cynical take. It’s an accurate description of what the threat model for most sudo configurations actually covers.
Defense in depth, containerization, careful sudo configuration with argument restrictions, continuous monitoring – these all help. But I think the most honest advice is also the simplest one: stay curious about what your tools can actually do, stay skeptical of configurations that look neat on the surface, and assume that any binary on your system is more capable than the single purpose you installed it for.
GTFOBins is worth bookmarking. Not because someone on your team is going to attack you. Because understanding how your tools can be misused is part of understanding what your actual security posture is. And honestly, I find it fascinating that a curated list of standard Unix tools keeps surfacing on Hacker News year after year, because every time it does, there’s a new angle nobody had thought of yet.