Findings that survive review,
not just findings that arrive fast.
SecHive is an operator-driven security research workbench under active development. You define the scope, hold the approval gates, and make the call on every finding while the runtime organizes hypotheses, validation notes, and reproducible evidence across pentest, bug bounty, source audit, mobile, and reverse-engineering modes.
Twenty-one public cases. Fourteen CVEs, four kernel fixes.
These are public advisory records and upstream commits, not benchmark scores. Twenty-one distinct findings across npm, PyPI, NuGet, Java, C/C++ and WordPress, plus four accepted Linux mainline contributions — each independently verifiable through the linked source. Five cases carry both a CVE and a repository advisory, so the identifier totals overlap and are never added together.
Verified as of 5 September 2026. Six public cases are listed at advisory level only, because their coordinators still withhold the technical detail. Further work remains in coordinated disclosure and is withheld in full — no identifier, product or technique — until the coordinating organization publishes.
Read-only is not capability-safe.
An allowlisted node:test builtin came back wrapped in a read-only proxy. It still exposed a method that launches a Node process with caller-controlled interpreter arguments.
Strict mode still trusted the wrong interface.
Strict class registration rejected an ordinary unregistered lambda capture class — and admitted the equivalent interface, because "no default methods" was read as proof the type was inert.
The guard counted wrappers, not capabilities.
A dangerous host prototype mutator was blocked directly and one layer deep. JavaScript lets the same capability survive arbitrary wrapper composition.
Reads were confined. Writes were not.
The restricted evaluator refused to read __class__. The assignment path walked the same segment as an intermediate destination and mutated shared class state.
The name was checked. NTFS disagreed.
Reserved-name filtering rejected .git, git~1 and trailing-dot variants — and accepted the one spelling NTFS resolves back to the real gitdir.
Generic TLV validity is not type validity.
A header-only SCTP parameter passed the generic walker. A typed consumer then read a 32-bit field that was never sent — and returned it to the peer in the state cookie.
Most AI security tools are good at producing activity. SecHive is built around a stricter question.
Scanners give you a long list of maybes. Agentic frameworks give you a long transcript. Both leave the human operator to reconstruct what happened, what was actually proven, and what is safe to put in a report.
SecHive collapses that gap. The operator stays in the chair — scope, approvals and disposition are yours — while the runtime writes its own audit trail as it works, so the report is the artifact, not the starting point.
Raw output without enough review context.
- ✕You get raw output — then spend hours rebuilding what actually happened.
- ✕No deterministic way to reproduce a finding on demand.
- ✕Evidence is scattered across screenshots, logs, and chat windows.
- ✕Negative results are dropped — you never see what the agent ruled out.
- ✕Provenance and reviewer decisions are often reconstructed after the run.
- ✕No policy gate on exploitation — easy to drift outside scope.
A defensible report — built as the work happens.
- ✓Research tooling is designed to capture provenance while the work happens.
- ✓Validated findings can include deterministic replay notes and retained evidence.
- ✓Artifact hashes make later review and change detection easier.
- ✓Negative evidence is retained — refutations are first-class artifacts.
- ✓Structured review bundles keep evidence, disposition, and remediation together.
- ✓Exploit execution and external actions remain behind human approval gates.
Seven stages between a target and a defensible report.
SecHive is not a single prompt, and it is not a fire-and-forget agent. It is an operator-controlled pipeline that enforces the scope you set, routes signals into specialist skills, plans hypotheses, validates them at runtime, preserves negative evidence, and only promotes a candidate to a finding once it clears your gate.
The loop is the product.
Anything in security can be made to look impressive in a transcript. SecHive's loop is designed to preserve the work behind a finding: scope, evidence, validation steps, negative results, and a clear human review decision.
Walk through the platform →Mission control, running on your machine.
SecHive is local-first. The operator UI shows running campaigns, hypothesis graphs, evidence drawers, replay buttons and approval queues — all served from the same machine that holds your scope.
/v1/execuser_id param — numeric enumeration, no ownership check observed/submitOne workbench. Six disciplines, each with its own truth.
Pentest, bug bounty, own-source bug hunt, mobile, reverse engineering and PR audit are different flows — different signals, different scope, different evidence standards. SecHive treats them that way instead of reusing one prompt with a different label.
- i. Pentest Authorized research with scope policy, approval checkpoints, and evidence organized for technical review. research mode
- ii. Bug Bounty Coordinated-disclosure reports with reproducible steps, CVSS context, and redaction-safe write-ups. research mode
- iii. Own-Source Bug Hunt Source-uploaded analysis where suspicions are kept distinct from validated runtime findings until proven. research mode
- iv. Mobile / APK Review Exported components, broadcast paths and binder surfaces — backed by static and runtime evidence. research mode
- v. Reverse Engineering Binary triage, anti-tamper inspection, and protocol reasoning where reproduction matters more than scan count. research mode
- vi. PR Audit Pull-request gating with diff-aware reasoning. Designed to catch regressions without flooding reviewers. research mode
Public records and internal evaluations. Clearly labeled.
The public research record includes disclosed CVEs, published GitHub Security Advisories, and three accepted Linux mainline fixes. Purpose-built Juice Shop and XBOW-style runs are project-reported internal evaluations, not independent certifications.
Published research
Independent, externally linkable records separate from work still moving through coordinated disclosure.
OWASP Juice Shop
Full unredacted black-box and white-box reports against the current 111-challenge tree. Routes, payloads, source references and evidence snippets retained.
XBOW-style campaign
One hundred and four recorded validation cases, paired black-box and white-box. 98 black-box wins, 104 white-box wins, 100% any-win.
Research artifacts mapped to familiar security frameworks.
The project documents how technical research artifacts can relate to SOC 2, ISO/IEC 27001, NIS 2, DORA, PCI DSS 4.0 and HIPAA. Framework references describe evidence mapping and control alignment. SecHive is not presently certified or independently audited under these frameworks unless explicitly stated.
NIS 2 Directive
Cybersecurity risk-management measures for essential and important entities. Evidence covers § (a) risk analysis, § (e) effectiveness testing, § (g) cyber hygiene.
Open vertical →DORA
Digital Operational Resilience Act. Threat-led penetration testing for financial entities, with chain-of-evidence retention and ICT third-party scope.
Open vertical →PCI DSS 4.0
Reference mapping for penetration testing of a cardholder-data environment, including Requirements 11.4.1–11.4.5 and segmentation testing.
Open vertical →SOC 2
Illustrative references to selected trust services criteria for vulnerability identification and threat detection.
Open vertical →ISO/IEC 27001
Annex A controls for technical vulnerability management and security testing in development and acceptance.
Open vertical →HIPAA Security Rule
Periodic technical and non-technical evaluation evidence for covered entities and business associates.
Open vertical →A finding needs a reproducible broken invariant.
This generalized runtime-authorization replay pattern shows the evidence shape used to test a hypothesis without exposing confidential targets or embargoed work.
Hypothesis
A signed runtime authorization carries a nonce-like value. bizlogic_hunter flags the value as never observed in durable state.
First execution
The relayer submits the signed action. The validation function returns OK. The execution wrapper performs the privileged side effect.
Replay
The same authorization bytes are submitted again, unmodified. The nonce is not consumed; the digest validates.
Second execution
The privileged side effect occurs a second time. The invariant "one signed authorization authorizes one execution" is broken.
Promotion
After human review, the candidate can be promoted. The proof pack contains the signed payload, two execution receipts, side-effect deltas, the validation source path, artifact hashes, and a deterministic replay.sh.
A readable report. A practical manifest for engineering.
The workflow is designed to produce both a human-facing report and a machine-readable proof pack with provenance, a redaction manifest, artifact hashes, and replay material for technical review.
# sechive-proof-pack/replay.sh — sha256:7c3a… set -euo pipefail TARGET="https://lab.example.invalid" AUTH="$(cat artifacts/signed-authorization.b64)" # first execution — expected OK curl -sS -X POST "$TARGET/v1/exec" \ -H "X-Authorization: $AUTH" \ -d @artifacts/payload.json | tee out/01.json # replay — invariant broken if 200 OK curl -sS -X POST "$TARGET/v1/exec" \ -H "X-Authorization: $AUTH" \ -d @artifacts/payload.json | tee out/02.json diff <(jq .receipt out/01.json) <(jq .receipt out/02.json) \ && echo "REPLAY ACCEPTED — finding confirmed" \ || echo "replay rejected — invariant holds"
Bring an authorized scope. Leave with a defensible report.
SecHive is local-first. Pilots run against your own infrastructure or against a controlled lab — never against systems you don't own or aren't explicitly authorized to test.