afrog: the Go PoC scanner built for bounty hunting workflows

A scanner shaped by three workflows

afrog describes itself as a high-performance security scanning toolkit built for bug bounty, pentest and red team workflows, and the three audiences explain its feature emphasis. It combines fast target probing, built-in vulnerability checks, custom PoC authoring and SDK-driven automation in a single Go-based workflow, so the same binary serves the bounty hunter scanning one target, the pentester running a file of hosts, and the red teamer embedding checks into tooling. The what-it-does list names the differentiators, fast and focused scanning for web targets and network services, built-in and custom PoC support for practical validation, lower false-positive noise through precise rule design and checks, and flexible integration with Go applications, automation flows and private PoC pipelines. The project is bilingual, English and Chinese readmes, and the contributor wall below reflects the Chinese security community that feeds it PoCs. The phrase single Go-based workflow deserves unpacking, because the tool's history shows the opposite temptation, most scanning stacks bolt a template engine onto a HTTP client and leave the rest to shell scripts, while afrog pulls probing, checking, out-of-band detection, notification and result handling inside one binary that a CI job or a laptop can run identically.

Three install paths, Go 1.27 or later

Installation has three routes, and the dependency floor is stated once, Go 1.27 or later. The binary release path downloads the latest from GitHub's releases page, built through a goreleaser configuration visible at the repository root. Building from source is four commands:

git clone https://github.com/zan8in/afrog.git
cd afrog
go mod tidy
go build -o afrog cmd/afrog/main.go

with ./afrog -h as the smoke test. The Go install path pulls the tagged module:

go install -v github.com/zan8in/afrog/v3/cmd/afrog@latest

The v3 module path in the install command marks the current major generation, matching the go.mod module declared as github.com/zan8in/afrog/v3 with toolchain go1.27.1, and the three paths converge on the same single binary.

One flag to scan, one flag to filter

The quick start compresses the tool to its essentials. Scanning a single target is:

afrog -t https://example.com

multiple targets come from a file:

afrog -T targets.txt

and severity filtering is one more flag:

afrog -T targets.txt -S high,critical

The severity filter matters more than it looks, PoC libraries accumulate hundreds of checks across information, low, medium, high and critical severities, and a bounty hunter working a scope wants the two severities that pay, not the noise. The lower false-positive claim in the feature list pairs with this, precise rule design and checks, so the filtered output is signal rather than a triage queue. The -t and -T split, target versus targets file, follows the conventions of the Go security tooling family afrog belongs to. The severity letters also compose with the file-based target flow in practice, a large target file scanned at all severities produces a working inventory, then re-running the same file at high and critical produces the actionable shortlist, and the two outputs together serve both the documentation and the hunt.

Four handbooks, from first PoC to licensed feed

The documentation is organized into four handbooks, and the structure names the tool's surface. The User Guide covers what afrog is and how to use it, starting at an overview page. The PoC Authoring Guide opens with write your first PoC, the path for contributors whose checks feed the community library. The SDK Usage Guide covers embedding afrog in your Go program, the integration surface the feature list advertises. And the Curated PoC handbook documents enabling licensed curated PoCs, the commercial layer beside the open-source core. The split tells users where their journey forks, use the tool, write checks, build with it, or subscribe to curation, each documented on its own track under docs/en in the repository. The handbook split also reflects who writes what, tool users read the first guide once, PoC authors return to the second constantly as new vulnerabilities appear, SDK users consult the third during integration, and only subscribers touch the fourth, so the documentation's shape matches how often each audience returns.

Eleven examples, from async to out-of-band

The examples directory maps the SDK's surface with eleven runnable projects, async_scan, basic_scan, full_output, internal, oob_scan, port_scan, progress_scan, sdk_portscan, vuln_scan and vulnweb, each demonstrating one integration shape. The oob_scan example points at the out-of-band detection capability, backed by the zan8in oobadapter dependency, the mechanism that catches blind vulnerabilities which phone home rather than reflecting in responses. The port_scan and sdk_portscan pair shows service probing as both standalone and embedded use, and the full_output example documents result handling. For a Go developer, these examples are the difference between reading an API reference and pasting working code, the on-ramp the SDK handbook's quickstart complements. The internal example in the list is worth a note for integrators, it demonstrates running scans inside an existing Go process with the tool's own logging and lifecycle rather than shelling out to the binary, which is the pattern automation platforms that wrap scanners typically want.

A dependency list that is a feature list

The go.mod reads as an inventory of what the scanner can touch. Database drivers cover Oracle, SQL Server, MongoDB, PostgreSQL, SQLite and the Chinese DM database, the backends PoCs for database services connect through. Protocol support includes go-smb2 for SMB, Azure go-ntlmssp for NTLM, a ZooKeeper client, and the zan8in rawhttp fork for low-level HTTP control. The ysoserial dependency generates Java deserialization payloads, murmur3 and regexp2 support detection logic, and the notification layer spans dingtalk and wxwork-bot-go for alerting into Chinese workplace chat platforms. Cel-go embeds an expression engine, gopsutil reads system metrics, and the ants pool drives the concurrency model, each dependency purchased by a feature the PoC library exercises.

v3.5.x, and a community of PoC authors

The release train is steady, v3.5.5 and v3.5.6 in July 2026 and v3.5.7 on 2026-09-08, with the repository pushed 2026-09-25, so the tool and its checks move together. The PoC contributors section is long enough to be a wall, dozens of named authors from the Chinese security community, 不动明王, 雪山, White-hua and many others with blogs and GitHub profiles linked, the social contract behind a vulnerability scanner's real value, its check library. The primary language registered on GitHub is HTML, a quirk of the repository's docs pages outweighing the Go source, and the MIT license covers the toolkit while the curated PoC handbook's licensing sits beside it as the commercial complement. The goreleaser configuration at the root produces the cross-platform release artifacts the download page serves, so the build-from-source path and the binary path produce the same tool, and the release tags track the PoC library's growth as much as the engine's fixes.

Editorial conclusion

Use afrog when bug bounty or authorized testing needs a fast, scriptable vulnerability scanner with a growing PoC library and a Go SDK for embedding scans in automation. It is a tool for professionals with permission to test their targets, not a point-and-click auditor, and its value depends on PoC quality, so learn the authoring guide rather than only the built-in checks. Before deploying, install Go 1.27 or newer for source builds or grab the release binary, start from the four handbooks on the docs site, and evaluate the curated PoC feed's licensing separately from the MIT core, since that handbook documents enabling a licensed product.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. zan8in/afrog on GitHub