Vulnerability Reporting Guide

Seven steps from finding an issue to a coordinated fix: where to send it, how to confirm it safely, what to write and how severity is rated.

Last updated 24 October 2026

Start a report Researcher portal

01Choose the right route

Check the scope first. Systems that belong to the website’s service providers, or to anyone else, should be reported to their owners.

This website or Quantix systems
The site, its form endpoint, PDF generation, token scanner or any other Quantix-operated system.
Report through the contact form
Research programmes
Findings in Quantix research programmes and challenges.
Use the researcher portal

02Confirm the issue safely

Reproduce it at least twice, using only your own accounts and data.
Stop as soon as you have shown the impact. Do not pivot, escalate or keep access.
For smart contracts, prove the issue on a local fork or test network, never against deployed funds.
Record the exact version you tested: commit, deployment date, or the date and time of testing.

03Write the report

A good report lets a reviewer reproduce the issue without asking questions. Plain text is fine. This structure covers everything triage needs:

vulnerability-report.txttext

1Title:        <one line: component + weakness + impact>2Route:        website | research programme <slug>3Component:    <URL, endpoint, contract and function, or file and line>4Version:      <commit, deployment date, or date and time you tested>5Class:        <e.g. Access control (CWE-284, SC01:2025)>6Severity:     <Critical | High | Medium | Low | Informational>7Reasoning:    <impact: what an attacker gains; likelihood: preconditions>8 9Steps to reproduce101. ...112. ...12 13Expected result: ...14Actual result:   ...15 16Impact17<who is affected, what can be lost or changed, under what conditions>18 19Proof of concept20<minimal test or request sequence; link to a private repository if large>21 22Suggested fix (optional)23Credit:       <name or handle to credit, or "no credit">

Map the weakness to a CWE and, for smart contracts, to the nearest OWASP Smart Contract Top 10 entry if you can. The standards crosswalk lists common classes with both.

04Rate the severity

Quantix rates impact and likelihood separately and reads the severity from the matrix, using the same rubric as its assessment methodology. Give your own rating and reasoning; the reviewer will share theirs, and any difference is discussed rather than imposed.

Severity levels, definitions and examples
Severity	Definition	Examples
Critical	Direct loss of funds or permanent loss of control is achievable with little or no precondition.	Any unprivileged path to steal or permanently lock funds in a contract; remote code execution on the server.
High	Material loss or protocol disruption is achievable under realistic conditions.	Reading another person’s form submission; sending email through the website to arbitrary recipients; bypassing an upgrade timelock.
Medium	Limited loss, degraded functionality, or impact that depends on specific conditions.	Stored script injection that the Content-Security-Policy blocks but that still alters page content; a griefing path that delays withdrawals.
Low	Minor impact, defence-in-depth gaps, or issues with unlikely preconditions.	Bypassing the form rate limit at low volume; information disclosure without a practical attack path.
Informational	Code quality, documentation or best-practice observations without direct security impact.	Hardening suggestions, such as a header or configuration change, with no demonstrated impact.

Severity is determined by combining impact and likelihood
	Low likelihood	Medium likelihood	High likelihood
High impact	Medium	High	Critical
Medium impact	Low	Medium	High
Low impact	Low	Low	Medium

Impact measures what an attacker gains or what users lose. Likelihood measures the preconditions, cost and privileges required. Findings without security impact are reported as Informational.

For issues in the website’s web or API layer you may also include a CVSS v4.0 vector. It is recorded alongside, not instead of, the Quantix rating.

05Protect sensitive details

Never include private keys, seed phrases, passwords or other people’s personal data.
Describe the proof of concept in the first message; share runnable exploit code once a secure channel is agreed.
Large proofs of concept belong in a private repository that you share with the coordinator.

Reports are received through the contact form with the topic “Responsible disclosure”, which routes them to the people who handle security reports.

06Send it

Use the contact form with the topic “Responsible disclosure” for this website and Quantix systems, or the researcher portal for research programmes. Both give you a reference number on screen only once the submission has actually been delivered; if delivery fails, the form says so and nothing is recorded as received.

Keep the reference number and quote it in any follow-up.

07What happens next

Acknowledge. The report is logged under a reference number and a named coordinator confirms receipt.
Triage and validate. A reviewer reproduces the issue, rates it on the Quantix severity rubric and shares the rating and reasoning with you.
Remediate. The owner of the affected system develops a fix or mitigation. Timelines are set by severity and complexity and agreed with you.
Verify. The fix is reviewed against your reproduction steps. You are invited to confirm it.
Disclose and credit. Details are published on a date agreed with you, with credit in the form you choose, or none if you prefer.

No fixed response times are promised; milestones are agreed with you after triage. Please keep the details confidential until the agreed disclosure date.