Findings & Validation
Cyrion AI reports a vulnerability only when an agent has demonstrated it. Every finding is backed by evidence you can reproduce.
Cyrion AI reports a vulnerability only when an agent has demonstrated it. Every finding is backed by evidence you can reproduce.
What a finding contains
| Field | Description |
|---|---|
| Title and severity | Critical, High, Medium, Low or Info. |
| CVSS score and vector | A standard severity score with its full vector string. |
| Category | The vulnerability class, such as injection or broken access control. |
| Affected asset | Host, endpoint, HTTP method and parameter involved. |
| Description | What the weakness is and why it matters. |
| Proof of concept | The exact request, payload or steps that demonstrate the issue. |
| Validation status | Whether the proof of concept was independently replayed, with a confidence score. |
| Reproduction steps | How to trigger the issue yourself. |
| Remediation | Concrete guidance for fixing it. |
| Evidence | Supporting artifacts. Hacker and above add browser-captured screenshots and visual proof. |
How findings are validated
- An agent discovers a candidate weakness.
- It builds a proof of concept to exploit it for real.
- The proof of concept is re-run and checked against what the target actually returned.
- Only confirmed results are promoted to a finding. Duplicates found by different agents are merged.
This is why Cyrion AI findings arrive with proof rather than a hunch.
What Cyrion AI detects
- Access control — IDOR, privilege escalation, authentication bypass, BOLA and BFLA.
- Injection — SQL, NoSQL, command and template injection.
- Server-side — SSRF, XXE, insecure deserialization, file inclusion.
- Client-side — XSS, prototype pollution, DOM vulnerabilities, CSRF.
- Authentication and sessions — JWT flaws, weak session handling, MFA bypass.
- Business logic — race conditions, workflow manipulation, pricing and limit abuse.
- Secrets and data exposure — leaked keys, tokens and sensitive data in responses and code.
- Infrastructure — misconfigurations, exposed services and outdated components.
- Mobile — insecure storage, weak transport security, exported components.
- Cloud — public storage, over-permissive identity policies, exposed resources.
- AI systems — prompt injection, jailbreaks, data leakage and unsafe tool use.
Working with findings
Open Vulnerabilities for every finding across your scans, filterable by severity, status, target and domain. Analytics shows trends over time. Domain views are plan-dependent: Web is available to every plan, Mobile from Hacker and Cloud from Red Team.
| Action | Description |
|---|---|
| Triage | Update status and severity as your team reviews each issue. |
| Retest | Launch a focused scan against a single vulnerability to confirm a fix. |
| Create a ticket | Send a finding to Jira with one click, or track it as a GitHub issue. |
| Comment | Discuss a finding with your team. |
| Tasks | Turn findings into remediation tasks on the Taskboard. |
| Favorite | Pin scans, reports and findings you return to often. |
Tip: After shipping a fix, use Retest on the finding. It is faster and cheaper than re-running a full scan.
Understanding severity
| Severity | Typical meaning |
|---|---|
| Critical | Direct, easily exploited compromise of data or systems. Fix immediately. |
| High | Serious weakness that is likely to be exploited. Fix in the current cycle. |
| Medium | Real weakness with limiting conditions. Plan a fix. |
| Low | Minor issue or defense-in-depth gap. |
| Info | Observation worth knowing, not a vulnerability by itself. |