arsenal-ng, a searchable command reference for penetration testing tools

What the tool is and where it came from

arsenal-ng is described as the classic launcher, evolved. It is a modern pentest command launcher written in Go, with a badge counting 248 tools and 2940 commands.

The lineage is stated in the README. It was inspired by the arsenal project from Orange-Cyberdefense and rewritten from scratch with a focus on simplicity, speed and developer experience. That original project is the well known one in the security community, a collection of cheatsheets for command line security tools, and it was a Python program with a curses interface. The rewrite keeps the idea and changes the implementation.

The licence is MIT, the language is Go, and the README badges say Go 1.24.0 or newer and Linux or macOS. The last push was on 2026-09-25, and the releases v1.6, v1.7 and v1.8 came in August and September 2026, so this is a project with a steady release cadence rather than a one-off port.

The scope is worth stating plainly. This is a reference and launcher for the invocations of existing tools. It does not implement scanning, exploitation or credential handling itself. What it does is let you find the right invocation quickly, fill in the arguments, and put it in front of you to edit before it runs, which is the difference between a cheat sheet you read and one you use.

That distinction also frames the intended use. The topics list includes bugbounty, penetration-testing, red-team, infosec and hacking, and the tool is aimed at people working in those roles, which in a professional context means authorised testing. The cheat sheet content is public knowledge about how tools are invoked.

Installing it and the platform constraints

There are three installation routes and the README gives the command for each.

The first is a Go install:

go install -v github.com/halilkirazkaya/arsenal-ng/cmd/arsenal-ng@latest

The note attached to it says Go 1.24.0 is required and that the Go bin directory needs to be on your PATH.

The second is the distribution package, and this is the route worth knowing about. Kali Linux ships arsenal-ng in its official repositories, with a package tracker linked, and the install is:

sudo apt install arsenal-ng

For anyone working in security tooling, having it in the Kali repositories means it arrives with the rest of the toolset and is updated with the distribution rather than by hand.

The third is building from source, which is a clone and a make:

git clone https://github.com/halilkirazkaya/arsenal-ng.git
cd arsenal-ng
make build
./bin/arsenal-ng

The Makefile is a single target. The build rule is a go build with the -s and -w linker flags to strip the symbol table and debug information, writing the result to bin/arsenal-ng from the cmd/arsenal-ng package. A .goreleaser.yaml at the top level suggests the release binaries for the other platforms are produced by GoReleaser rather than by hand.

The platform support table is where the one real limitation sits. Linux is fully supported but requires a kernel 6.2 or newer configuration for terminal prefill, which is described in detail further down. macOS is fully supported and works out of the box with no additional configuration. Windows is marked as WSL only, with native command prompt and PowerShell explicitly unsupported.

The optional alias section is a nicety rather than a feature. You can add a short alias such as a for arsenal-ng to your shell configuration, with a zsh and a bash example, and source the file to make it take effect immediately.

The terminal prefill problem and how the README handles it

The Linux configuration section is the most interesting part of the README, and it is a security problem rather than a feature.

arsenal-ng relies on the TIOCSTI ioctl to prefill the terminal buffer, and the README explains that the ioctl is disabled by default in newer Linux kernels for security reasons. That is correct: allowing a process to inject characters into another process's terminal input is a serious capability, and several distributions disabled it as a hardening measure after it was abused.

The first option is to enable TIOCSTI globally. The README gives a temporary form for the current session and a permanent one that writes a sysctl file and reloads the configuration:

# Temporary (current session only)
sudo sysctl -w dev.tty.legacy_tiocsti=1

# Permanent (survives reboot)
echo "dev.tty.legacy_tiocsti=1" | sudo tee /etc/sysctl.d/99-tiocsti.conf
sudo sysctl --system

The second option is narrower. Instead of changing a system-wide setting, you grant the CAP_SYS_ADMIN capability to the arsenal-ng binary alone:

# Ensure 'setcap' is installed (Debian/Kali/Ubuntu)
sudo apt-get install libcap2-bin

# Grant the required capability to the binary
sudo setcap "cap_sys_admin+ep" $(which arsenal-ng)

The README is candid about the cost of that option, saying CAP_SYS_ADMIN is powerful and virtually equivalent to root access, and that the method should only be used if you fully understand the risks.

That candour is the point. This is the only part of the tool that touches the security of the machine it runs on, and the README states the trade rather than burying it. For an assessment workstation that is your own and is used only for authorised testing, the narrow capability route is defensible. On a shared or general-purpose machine, enabling TIOCSTI globally is a change that affects every program on the system, and the safer answer is to use the tool without the prefill feature, or to use macOS where the README says no configuration is needed.

