Sample finding
What one finding looks like when you open it
This is a sample. ExamplePay, its systems and everything below are fictional, written to show the format. It is not client work, no real system was tested, and the hashes and identifiers are illustrative. The score is real: it is what our scorer returns for this finding's inputs.
A buyer deciding whether to run private testing should see the deliverable first. This is one finding as it appears on the platform: what happened, what it means for the business, how to reproduce it, how it is scored, and the decisions that stay with you.
F-2610-4821 · Another merchant's settlement report can be downloaded by changing its ID
| Engagement | ExamplePay merchant dashboard (sample) |
| Asset | Settlement reports, merchant dashboard |
| Researcher | RSH-7F2A (a stable pseudonym; you never see a legal identity) |
| Exception Impact Score | 5.1 Medium |
| CVSS 3.1 | 6.5 Medium (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) |
| Classification | CWE-639 Authorization bypass through a user-controlled key · OWASP A01:2021 Broken access control |
| Stage | Remediation |
Summary
A signed-in merchant can download any other merchant's daily settlement report. The download link carries a sequential report ID, and the server checks that the requester is signed in but not that the report belongs to them. Changing the number in the link returns someone else's report.
Business impact
Each report lists a merchant's transactions for the day: amounts, settlement totals, masked card numbers and customer reference IDs. Anyone with a merchant account, including one opened for the purpose, could collect the reports of every other merchant by counting through the IDs. That is confidential financial data of businesses who trusted the platform with it, and the kind of exposure a payment company is expected to report to its regulator and its merchants.
Steps to reproduce
- Sign in as merchant A and open Reports → Settlement.
- Download today's report. The request is
GET /api/v2/settlements/reports/88231/download. - Repeat the request with the ID changed to
88230. - The response is merchant B's report, with a 200 status and the full file.
The researcher used two test merchant accounts created for the engagement and stopped after confirming one report from each, as the rules of engagement require. Nobody else's data was kept.
Evidence
- Request and response capture, with merchant B's data redacted by the researcher before upload.
- A 40-second screen recording of steps 1 to 4.
- Each file's SHA-256 hash is recorded before the file is encrypted (AES-256-GCM) and stored, so it still proves what was submitted after the file is deleted on schedule. Every access link issued for a file is written to its chain of custody, and what is served is checked against the recorded hash.
How it is scored
We record both CVSS and the Exception Impact Score. The EIS weights the technical picture by the asset, the data and the regulation that apply. For this finding we set the asset as financial reporting, the data as confidential and the regime as banking and card rules.
| Technical base | Business multiplier | Context | Report quality | EIS |
|---|---|---|---|---|
| 5.27 | 8.7× | +0.45 | +0.55 | 5.1 Medium |
EIS:1.0/AV:N/AC:L/AU:S/C:H/I:N/A:N/AT:FR/DC:C/IR:B → 5.1 MEDIUM
It needs a signed-in account and only reads data, so it is not Critical. It reaches confidential financial data under banking rules, so it is ranked well above the same flaw on a page carrying nothing. How the score works.
Remediation
Check ownership on the server for every report request: look the report up by its ID and the signed-in merchant's ID, and return 404 when they do not match. Replace sequential IDs with random ones as a second layer, not as the fix. Then check the other download endpoints that take an ID, such as invoices, refunds and payout statements, for the same pattern.
What happens to a finding
| Stage | What it means | Who moves it |
|---|---|---|
| Reported | The researcher submits it inside the authorised window and scope | Researcher |
| Validation | Our team reproduces it and sets the score, or closes it as invalid | Our team |
| Disclosure | Sent formally to your named security contact | Our team |
| Remediation | Your team fixes it | Our team records it |
| Retest | The fix is checked; a failed retest goes back to remediation | Our team |
| Closed | Resolved, with the full history kept | Our team |
What you decide, and what is recorded
- Accept or decline. Accept it and you pay the reward you set for its severity before testing began. Decline it with a note and it costs nothing. A decline can be reversed after a retest. Neither is possible while a finding is still unvalidated.
- Calling it an incident. A finding becomes a confirmed incident, and any regulatory reporting clock starts, only through a deliberate, recorded confirmation by you or our operations team. Never by an automatic rule.
- Publication. Nothing about the finding or your organisation is published unless you approve the exact wording.
- The record. Every one of these steps is written to a hash-chained audit log you can have verified.
Want to see it on the live platform? Write to founder@exceptionsecurity.com for a 10-minute walkthrough. If you'd rather start with no commitment at all, the free disclosure programme runs a reporting page in your name, and the free posture check shows what your domain tells a stranger.