Cybermes: the manifest says 3.0.0 and the newest tag is v3.5.0
Autonomous Offensive Security, Bug Bounty & Red Teaming Agent Framework powered by Hermes Agent, specialized reasoning skills, and multi-model LLM orchestration.
At a glance
- What is it?
- An offensive security automation framework that pairs a Python reasoning agent with a native Go MCP server, driving three different browser automation stacks from one repository. The dependency list is declared twice with identical contents, and the scan output directories are committed.
- Who is it for?
- Cybermes suits an authorised bug bounty or red team operator who wants the agent loop, the reconnaissance toolchain and the reporting stage in one place, and who is prepared to write a `scope.yaml` before running anything. It does not suit a workflow that needs a pinned, auditable dependency surface, because the version in the manifest trails the newest tag, the dependency list exists in two copies, and three browser automation stacks ship at once.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 4, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The build manifest stopped at 3.0.0 and the tags kept going
The two version numbers come from different files and they disagree. The manifest declares:
[project]
name = "cybermes"
version = "3.0.0"
requires-python = ">=3.10"while the three most recent releases are v3.5.0 from 2026-09-16, v3.4.2 from 2026-08-30 and v3.4.1 from 2026-08-30. The last two were published seventeen minutes apart on the same day, and v3.4.1 carries a release title that names its own nature, Interactive Prompt UI Hotfix and Terminal Lifecycle Engine. So the tags say three and a half minor versions have shipped since the manifest was last edited. That is the normal consequence of tagging from a branch while the version lives in a file nobody bumps, and it means the version string in the source is not a description of the current release. It is worth knowing before you file an issue, because a report quoting 3.0.0 is describing code two minor generations behind the newest tag.
Three browser automation stacks ship in one repository
The dependency manifests describe three separate ecosystems and each brings its own way of driving a browser. The Go side uses `github.com/chromedp/chromedp` at v0.16.0, a Chrome DevTools Protocol driver, along with its cdproto companion. The Python side declares `playwright>=1.49.0`. And the Node manifest declares `@modelcontextprotocol/server-puppeteer`. So a single checkout contains a Go CDP client, a Python Playwright client and a Node Puppeteer server. The Go module also carries a full MCP stack: `github.com/mark3labs/mcp-go` at v0.58.0 with `gopkg.in/yaml.v3`, and twelve indirect dependencies that include two separate JSON schema libraries, `google/jsonschema-go` and `santhosh-tekuri/jsonschema/v6`, plus a URI template implementation and three WebSocket packages. That is a large transitive surface for a module whose stated job is exposing tools over JSON-RPC.
The dependency list is written twice with the same ten lines
The Python dependency set appears in full in two places. The manifest carries ten entries, starting with `hermes-agent>=0.1.0`, `pyyaml>=6.0.2`, `requests>=2.32.3`, `python-telegram-bot>=21.10`, `playwright>=1.49.0`, `arjun>=2.2.1`, `rich>=13.9.4`, `markdown>=3.7`, `jinja2>=3.1.5` and `mcp-server-fetch>=2026.8.0`. The requirements file carries the same ten lines in the same order. Two copies of one list means an installer that reads the wrong one installs a different environment than the manifest advertises, and there is nothing in the tree that ties them together. One entry is also unaccounted for on the front page: `python-telegram-bot` is a full Telegram bot framework, and the installation and architecture sections describe MCP clients, a standalone CLI and a container without mentioning a Telegram surface anywhere.
Fourteen launcher scripts are committed at the repository root
The root listing is forty entries and fourteen of them are launchers. There are `cybermes`, `cybermes.bat` and `cybermes.ps1` for the main CLI, `hermes`, `hermes.bat` and `hermes.ps1` for the engine, `mcp.bat`, `mcp.ps1` and `mcp.sh` for the local MCP manager, `setup.sh` and `setup_windows.ps1` for installation, `env.sh` and `env.ps1` for environment loading, and `entrypoint.sh` for the container. Alongside them sit the two build manifests and a lock file per ecosystem: `go.mod`, `go.sum`, `pyproject.toml`, `requirements.txt`, `package.json` and `package-lock.json`. The reason for the duplication is visible in the Go module, which pins a Go toolchain line of 1.26.0 and a module path of just `cybermes` with no domain prefix, so the Go components are built in place rather than consumed as a published module.
recon, logs, output and targets are version-controlled directories
Four of the root entries are where the tool writes while it runs. The pipeline's first stage initialises `recon/<TARGET_SLUG>/` and `reports/<TARGET_SLUG>/`, the third stage archives raw tool output to disk under `recon/`, and the sixth compiles reports into the workspace. Alongside those, the root listing carries `logs/`, `output/` and `targets/`. All of them are in the repository, which means the natural output of an assessment, reconnaissance data including endpoints, status codes and anything the filter classified as a leaked secret, sits inside a directory tree that is under version control. The presence of `scope.yaml` at the root is the counterweight and the thing to read first, since the first stage resolves domain boundaries from it, and `ATTRIBUTION.md` sits next to it for whatever the playbooks and wordlists derive from.
The MCP package you install with npx is not in this repository
The recommended installation is a single line:
npx -y cybermes-mcp installThe Node manifest in this repository does not define a package called `cybermes-mcp`. It has no name, no version and no scripts, and its entire content is two dependencies, the official Model Context Protocol filesystem and Puppeteer servers:
"@modelcontextprotocol/server-filesystem": "^2026.7.10",
"@modelcontextprotocol/server-puppeteer": "^2025.5.12"So the binary that `npx` fetches is built and published somewhere else, or from a branch not represented here, and this manifest is the dependency set for running it rather than for building it. The version numbers on those two dependencies are themselves dated, one tracking a 2026 calendar version and the other a 2025 one. The alternative documented path is a manual client configuration block that also shells out to `npx` with the same `-y` flag, so in both cases the artefact that gets installed onto a user's machine is not traceable to a tag in this tree.
smart_pipe decides what the agent is allowed to read
The third pipeline stage is the one that shapes everything else, and its reason is stated as context saturation rather than performance. Raw output from the reconnaissance tools is archived to disk in full, while `smart_pipe` streams only relevant endpoints, HTTP status codes and leaked secrets into the agent's context window. The tools it sits in front of are named as a sequence: `subfinder`, `httpx`, `katana` and `ffuf`. After that the fourth stage queries an offline knowledge database through `search_knowledge` and loads playbooks from `skills/`, and the fifth is a gate: the agent writes a non-destructive script named `pocs/poc_<vuln>.py` and executes it, capturing raw HTTP request and response evidence before anything reaches the report stage. The design point is that a filter decides which findings the model reasons over, so the filter's criteria are part of the assessment's trustworthiness rather than an optimisation detail. The flow diagram groups those six stages into three phases, a scope and recon phase, a skill and validation gate phase, and a deliverables phase, with the gate sitting between collection and reporting rather than at the end of it. That placement is the design: nothing reaches a report without passing through a reproducible script first.
Editorial conclusion
Cybermes suits an authorised bug bounty or red team operator who wants the agent loop, the reconnaissance toolchain and the reporting stage in one place, and who is prepared to write a `scope.yaml` before running anything. It does not suit a workflow that needs a pinned, auditable dependency surface, because the version in the manifest trails the newest tag, the dependency list exists in two copies, and three browser automation stacks ship at once. Check four things first. Check your scope file, since the first pipeline stage resolves domain boundaries from it and everything downstream writes into a per-target directory. Check that you can get a model configured, since the engine is a reasoning agent and a missing key is not a degraded mode. Check which of the three installation paths you are using, because the MCP installer, the standalone CLI and the container take different routes to the same code. And check that your recon and report output directories are not inside a repository you push. The licence is Apache-2.0, the default branch was pushed on 2026-10-02, and the three most recent releases are v3.5.0, v3.4.2 and v3.4.1.
Frequently asked questions
What is the Cybermes framework?
An offensive security assistant and automation framework for authorised bug bounty hunting, reconnaissance, vulnerability research and structured reporting. It pairs a Python reasoning agent with native Go utilities, a set of modular playbooks, and an MCP server that exposes its tools to AI coding environments over JSON-RPC.
How do I install Cybermes for an AI coding assistant?
Through its MCP server. The universal installer runs npx -y cybermes-mcp install and auto-detects configured clients, or you can target specific ones with flags such as --kilo or --gemini --cursor, install globally with npm to avoid startup latency, or register the server manually in a client's mcpServers block.
How do I run a Cybermes assessment from the terminal?
Through the standalone CLI, which accepts a target as a single prompt, or in a container with docker compose exec. Before either, python tools/doctor.py checks system dependencies and path bindings, and the same script with --fix repairs what it finds. A mock vulnerable application is included for local testing.
What are the two Cybermes operational workflows?
An autonomous CLI workflow where the local Hermes engine reasons, spawns subprocesses, filters streaming output and runs validation loops on the machine, and an MCP server workflow that exposes the native Go tools and playbooks to external assistants and editors over JSON-RPC 2.0 on stdio.
What version of Cybermes is current?
The newest release is v3.5.0, published 2026-09-16, following v3.4.2 and v3.4.1 on 2026-08-30. The build manifest still declares version 3.0.0, so the version in the source lags the tags by two minor versions.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/zyrexnn-cybermes)