The beta wraps more than 50 tools around 3 guided workflows
Ars0n Framework v2 combines more than 50 bug bounty tools with 3 workflow types: company, wildcard, and URL. Company scans map an organization's domains and networks. Wildcard scans enumerate subdomains, probe live services, and assign an ROI score. The URL path is described as a teaching flow for manual testing. Results land in PostgreSQL and appear in a React interface, so beginners can follow one method without stitching text files from Amass, Subfinder, Nuclei, and other commands.
That scope explains a checkout of 784 files, about 300,833 source lines, and 55.4 MB. The framework also stores screenshots, DNS records, technologies, findings, endpoints, and imported .rs0n bundles. Each wrapped tool can receive custom options through the interface or MCP. This is closer to a security lab assembled around one hunter's process than a single scanner. The tradeoff is that failures can come from the framework, Docker, an included tool, or an outside data source.
The 142-tool MCP server is unauthenticated by default
The MCP server registers 142 tools and listens on port 3001 over SSE. Those tools can create and delete targets, launch or cancel scans, replay captured HTTP traffic, change settings, manage API keys, and run vulnerability checks. Authentication is optional. The README warns that anyone who can reach the port can act through the service, so MCP_AUTH_TOKEN and a restricted network are baseline configuration for any shared or remote host.
The Compose file raises another trust question: the API container receives /var/run/docker.sock from the host so it can start the tool containers. A process with that socket can control the Docker daemon, which makes host isolation important. Our Go suite passed only 2 tests, and those tests do not establish that every one of the 142 MCP actions has correct authorization or safe scope handling. Put this on a dedicated machine or VM, then limit who can reach ports 80 and 3001.
What happened when we ran it
Our sandbox installed 67 Go packages in 14 seconds, then built the server successfully in 39 seconds. We tested commit f7be125 in a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets. The Go project lives under ./server, so these numbers describe the backend package. They do not describe docker-compose up --build, the React client, PostgreSQL, nginx, MCP, or any of the separate scanner images.
Go test finished in 21 seconds with 2 passed and 0 failed out of 2. The repository scan found a Dockerfile but no tests directory and 0 CI workflow files. A passing pair of tests is better than a broken backend, yet it is thin evidence for 300,833 lines of source and a system that drives active security tools. Our harness also did not run a real target scan, validate an API key, or test the UI.
The 39-second server build does not prove the 50-container setup
The documented product path downloads a beta ZIP and runs Docker Compose, which builds more than 50 containers. The README recommends at least 8 GB of RAM and several GB of free disk. PostgreSQL, nginx, the client, API, MCP server, and individual tool images all have their own startup or dependency failure modes. Some discovery stages need outbound internet access, while SecurityTrails, Censys, Shodan, and similar services may require keys or paid quotas for stronger results.
Open issue 110 records one example of that dependency churn: an httpx image failed because @latest required a newer Go toolchain. Current Dockerfiles use Go 1.26 and pin httpx v1.10.0, so the source has moved past the exact report. Our 14-second install of 67 Go packages did not build that image or the other tool images. With this many upstream projects, pinning and retesting containers is continuing maintenance, even when the core server compiles cleanly.
Beta 0.1.0 documentation disagrees about the URL workflow
The September 5 beta 0.1.0 release says the URL workflow and all other functions are complete. The current README still labels the URL workflow under development, lists future educational modules, and points learners to the wildcard path as the present alternative. That contradiction makes it hard to tell which lessons and scanners a beginner should expect. Evaluate the exact beta ZIP against a permitted test target before adopting the teaching sequence.
The ROI score needs similar restraint. The README gives points for signals such as missing headers, error pages, technologies, and endpoint counts, based on the author's hunting experience. It is a prioritization device, not proof of a vulnerability. With only 2 Go tests in our run and no CI workflow files, teams should keep raw tool output and manual verification beside every ranked target. A high score can guide attention, but it should not become an automated finding.
September activity supports a trial, while the beta label still matters
GitHub listed 796 stars and 44 combined issues and pull requests on September 10, 2026. The last push was September 7, two days after beta 0.1.0 shipped, so the project is active. The open queue includes installation reports, dependency updates, tool failures, and proposed fixes. That activity is useful for a beta, though it also shows the support surface created by Windows, WSL, macOS, Linux, Docker, and dozens of upstream scanners.
Ars0n is worth trying if the guided method is the reason you are here. The 39-second server build and 2 passing tests lower the first source-level hurdle, while the web interface and MCP layer offer more structure than a folder of scripts. The default security posture and deployment size rule it out for a casual shared server. Run it in isolation, add MCP authentication before connecting Claude Code, stay inside written scope, and verify every scanner result by hand.