Findings
Illustrative, anonymised findings that show how Countermind reports web, API, cloud and Web3 issues. Each one is laid out the way a researcher signs it in a report.
12 of 12 findings
With one merchant's API key, the settlements and IBANs of 1,284 merchants could be read.
Evidence
Web & API · Authorisation
Any pull request could run code that assumed the production administrator role in the cloud account.
Evidence
Cloud · AuthorisationDetail in the report
Two approvals sent at the same moment both succeeded, so one refund was paid out twice.
Evidence
Web & API · Business logicDetail in the report
A regular member could change their own role and gain billing and member management rights.
Evidence
Web & API · AuthorisationDetail in the report
Repeated small withdrawals rounded in the user's favour and slowly drained the vault's other depositors.
Evidence
Web3 · Business logicDetail in the report
An old reset link stayed valid after a password change, so anyone who later got into the user's inbox could still reset the account.
Evidence
Web & API · Session and identityDetail in the report
If the price feed stopped updating, liquidations would continue at an hours-old price.
Evidence
Web3 · Business logicDetail in the report
Anyone with read access to application logs could reuse valid upload links for up to an hour.
Evidence
Cloud · Data exposureDetail in the report
Different error messages let anyone check whether an email address belongs to a customer.
Evidence
Web & API · Session and identityDetail in the report
The endpoint lists service names and versions, which makes later probing easier.
Evidence
Cloud · ConfigurationDetail in the report
No direct risk today. Setting the attribute explicitly keeps behaviour stable across browsers.
Evidence
Web & API · ConfigurationDetail in the report
No direct risk. Monitoring cannot see fee or pause changes until someone reads the state.
Evidence
Web3 · ConfigurationDetail in the report
No finding matches these filters.
Illustrative findings. Anonymised, not customer data.
We publish a finding only when the agreed terms allow it. Names, domains, keys and personal data are removed; the mechanism, the request and the response stay.
Customer names, domains, tokens, personal data and anything that identifies the system.
The class of flaw, the request and the response, the impact and the fix.
In a delivered report, every finding is reproduced in clean runs and signed by a named researcher.
Each filled arm is one step of impact. Colour never carries the meaning alone.
Direct, low-privilege access to the data or money of many customers.
2 of 12 findingsShow theseLoss of data, money or privilege for a single customer or account.
3 of 12 findingsShow theseAn issue that grows when combined with another flaw, or exposes limited data.
3 of 12 findingsShow theseA gap that makes an attacker's job easier but has limited impact alone.
2 of 12 findingsShow theseNo direct risk; a recommendation that strengthens defences.
2 of 12 findingsShow theseIn a delivered report, each finding sits with the scope, the limits and the retest record.
The findings on this page are illustrative and anonymised. Real findings are published only when the agreed terms allow it, with names, domains and data removed.
A finding describes a flaw, not a customer. We never publish who was affected, where, or when the work took place.
A researcher sets it from the demonstrated impact. The Zaaf plus shows it at a glance; CWE and CVSS sit beside it for your tooling.
No. Most findings stay in the customer's report. Publication is opt-in and agreed in writing.
Ask for a shareable sample during the scoping call. A finding page here is one page of a report, without the scope and limits around it.
Thirty minutes with a Zaaf researcher. You bring one scope; we show you what a Countermind would look at first.