# airgeddon: a Bash toolkit for auditing wireless networks on Linux

> airgeddon wraps aircrack-ng, hostapd, reaver and other wireless tools behind a menu-driven Bash script. It is built for Linux auditors, and the README points to the wiki for everything else, including the Docker route.

**v1s1t0r1sh3r3/airgeddon** — This is a multi-use bash script for Linux systems to audit wireless networks.

- Repository: https://github.com/v1s1t0r1sh3r3/airgeddon
- Stars: 8,030 · Forks: 1,339
- Language: Shell
- License: GPL-3.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/v1s1t0r1sh3r3-airgeddon

## What airgeddon is for, and who ends up using it

The repository describes airgeddon in one line: a multi-use bash script for Linux systems to audit wireless networks. That sentence carries more weight than it looks. The subject is wireless networks, the platform is Linux, and the deliverable is a script, not a daemon or a service. The topics list on the repository names the techniques the menus expose: handshake capture, PMKID, pixie dust, WPS, evil twin, denial-of-service, enterprise, sniffing and sslstrip, across WEP, WPA/WPA2/WPA3 and multi-band targets.

The audience follows from that. Someone auditing their own wireless estate, a pentester working a wireless scope, or a learner who wants the individual tools (aircrack-ng, reaver, hostapd, bettercap) reachable without memorising each invocation. The value is orchestration: an interactive menu picks the technique, and the script assembles the underlying commands. If you already have a working pipeline of your own, the menu is not the part you were missing.

## How the script is put together: Bash 4.2, a menu, and other people's tools

The repository root holds airgeddon.sh, language_strings.sh, a plugins directory, known_pins.db with a matching pindb_checksum.txt, and a .airgeddonrc file. That layout tells you the shape of the thing. airgeddon.sh is the entry point; language_strings.sh handles the supported languages the wiki lists; the pin database is the WPS side, with a checksum file so the script can tell whether that database has been altered; .airgeddonrc is the per-user configuration file at the top level of the checkout.

The README's badge links state the runtime floor: Bash 4.2 or later. That is a real constraint rather than a formality, since older enterprise distributions ship Bash 4.1 or earlier and the script will not run there. The Dockerfile confirms the same stack from the other direction: it starts from kalilinux/kali-rolling and installs gawk, iw, aircrack-ng, xterm, iproute2, pciutils, procps and tmux as the essential tools, then a longer optional list that includes hostapd, reaver, bully, pixiewps, hashcat, bettercap, mdk3, mdk4, hcxdumptool, hcxtools, hostapd-wpe, hostapd-mana, asleap, john, beef-xss, tshark and tcpdump.

So airgeddon is a front end. The wireless work is done by aircrack-ng for capture and cracking, hostapd for access point impersonation, reaver and bully for WPS, and the rest. airgeddon's own code decides which of them to launch, in what order, with which arguments, and it parses the output back into the menu. The plugins directory is the extension point the wiki documents under its plugins system pages, which matters if you want to add a technique without forking the main script.

## Installing airgeddon and running a first scan

The README does not carry install steps. It says all the needed information about how to install, use and enjoy airgeddon is present at GitHub's Wiki, and the wiki has separate pages for Installation & Usage, Requirements, Essential Tools, Optional Tools and Docker (split into Linux, Mac OSX and Windows pages). Treat the wiki as the source of truth for your distribution rather than copying steps from a blog post.

The repository does ship a Dockerfile, and the README links a Docker Hub image at v1s1t0r1sh3r3/airgeddon. The Dockerfile is the clearest install description in the repository: it builds on kalilinux/kali-rolling, installs the tool sets listed above, sets DISPLAY to :0, creates a volume at /io for external files, and sets the working directory to /opt/. The DISPLAY setting is the part to notice, because the script uses xterm and the container needs an X display to show it.

Once the script and its dependencies are in place, the entry point is the script itself:

```bash
sudo ./airgeddon.sh
```

The README's badge and the wiki's Options page are where the supported flags live, so check that page before scripting anything. On start the script checks for its essential tools and for a wireless interface. If it cannot find an interface, or the interface cannot enter monitor mode, the menu options that need one will not work. That check is the first thing to watch on a new machine, and it is also why a virtual machine with no passed-through USB adapter is the wrong place to try this.

## Where airgeddon stops being the right tool

The script is interactive by design, and that is the main limitation. The README describes a multi-use bash script with a menu, the wiki documents Options separately, and nothing in the repository suggests an unattended batch mode for running a fixed sequence across many targets. If you need reproducible, scripted runs in CI or a scheduled job, you will end up calling aircrack-ng, hcxdumptool or hostapd directly, because that is what airgeddon does underneath, minus the menu.

Hardware is the second boundary. The wiki carries dedicated pages for Cards and Chipsets, Wayland, Consistent Network Device Naming and Kali Nethunter, which is a good sign that all four cause trouble. Monitor mode and packet injection depend on the chipset and driver, not on airgeddon, and no amount of menu navigation fixes an adapter that will not inject. The Wayland page exists because the script's xterm-based interface assumes an X session; on a stock Wayland desktop you may need an XWayland setup or a different session type.