One practical detail worth noting: the capability has to be set on the binary, so a fresh install or an upgrade that replaces the file loses it, and the capability has to be reapplied.

How the interface works and what it gives you

The tool opens a terminal interface with all available commands, and the workflow the README describes has five steps. You type keywords to search, use the arrow keys to browse the results, press Enter on the one you want, fill in any placeholders, and press Enter again to write it to the terminal input buffer. It then sits there for you to edit before you run it.

That last point is the design decision that distinguishes this from a simple cheatsheet browser. The command is not executed for you. It is placed in your input buffer, which means you see exactly what is about to run, you can adjust it, and nothing happens without a second deliberate action.

The search is described as smart and multi-word, running across tool names, titles, tags, descriptions and commands, so you can search for something like nmap scan or ffuf and get results that match on any of those fields rather than only on the command text.

The feature table lists the rest. Instant startup from a single binary with no dependencies. Syntax highlighting so commands are colour coded. Coloured tags where each tag gets a consistent distinct colour based on a hash, which is for quick visual identification rather than for meaning. A simple YAML format for the cheatsheets, described as easy to maintain and extend. An argument system supporting {{arg}} and {{arg|default}} placeholders with auto-completion. Global variables that you set once and use everywhere, with the variables auto-filling in all commands. A tools view that browses all available tools with command counts in a paginated table. Command hints for the special commands. A built-in help screen reached with the question mark key, covering all the shortcuts. And the terminal integration itself, which is the mechanism described above.

The global variables feature is the one that changes how you work. Setting a target once means every command that references it picks it up, so the workflow in the README's example session is to set target to an address, search for nmap, pick the stealth scan entry, and the placeholder is already filled in. The special commands are set key=value, unset key, variables to list what is set, and tools to show the catalogue.

The implementation and how it compares

The dependency list tells you the interface approach, and the Go module is small and deliberate. The direct dependencies are the Charm libraries for the terminal interface, bubbles for the components, bubbletea for the framework and lipgloss for styling, plus golang.org/x/sys and gopkg.in/yaml.v3 for the cheatsheet files. The indirect list is the usual tail of those libraries, including the terminal handling packages, the clipboard integration, the OSC 52 terminal escape handling and the Unicode width library.

Bubble Tea is worth a brief explanation for anyone who is not a Go terminal developer. It is an architecture in which the program is a model, a view and an update function over messages, which is what makes the keyboard handling in this tool consistent across the search view, the argument input view, the tools table and the help screens without each of them implementing its own key handling. The keybinding tables in the README are the visible result.

The repository layout is conventional: a cmd/ directory with the entry point, an internal/ directory for the implementation, a Makefile, a .goreleaser.yaml for releases, a SECURITY.md, and an assets/ directory holding the demonstration GIFs used in the README. There is no cheatsheet directory at the top level, which suggests the YAML files are compiled into the binary, consistent with the single binary and no dependencies claim.

The comparison to make is with the original Python arsenal and with the plain text cheatsheet repositories that circulate for these tools. Against the original, the differences are the ones the README claims. A Go binary starts in milliseconds rather than loading a Python interpreter, the search is fuzzy and multi-field rather than substring based, and the interface is a modern terminal framework rather than curses. Against plain text files, the differences are the argument placeholders, the global variables and the search across descriptions and tags, none of which a directory of markdown files can do.

The honest limitation is the platform split. Windows users must use WSL, which means the tool is available in a Linux environment they may not otherwise use, and the macOS path is smooth while the Linux path requires a system-level change that many hardened configurations have deliberately disabled. That is the trade for the terminal prefill feature, and the README makes it visible rather than burying it, which is the behaviour you want from a tool that asks for a capability this powerful.

Editorial conclusion

Adopt arsenal-ng if you work in an authorised security testing role and want a searchable reference of tool invocations instead of a folder of text files, and you are comfortable with the terminal integration it requires. Skip it if you are on Windows without WSL, since native command prompt and PowerShell are unsupported. Verify first by installing the release binary on Linux or macOS, and by checking whether the terminal prefill feature works in your terminal before you rely on it, since that depends on a kernel or capability setting.

Frequently asked questions

Official sources

1. halilkirazkaya/arsenal-ng on GitHub
2. Issues
3. License: MIT
4. README
5. Releases