hackGPT: a ChatGPT-driven hacking toolkit that runs from a notebook or the command line

What hackGPT actually does, and who it is written for

The repository describes itself as a way to use OpenAI and ChatGPT for hackerish work. That is broad, and the directory listing shows what it means in practice: a chatbot/, a mobile/ variant, a hackGPT_local/ directory, a hackerParents/ directory, and PwnAI_depreciated/, which the README also refers to as PwnAI. The README walks through four concrete jobs. The first is a chatbot that runs in a Jupyter notebook or from hackGPT.py and can be launched in a browser tab. The second is JIRA_hackGPT.py, which the README describes as hunting for JIRA issues with type=bug, fixing the issue and committing the fix back to the ticket as a comment. The third is PwnAI, which automates CVE exploit creation and CyberDefense protections, with results linked in a separate output repository. The fourth is parsing and analysis of JSON threat data from CyberDefense tools, with a SecurityScorecard ASI tool named as the example source.

The audience is narrow. This is for a security practitioner who already reads Python and Jupyter notebooks and wants a working example of prompting a model with vulnerability data, rather than a packaged scanner. The README is a set of screenshots and shell snippets, not a manual, and several paths in it point at other repositories (PwnAI, ssc-asi-tools) rather than at code in this one.

How the pieces fit together: notebooks, scripts and an API key

There is no single architecture here. The repository is a flat collection of entry points that share one dependency list and one credential. requirements.txt names openai, gradio, streamlit-chat, streamlit-extras, transformers, torch, huggingface-hub, hugchat, python-dotenv, ipywidgets, inquirer, prettytable and jira. That mix tells you the shape of the project: a chat interface built on Streamlit and Gradio, a local model path through transformers and torch, an alternative hosted chat path through hugchat, and a JIRA client. Each entry point pulls what it needs from the same environment.

The data flow for the PwnAI path is the clearest one in the README. Input files live under input/, with input/malware/malware_sample and input/sample_sources shown as examples. The README shows the first ten lines of those files, and they are plain text: an exploit header block with fields such as Exploit Title, Date, Exploit Author, Vendor Homepage, Version, Tested on and CVE, followed by links to Metasploit payload sources. So the loop is: put vulnerability or payload text in input/, run a script or notebook cell, get generated output written under output/. The README links a separate PwnAI repository for the published results of that loop.

Credentials are handled through a .env file. The README says to configure .env with your OpenAI API key and notes that the notebook will help you. That is the whole credential story, and it means the key sits in the working directory unless you handle it differently.

Installing hackGPT and running a first search

The README gives a clone, an optional virtual environment, and a pip install. Note that the first clone command in the README points at the PwnAI repository, not at hackGPT; the SSH line below it is the one that names hackGPT. If you want this repository, use the correct URL.

git clone https://github.com/NoDataFound/hackGPT.git
cd hackGPT
python3 -m venv env
source env/bin/activate
python3 -m pip install -r requirements.txt

After that, look at the sample inputs before running anything. The README uses head to show the first ten lines of both files, and the output is a plain-text exploit header plus source links.

head -n 10 input/malware/malware_sample && head -n 10 input/sample_sources

For the notebook route, install Jupyter and open the notebook. The README also points at the Jupyter renderers extension in the VS Code marketplace for viewing notebook output.

pip3 install jupyter notebook

The README states that the notebook helps you configure .env with your OpenAI API key. Do that before executing cells, or the API calls will fail. The two Python entry points are run directly:

python3 PwnAI.py
python3 PwnAI_bulk.py

The README labels these as single searches and bulk searches. Expect the first run to spend API credit and to take as long as the model call takes; there is no batching or caching layer described anywhere in the README.

hackGPT in Colab, Siri and the mobile path

The README treats Colab as a first-class way to run this, with a direct link to hacklab.hackGPT.ipynb and a note that the chatbot works on mobile. That matters because the dependency list is heavy: torch and transformers in the same environment as Streamlit and Gradio is not a small install, and a hosted notebook sidesteps it. The trade-off is that your OpenAI key and any threat data you paste into the notebook live in that hosted session.

The README also shows hackGPT enabled through Siri, with a screenshot but no setup instructions. Treat that as a demonstration rather than a documented feature. The same applies to the mobile/ and hackerParents/ directories: they exist in the repository listing, but the README does not explain what they contain or how to configure them. Anyone evaluating this for reuse should read those directories directly rather than expecting guidance.

Where hackGPT is the wrong tool

The most obvious limitation is that the README does not document what happens when a model call fails, when the output is wrong, or how to roll back a JIRA comment that JIRA_hackGPT.py posted. The README itself includes a screenshot captioned as hackGPT being superduper wrong, which is honest about the failure mode but does not describe any guardrail. If you point the JIRA script at a real tracker, the commit and comment steps are the part you cannot verify from the documentation.

Second, the repository has no releases and no licence file in the listing. The description field for the project states a licence is unknown. That is a real constraint for company use: you cannot tell what you are allowed to do with the code, and there is no tagged version to pin.

Third, the dependency set is broad and unpinned. requirements.txt lists package names with no version specifiers, so an install today resolves to whatever is current. torch, transformers, streamlit and gradio all move quickly, and the README does not state which versions were used for the screenshots.

Fourth, this is not a scanner. It does not discover vulnerabilities, parse binaries or manage engagements. It formats text you already have into prompts and writes the answers to output/. If you need deterministic parsing of threat feeds or a repeatable pipeline, a scripted parser without a model in the loop is the better fit.

A real alternative: ssc-asi-tools and plain parsers

The README itself points at a different approach. It names the SecurityScorecard ssc-asi-tools repository, specifically the SSC_APIHunter tool, as the source of the JSON threat data that hackGPT then parses and analyses. The split is instructive: ssc-asi-tools handles the API call and data retrieval, and hackGPT handles the interpretation. If your goal is getting the data, the upstream tool is the one doing the work.

For the exploit-generation path, the alternative is not another AI tool but the traditional loop: read the CVE, read the vendor advisory, write the proof of concept, test it in a lab. The README's own sample input shows what that loop consumes, a header block with CVE, version and tested-on fields plus links to Metasploit payload sources. hackGPT compresses the write-up stage of that loop. It does not replace the lab.

Maintenance, licence and what upgrading costs

The last push to the default branch was on 2026-08-12, so the repository is not abandoned, but there are no releases and no changelog published alongside it. The README badge reads hackGPT v23, which suggests the author tracks versions in the README rather than in tags. Upgrading therefore means pulling main and re-reading the README, not moving between tagged versions.

The practical upgrade cost sits in requirements.txt. Because nothing is pinned, a fresh install can pull a new major version of openai or transformers and break calls that were written against an older client. If you vendor this code, pinning the dependency list yourself is the first change worth making.

On licensing: the repository listing does not include a licence file, and the project metadata reports the licence as unknown. That is a fact about the repository, not a legal opinion. If you plan to redistribute the code or ship it inside a product, the absence of a licence is the thing to resolve with the author before you build on it.

Editorial conclusion

Adopt hackGPT if you want a readable set of scripts showing how to wire OpenAI calls into security chores, and you are comfortable reading Python and notebooks to find the entry points. Skip it if you need a supported product with versioned releases, a documented licence, or a maintained dependency set: the repository has no releases, no licence file and no stated maintenance commitment. Before running anything, verify two things in the repository itself: that requirements.txt still resolves against current openai and transformers builds, and that the .env file the README mentions is the only place your API key is stored.

Frequently asked questions

Official sources

1. Issues
2. NoDataFound/hackGPT on GitHub
3. Project website
4. README