The Docker route has its own cost. The container installs a large optional tool set, and the Dockerfile sets DISPLAY to :0, so it wants access to your X server. Passing a wireless adapter into a container is a host-level operation, and the wiki's Docker pages per platform are where that is described. If you only want one technique, pulling a full Kali-based image with beef-xss, hashcat and hostapd-wpe inside is more surface than the task needs.

## airgeddon compared with driving aircrack-ng by hand

The realistic alternative is not another wrapper; it is the underlying tools used directly. aircrack-ng ships its own suite of commands for monitor mode, capture and cracking, and hcxdumptool with hcxtools covers PMKID and handshake collection in a form built for modern WPA3-era targets. Both are installed by the airgeddon Dockerfile, which is a fair sign of where the actual work happens.

The difference is control versus convenience. Calling aircrack-ng directly means you choose the channel, the capture file name, the deauth timing and the wordlist, and you can put all of it in a shell script that runs the same way twice. That is exactly what you cannot easily do through a menu. In exchange you have to know which tool handles which attack, and you reassemble the workflow yourself each time. airgeddon's contribution is that reassembly, plus the WPS pin database and the plugin system, neither of which the raw tools provide. Pick airgeddon when the workflow is exploratory and a human is watching. Pick the raw tools when the workflow is fixed and a machine is running it.

## Licence, updates and what maintenance costs you

airgeddon is GPL-3.0, and the README's licence badge reads GPL v3+. That matters if you plan to ship airgeddon inside a product or a managed service: the GPL's obligations attach to distribution, and the wiki has a Disclaimer & License page that restates the project's position. This is not legal advice, and if you are redistributing the script or a modified version of it, that is a question for your own counsel.

On cadence, the repository is not archived and the last push was on 2026-09-19, so it is being touched. The release history shows v12.01 on 2026-07-13, v12.0 on 2026-05-14 and v11.61 on 2026-01-30, which is a steady stream rather than a burst. Upgrading is a git pull of the checkout plus a re-read of CHANGELOG.md, but the dependency side is the real cost: the Dockerfile shows how many packages airgeddon can call on, and on a rolling distribution like Kali those packages move under you. The known_pins.db and pindb_checksum.txt pair means the WPS database is versioned with the script, so a partial update can leave the checksum mismatched. Keep the checkout and the tool packages in step, and read the changelog before jumping a major version.

## Conclusion

Adopt airgeddon if you audit wireless networks on Linux and want aircrack-ng, hostapd, reaver and the rest driven from one menu instead of a dozen hand-written command lines; the wiki is the install path, and the Docker image is the least invasive way to try it. Do not adopt it if you need a Windows-native tool or an unattended pipeline, since the README describes a menu-driven interactive script and the Docker wiki pages are the only cross-platform route it offers. Before trusting it in a real engagement, verify three things: that your wireless card is on the supported cards and chipsets list, that the essential and optional tools the wiki names are installed on your distro, and that monitor mode actually comes up on your adapter, because none of the menu options work without it.

## FAQ

### What is airgeddon used for?

It is a multi-use bash script for Linux systems to audit wireless networks, according to the repository description. The menus cover techniques such as handshake capture, PMKID, pixie dust, WPS, evil twin, denial-of-service and enterprise attacks, with sniffing and sslstrip listed among the topics.

### How do I install airgeddon?

The README does not list install steps; it states that all the information about how to install, use and enjoy airgeddon is on GitHub's Wiki, which has an Installation & Usage page plus Requirements and Essential Tools pages. There is also a Dockerfile in the repository and a linked Docker Hub image at v1s1t0r1sh3r3/airgeddon.

### How to install airgeddon on Kali?

The wiki's Installation & Usage page is the documented path, and the repository's Dockerfile builds on kalilinux/kali-rolling, so the Kali package set it installs (gawk, iw, aircrack-ng, xterm, iproute2, pciutils, procps, tmux and the optional tools) is a reasonable picture of what the script expects.

### how to install airgeddon on kali linux

Same documented route as any Kali install: the wiki's Installation & Usage page, with the Requirements and Essential Tools pages checked first. The Dockerfile's package list shows the dependencies the script calls on, from aircrack-ng and iw up through hostapd, reaver and hcxdumptool.

### how to install airgeddon in linux

The README points to GitHub's Wiki for installation on Linux systems generally, and the wiki splits Docker instructions by platform. The runtime requirement stated in the README badges is Bash 4.2 or later.

### what is airgeddon

It is a multi-use bash script for Linux systems to audit wireless networks, licensed GPL-3.0. The repository topics list aircrack, handshake, WPS, pixie dust, PMKID, evil twin and enterprise among the areas it covers.

## Sources

- [Issues](https://github.com/v1s1t0r1sh3r3/airgeddon/issues)
- [License: GPL-3.0](https://github.com/v1s1t0r1sh3r3/airgeddon/blob/master/LICENSE)
- [README](https://github.com/v1s1t0r1sh3r3/airgeddon/blob/master/README.md)
- [Releases](https://github.com/v1s1t0r1sh3r3/airgeddon/releases)
- [v1s1t0r1sh3r3/airgeddon on GitHub](https://github.com/v1s1t0r1sh3r3/airgeddon)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/v1s1t0r1sh3r3-airgeddon