Found in Aspectv3 real-world smoke
Aspectv3 (real-world target) exposed 0 API action tools to BugHunter through SurfaceMCP. SurfaceMCP knew about 35 pages and 35 navigations, but found no TypeScript mutations/actions to convert into MCP tools. Result:
- Pen-testing: 0 probes
- XSS mutation: 0 probes
- Race conditions: 0 tests
- IDOR: 0 replays
- Form fuzzing: 0 tests
Entire backend attack surface of `/api/v1/...` was untouched. BugHunter on a real app degenerates into "decent SEO/perf auditor" without action coverage.
Why
Adopting BugHunter today requires hand-authoring SurfaceMCP action definitions for each backend route. That's high friction. Most projects won't do it, so they lose 70%+ of BugHunter's detection capability.
Architectural direction
SurfaceMCP needs auto-discovery extractors for common backend framework patterns:
- Express: scan route registrations (`app.get`, `router.post`), extract path/method/params via AST
- Fastify: scan plugin/route definitions
- NestJS: extract from `@Get`/`@Post` decorators
- tRPC: enumerate router paths
- Next.js API routes: walk `pages/api/` and `app/api/` directories
- OpenAPI: already supported, just emphasize as fallback
The OpenAPI extractor already exists. The gap is the framework-native ones — many projects don't author OpenAPI specs but DO have Express/NestJS code that could be parsed.
This is a SurfaceMCP-side spec, not BugHunter
The fix lives in cunninghambe/SurfaceMCP. BugHunter consumes whatever tools SurfaceMCP exposes; the question is how SurfaceMCP discovers them.
Priority
High but not immediate. The bounded fixes (#145, #146, #147) are higher leverage on existing real-world signal. This unlocks the next 10x of real-world value but requires substantial cross-repo work.
Related
- Aspectv3 smoke from this session (the empirical evidence)
- SurfaceMCP existing extractors at `/root/SurfaceMCP/src/extract/`
Found in Aspectv3 real-world smoke
Aspectv3 (real-world target) exposed 0 API action tools to BugHunter through SurfaceMCP. SurfaceMCP knew about 35 pages and 35 navigations, but found no TypeScript mutations/actions to convert into MCP tools. Result:
Entire backend attack surface of `/api/v1/...` was untouched. BugHunter on a real app degenerates into "decent SEO/perf auditor" without action coverage.
Why
Adopting BugHunter today requires hand-authoring SurfaceMCP action definitions for each backend route. That's high friction. Most projects won't do it, so they lose 70%+ of BugHunter's detection capability.
Architectural direction
SurfaceMCP needs auto-discovery extractors for common backend framework patterns:
The OpenAPI extractor already exists. The gap is the framework-native ones — many projects don't author OpenAPI specs but DO have Express/NestJS code that could be parsed.
This is a SurfaceMCP-side spec, not BugHunter
The fix lives in cunninghambe/SurfaceMCP. BugHunter consumes whatever tools SurfaceMCP exposes; the question is how SurfaceMCP discovers them.
Priority
High but not immediate. The bounded fixes (#145, #146, #147) are higher leverage on existing real-world signal. This unlocks the next 10x of real-world value but requires substantial cross-repo work.
Related