Fluxion: a WPA phishing toolkit that checks the key against a captured handshake

What Fluxion actually retrieves, and who is meant to run it

Fluxion is a security auditing and social-engineering research tool. The README states its purpose plainly: the script attempts to retrieve the WPA/WPA2 key from a target access point by means of a social engineering (phishing) attack. That sentence is the whole product. It does not crack a key by computation. It asks a human for it.

The audience is narrow. The README recommends Kali Linux 2025.4 and an external wifi card, and the disclaimer puts responsibility for authorisation on the end user. If you are not running an authorised assessment against a network you are allowed to touch, the tool has no legitimate use for you, and the authors say attacking infrastructure without prior mutual consent is highly discouraged by them.

It is a remake of linset by vk496, and the README frames the remake as having fewer bugs and more functionality. The repository is HTML at the top level, which is unsurprising once you look at the attacks directory: the captive portal pages are web assets, and the orchestration around them is shell.

The captive portal attack, step by step through its moving parts

The README describes a sequence. You scan for a target wireless network, then launch the Handshake Snooper attack and capture a handshake, which it calls necessary for password verification. Then you launch the Captive Portal attack.

That second attack spawns four things. A rogue (fake) AP imitates the original access point. A DNS server redirects all requests to the attacker's host running the captive portal. A web server serves the portal that prompts users for their WPA/WPA2 key. A jammer deauthenticates clients from the original AP and lures them to the rogue one.

The design detail worth noticing is the verification loop. Every authentication attempt at the portal is checked against the handshake file captured earlier. The attack terminates automatically once a correct key is submitted, and the key is logged, after which clients are allowed to reconnect to the target access point. That is a different architecture from tools that simply collect whatever a user types. The handshake is the oracle; without it, the tool cannot tell a typo from a valid key, which is exactly why the README lists the handshake as a prerequisite rather than an optional step.

The README also notes that attack setup is mostly manual, with an experimental auto-mode handling some setup parameters. Treat auto-mode as a convenience layer over a manual process, not as an unattended workflow.

Installing and first run

The README gives three commands for a source install. The launcher checks dependencies and prompts to install any that are missing, so the first run may pause for package installation.

git clone https://github.com/FluxionNetwork/fluxion.git
cd fluxion
./fluxion.sh

If you only want the dependency check, the README documents a flag for that. It installs and checks dependencies without running attacks, which is the safer first command on a fresh Kali box.

./fluxion.sh -i

On Arch, the README offers two routes. You can build the package from the bin directory, or install it from the blackarch repository.

cd bin/arch
makepkg

pacman -S fluxion

Once the tool is running, the README's own order is: scan for a target network, run the Handshake Snooper attack, capture a handshake, then launch the Captive Portal attack. The README points to a wiki page called Captive Portal Attack for the detailed guide, and asks that you read the FAQ before requesting issues. There is also an uninstall.sh at the repository root; the README does not document what it removes.

WSL, adapter quirks and the handshake dependency

Fluxion does not work on Windows Subsystem for Linux, in either WSL or WSL2. The README gives the reason: the subsystem does not allow access to wireless network interfaces. It adds that issues regarding WSL will be closed immediately. If your only Linux environment is WSL, this project is not for you, and no amount of configuration will change that, because the missing capability is at the interface level.

The second failure mode is hardware. The README warns that some wireless adapters have driver or firmware quirks that break scanning, capture, or the evil twin, and points to docs/problematic-adapters.md before opening an issue about a misbehaving card. That file is the first thing to check when a scan returns nothing or the fake AP never comes up.

The third is the handshake. Because every portal submission is validated against the captured handshake, a failed capture leaves you with a portal that cannot confirm anything. The README treats the handshake as a prerequisite, so a deployment that skips it is outside the documented path.

A fourth constraint is legal rather than technical. The disclaimer states that using Fluxion against infrastructure without prior mutual consent could be considered illegal activity, and that authors assume no liability for misuse. That is not boilerplate you can skim past; it defines the only context in which the tool is intended to run.

How Fluxion differs from aircrack-ng and Wifite

The nearest comparison is to the capture-and-crack toolchain the project itself lists in its topics: aircrack. A tool like aircrack-ng takes a captured handshake and attacks it offline, guessing passphrases against the four-way handshake until one matches. It never touches the client. Fluxion inverts that. It captures the handshake and then uses it as a validator while a live social-engineering attack persuades a person to type the key. The handshake is not the thing being attacked; it is the reference value.

Wifite and its descendants, credited in the README alongside linset's author, automate wireless attack selection and execution. Fluxion is narrower and more theatrical: a fake AP, a DNS redirect, a web server and a jammer, all aimed at one outcome, a typed passphrase. If your goal is to demonstrate to a client that their users will hand over a network key to a convincing login page, the captive portal is the point. If your goal is to measure passphrase entropy, aircrack-style offline cracking answers a different question and needs no live clients at all.

The trade-off is operational noise. Deauthenticating clients and standing up a rogue AP is visible on the air, and the attack only ends when a correct key arrives or you stop it. An offline cracking run is quiet by comparison.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push to master was on 2026-09-19. Recent releases are v6.32 on 2026-09-11, v6.31 on 2026-07-21 and v6.28 on 2026-03-16, so the release cadence over the past six months has been steady. The README also states that Fluxion is actively maintained with new features, improvements and bugfixes, and points to the commit log as its changelog, which means there is no separate curated changelog file to read before upgrading.

Upgrading from a source clone is a git pull away, but the dependency check runs on launch, so a version bump can pull in new packages on the machine you are assessing from. That is the real upgrade cost here: not the code, but the toolchain underneath it. The README pins its recommendation to Kali Linux 2025.4, and nothing in the repository documentation describes a supported upgrade path between releases.

Fluxion is GPL-3.0. If you redistribute it or a modified version, the licence's terms apply, and the README separately notes that the authors do not own the logos under the captive portal sites directory, citing fair use under Section 107 of the Copyright Act 1976 for criticism, comment, news reporting, teaching, scholarship and research. Whether your particular use of those third-party page assets falls inside that framing is a question for a lawyer, not for this article. There is no legal advice in this section, only what the repository states.

Editorial conclusion

Fluxion fits authorised wireless assessments where you control the target network and the client devices, and where you can capture a handshake first, because the portal attack verifies submissions against that handshake. It is the wrong tool for anyone without written authorisation, for WSL users, and for assessment work that needs a documented rollback path, since the README does not describe one. Verify three things before you start: that your adapter is not listed in docs/problematic-adapters.md, that the handshake capture succeeds, and that running ./uninstall.sh does not remove anything you still need. If the handshake never lands, stop there: Fluxion's captive portal cannot confirm a key without it.

Frequently asked questions

Official sources

1. FluxionNetwork/fluxion on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases