Vulkro Red Coming soon
See which findings chain into a break-in.
Vulkro Red takes what Vulkro and Vulkro for Salesforce found and orders it into the route an attacker would take, stage by stage. It reads only the code on disk: it never sends a request to your systems or touches a live one, and its only connection is to the model you choose.
Coming soon. An offline red team on the same engine as the reviews.
01
recon
214 routes inventoried from the router table, 18 with no guard
src/routes/index.ts:31
VULK-031102
initial access
Invoice read route is reachable without a session
src/routes/invoice.ts:47
VULK-1042CWE-30603
protection bypass
requireAuth is mounted after the invoice router, so it never runs
src/app.ts:88
VULK-1180CWE-28404
injection
Path parameter reaches the query builder without a bound parameter
src/db/invoice.repo.ts:126
VULK-2207CWE-8905
broken access
Lookup carries no owner or tenant predicate, so any id resolves
src/services/invoice.service.ts:212
VULK-1305CWE-63906
exfiltration
Serializer returns 12 customer fields, including billing address
src/serializers/invoice.ts:64
VULK-1544CWE-200Critical
Ceiling: a strongly grounded static path. Nothing on this chain was executed, so no stage is labelled confirmed.
An example chain. Every stage cites the file and the line the engine read.
01Why a red team
Problems that combine are riskier than each alone.
A review lists what is wrong. Vulkro Red shows how those problems combine into an attack.
- Severity rates each problem alone
- The right question for fixing, and the wrong one for deciding what an attacker does next.
- Risk depends on how they combine
- A Medium problem that makes a High one reachable is worse than either alone.
- Every stage cites a file and a line
- The one the engine actually read, or it is not printed. No stage exists only in a model's imagination.
02The scope
Your code, what you installed, and your org.
The same reading covers the code you wrote, the code you installed, and the org you deployed into.
Supply chain
Hostile package families, hijacked releases and install-time scripts, placed on the chain where they actually enter.
Salesforce
An Apex query that trusts its caller, and an org setting that lets a guest be that caller: two half-problems joined into one path.
Nothing to authorise
No request is sent to your systems, no server is touched, no exploit is run. Its only connection is to the model you choose. There is no engagement letter, only a reading of the code on disk.
03How a chain is built
Printed only when every stage is backed.
A chain appears only when the review's own map backs every stage, and each limit of a static read is named before you rely on the result.
- Backed at every stage
- A way in that reaches the code, a path the data can travel, and a place it does damage, each backed by the map the review built.
- Never called confirmed
- Nothing is executed, so the ceiling is a strongly grounded static path, and the report says so on every chain.
- The engine checks the story
- A local model on your machine proposes attack leads, at temperature zero by default. Every lead is checked against the call graph, the endpoint inventory and reachability, and the chain text is built from the engine's findings.
What it reads
- source
- configuration
- lockfiles
- Runtime behaviournothing is executed
- Business logicno specification to compare the code against
- Dynamic dispatchno value to follow when a call is built at runtime
- Exploitability as deployednetwork position is not in the code
- Unsupported languagesno grammar loaded, so no parse tree to walk