Scan engines · Vulnerability and authorization testing

cortex

Runs detection templates and dedicated authorization tests, then re-proves every candidate before it is allowed to become a finding.

Daemon port: 4445
Licence: Apache-2.0
Install: crossfyre extension install cortex

Contents

The template model Matchers The expression DSL Out-of-band confirmation Authorization testing Correctness and resilience Standalone usage Key options Output

cortex is the vulnerability-scanning engine, a dynamic scanner that runs detection templates and dedicated authorization tests against a target and reports evidence-backed findings. It reads nuclei-format templates (its own curated built-ins plus any external directory you point it at), matches on response status, body content, size, regexes and an expression language, and confirms blind vulnerabilities out-of-band. Beyond templates it has a purpose-built authorization engine that replays endpoints across multiple identities to catch broken access control. Every candidate is put through a correctness pass before it is reported, so findings are evidence-backed rather than "possible".

The template model

cortex runs a practical subset of the nuclei YAML template schema, so templates you already have will largely work. A template declares an id, some info (name, severity, description), and one or more HTTP requests:

id: git-config-exposure
info:
  name: Exposed .git/config
  severity: medium
http:
  - method: GET
    path:
      - "{{BaseURL}}/.git/config"
    matchers-condition: and
    matchers:
      - type: word
        words: ["[core]", "repositoryformatversion"]
        condition: and
      - type: status
        status: [200]

Requests support method, a list of paths, headers, a body, and payloads, named value lists substituted into {{placeholders}} across the path, body and headers, which cortex expands into concrete requests (bounded for safety). Placeholders include {{BaseURL}}, {{RootURL}} and {{Hostname}}, your own payload names, and {{interactsh-url}} for out-of-band checks. External templates load from the directory set with templates_dir or the CORTEX_TEMPLATES_DIR environment variable, on top of the built-in set, which always runs. The built-ins cover common high-signal exposures: .git/config and .env files, private keys and cloud credentials, backup files, directory listings, phpinfo and server-status pages, debug stack traces, path traversal and blind SSRF.

Matchers

A matcher decides whether a response is a hit. cortex supports:

Matcher	Fires when
`status`	The response status code is in a given list.
`word`	The response contains given substrings, combined with and / or.
`regex`	The response matches given regular expressions.
`size`	The response body length is one of given sizes.
`dsl`	A boolean expression over the response evaluates true.

Each matcher can target a part of the response (body, headers, or the whole raw response), can be combined with and / or via matchers-condition, and can be marked negative to require that something is absent.

The expression DSL

The dsl matcher evaluates a boolean expression against the response, for checks a plain word or status match cannot express, for example status_code == 200 && icontains(body, 'werkzeug'). It exposes response variables (status_code, body, headers, content_length), the usual comparison and logical operators, and helper functions including contains, icontains, startswith, endswith, contains_any, contains_all, regex, len, tolower and trim.

Out-of-band confirmation

Some vulnerabilities never show in the response: the target just makes an outbound request if it is vulnerable. cortex confirms these by embedding a unique out-of-band callback URL in the payload ({{interactsh-url}}), firing the check, and watching for the callback. A received callback is high-confidence proof the vulnerability fired: this is how cortex confirms blind SSRF, blind injection and similar flaws. cortex never reports a blind finding without a real callback, so there are no phantom out-of-band alerts. Out-of-band checks run when an out-of-band endpoint is configured for the engine; otherwise those templates are safely skipped.

Authorization testing

cortex includes a dedicated authorization engine, separate from templates, that is hard to test any other way. It takes a set of endpoints and a set of identities (each a role plus its login), replays every endpoint as every identity, and compares the responses to find broken access control:

BOLA / IDOR (object-level): two different users get the identical response body for an object-scoped endpoint (like /invoices/3), meaning the object is not scoped to its owner. Reported critical. cortex spots object references both in the path (numeric ids, UUIDs, opaque handles) and in query parameters (?account_id=…, anything ending in _id), and is precise enough not to flag ?page=2.
BFLA (function-level): a non-privileged identity reaches a privileged endpoint (/admin, /manage, /internal and the like) that a privileged identity also reaches, proving it is a live function and not a 404. Reported high.
Broken authentication: an anonymous request reaches a protected endpoint that should require a login. Reported high.

Every finding carries a per-identity response matrix (who got which status and body size) as its evidence, and cortex guards against false positives from soft "please sign in" pages and login redirects.

Correctness and resilience

cortex is built to be trusted, not just noisy. Every candidate goes through a generate, detect, confirm, report pass: a response-based match is re-issued and must reproduce before it becomes a finding; an authorization candidate is re-probed as the accused identity; a blind check must produce a real callback. And it is resilient to rate limiting: on a 429 or 503 it backs off and retries rather than giving up, so a busy or WAF-fronted target does not quietly hide real vulnerabilities. The result is a low false-positive rate and findings you can put straight into a report.

Standalone usage

cortex --daemon &                      # start the engine (port 4445)
cortex scan https://example.com

# high/critical only, external templates, authenticated
cortex exec '{"operation":"scan","target":"https://example.com","severity":["high","critical"],"templates_dir":"/opt/nuclei-templates","auth":{"headers":{"Authorization":"Bearer <token>"}}}'

# authorization testing across two identities (BOLA / BFLA)
cortex exec '{"operation":"authz","endpoints":[{"method":"GET","url":"https://api.example.com/invoices/3"}],"identities":[{"role":"user_a","auth":{"cookies":"session=a..."}},{"role":"user_b","auth":{"cookies":"session=b..."}}]}'

Key options

Option	What it does
`target`	URL or host:port to scan.
`severity`	Restrict to given severities such as high or critical. Empty runs all.
`templates_dir`	External nuclei template directory, in addition to the built-ins.
`passive_only`	Only run passive header checks; make no active requests.
`auth`	Headers and cookies for authenticated scanning.
`timeout_ms` `follow_redirects`	Per-request timeout and whether to follow redirects.

Output

Each finding carries the target, severity, name, the template id that fired, the exact URL it matched at, a description and evidence, all marked confirmed. Passive checks also flag missing security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options). On the platform, cortex runs as a vulnerability-scan workflow against the surface the earlier engines mapped, uses scout's fingerprints and CVE leads to focus where it matters, and streams confirmed findings into your Findings explorer.