# King Phisher: a full phishing campaign toolkit with a client, a server and plugins > The original open source awareness training platform, built to run several campaigns at once with email templates, web page cloning and plugin hooks. Its own README now says it is no longer maintained. **CrimsonForge-io/king-phisher** — Phishing Campaign Toolkit - Repository: https://github.com/CrimsonForge-io/king-phisher - Stars: 2,602 · Forks: 582 - Language: Python - License: BSD-3-Clause - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/crimsonforge-io-king-phisher ## Two processes, because email sending and page serving are different jobs The repository tree explains the architecture before the README does. There is a `KingPhisher` entry and a `KingPhisherServer` entry at the top level, alongside a `king_phisher/` package, plus `docs/`, `data/`, `tools/` and `tests/`. That split is the whole design. One process is the client, which is what an operator drives to compose campaigns, send mail and watch results. The other is the web server that serves the landing pages to the people who click. They are separate because they live on different sides of the network boundary in a real engagement: the client belongs to the tester on the internal network, and the server is the thing exposed to the internet that victims actually reach. The README backs this up with the feature list. Run multiple phishing campaigns simultaneously, send email with embedded images for a more legitimate appearance, optional two-factor authentication, credential harvesting from landing pages, SMS alerts regarding campaign status, web page cloning capabilities, integrated Sender Policy Framework checks, geo location of phishing visitors, and send email with calendar invitations. Several of those are the details that separate an awareness tool from a mail blaster. A tracking image embedded in the body, an SPF check before sending, and a geo lookup on the landing page are all things you need to make a campaign convincing and to report on it afterwards. ## uid is the variable that ties an email to a server The README documents the Jinja2 template variables available in client message templates, and one of them explains the tracking model. There is `uid`, described as the unique tracking identifier, and the same value is available as `client.message_id`. The same file also exposes `url.webserver`, the phishing server URL with the uid parameter, `url.webserver_raw` without it, `url.tracking_dot` for a tracking image URL, and `tracking_dot_image_tag` as the image in a preformatted `` tag. The README then states the constraint that matters: the uid is the most important, and must be present in links that the messages contain. That is a small design with large consequences. A campaign works because every link and every tracking pixel in the outbound email carries an identifier that the server can look up, attribute a visit, and store. There is no separate click tracking service to integrate, and nothing in the outbound message that a mail client would treat as suspicious beyond the link itself. The remaining variables are the personalisation layer: `client.company_name`, `client.email_address`, `client.first_name`, `client.last_name` on the recipient side, and `sender.email`, `sender.friendly_alias`, `sender.reply_to` on the sending side. Templates live in a separate King Phisher templates repository rather than in this one, and the README asks for contributions there instead. ## Plugins extend both halves, and so do the templates The plugin story is where this differs from a single-script tool. The README states that both the client and the server can be extended with functionality provided by plugins, that a small number are packaged with King Phisher, and that additional ones live in a separate plugins repository. Two consequences follow. First, extending the landing page server does not require forking the operator console, and vice versa, which is the separation that made the tool workable for a team with more than one role. Second, the plugin surface is a security boundary you inherit: anything a plugin can do runs with the privilege of the process it loads into, on a server that is deliberately reachable from the internet. The v1.14.0 release notes show this system under load. That release added server support for installing missing plugin requirements during initialization, and v1.15.0 notes that the Windows build will now install PyPI requirements for plugins during installation. Both changes exist because plugins declare Python dependencies and something has to resolve them. The template split follows the same logic. Message templates and server page templates live in their own repository, so a campaign designer can change the look of an email without touching Python at all. ## Building the docs, and what the release history reveals The project uses Sphinx for its internal technical documentation, and the README gives the generation command: ```bash sphinx-build -b html docs/source docs/html ``` The published copy is hosted on ReadTheDocs at king-phisher.readthedocs.io, which means the internal documentation still resolves even though the software has stopped moving. The release history is short and stops abruptly. v1.15.0, from 2019-09-24, adds selectable visible columns for tables in the Campaign tab, adds printing of pipenv output in real time, notes the Windows plugin requirement install, and closes with multiple bug fixes. v1.14.0, from 2019-08-01, adds the `Message-ID` MIME header to outgoing messages, tries SSH authentication with every agent-provided key, deletes `Pipfile.lock` from the repository to avoid hash issues between Python versions, adds `--three` to the pipenv install and update startup steps to force Python 3, adds asynchronous RPC methods to the client, adds GraphQL and database schema documentation, renames Target URL to Web Server URL in the campaign editor, and adds the ability to issue SSL certificates through certbot. v1.13.1, from 2019-04-19, fixes broken references to `start_process`, fixes a `KeyError` when creating a campaign for the first time, and updates SQLAlchemy and Jinja2 for security patches. Those three releases show a mature project doing sensible maintenance, including dependency patching, and then nothing for seven years. The absence of a v1.16 is the most informative entry in the changelog. ## The README's own status statement, and what it means for adoption The line that shapes every other judgement here is a single sentence near the top of the README: King Phisher is no longer being maintained. The release record agrees. The newest tag is v1.15.0 from 2019-09-24, the repository metadata reports a last push on 2026-08-04, and no release has followed the 2019 series. The commits since are not new versions of the software. For anyone evaluating it, that turns a set of ordinary upgrade questions into unusual ones. King Phisher is a Python application with a `Pipfile` and PyPI dependencies resolved through pipenv, including SQLAlchemy and Jinja2, both of which have had security advisories since 2019 that a 2019 lockfile cannot have addressed. The repository's own release notes demonstrate the maintainers cared about exactly this, since v1.13.1 exists partly to patch those two libraries, and the reason it cannot keep happening is the reason the project stopped. That is not a reason to dismiss the codebase. It is a reason to treat any deployment as a fork you now own, with a security review attached to it rather than an upstream to send patches back to. ## How it compares with a commercial awareness platform The comparison worth making is not with other phishing tools, it is with the hosted awareness platforms that appeared after this one. Those services bundle the same mechanics, credential harvesting, campaign reporting, simulated landing pages, and add dashboards, scheduled campaigns, HRIS integrations and vendor support. They also cost per user per month and hold your phishing data on someone else's infrastructure. The genuine advantages King Phisher still has are operational rather than technical. It runs on infrastructure you control, so a simulation for a regulated environment does not require sending employee credentials to a third party. It is BSD 3-clause licensed, so there is no licence restriction on modifying it. And the client/server split plus the plugin hooks means a security team can automate parts of a campaign from their own tooling. The disadvantages are equally concrete and mostly about dependency risk. A hosted platform patches its own stack; a 2019 Python application on your network does not. King Phisher's landing page server is exposed to the internet by design, which means an unpatched web framework in its dependency tree is reachable by anyone who reads the source. Where it is not the right answer at all is anything requiring reliable long term operation, because there is no upstream left to report a vulnerability to. ## Conclusion King Phisher is worth reading as architecture rather than adopting as tooling, because the split between a campaign client, a web server that serves the landing pages, and a plugin system on both sides was the pattern later awareness platforms commercialised. For actual use, the honest position is that the project is finished: the README states plainly that it is no longer being maintained, the newest release is v1.15.0 from 2019-09-24, and no newer tag exists, so you inherit the dependencies as they were. Anything you build here also inherits the obligation in the README that the tool is only to be used for legal applications when the explicit permission of the targeted organization has been obtained. ## FAQ ### What is King Phisher used for? It is a toolkit for simulating real world phishing attacks in order to test and promote user awareness. The README describes running anything from simple awareness training to more elaborate scenarios where content aware of the user is served for harvesting credentials. ### Is King Phisher still maintained? No. The README states plainly that King Phisher is no longer being maintained, and the newest GitHub release is v1.15.0 from 2019-09-24, with no tag published since. ### How do King Phisher message templates track who clicked a link? Every link and tracking image in an outgoing message carries a `uid`, the unique tracking identifier, which is also exposed as `client.message_id`. Template variables such as `url.webserver`, `url.tracking_dot` and `url.webserver_raw` build the links, and the README states that the uid must be present in links the messages contain. ## Sources - [CrimsonForge-io/king-phisher on GitHub](https://github.com/CrimsonForge-io/king-phisher) - [Issues](https://github.com/CrimsonForge-io/king-phisher/issues) - [License: BSD-3-Clause](https://github.com/CrimsonForge-io/king-phisher/blob/master/LICENSE) - [README](https://github.com/CrimsonForge-io/king-phisher/blob/master/README.md) - [Releases](https://github.com/CrimsonForge-io/king-phisher/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crimsonforge-io-king-phisher