Found a security issue? Tell us. We'll listen.
This policy covers how to report a vulnerability in YionStack, what you can expect from us, and what is in and out of scope. Aligned with the ISO/IEC 29147 standard for vulnerability disclosure and discoverable via /.well-known/security.txt per RFC 9116.
Last updated: 10 June 2026
Email security@yionstack.co.uk
Include reproduction steps, affected URLs / endpoints, your tooling, and whether you have already disclosed elsewhere. Encrypted email is welcome — we will publish a PGP key here when ours is rotated.
What we promise
A real safe-harbour, not the words of one.
Researchers who follow this policy in good faith get the protections below. We treat reports as collaboration — not as PR problems to manage.
Acknowledged within 2 working days
A real human will email you back. No autoresponder loops, no waiting weeks for triage.
No legal action for good-faith research
We will not threaten or pursue legal action against researchers who follow this policy in good faith — including under the Computer Misuse Act 1990.
Status updates while we fix
We give you a fix timeline up front and update you on progress. We will not silently drop a report.
Public credit if you want it
If you'd like, we'll credit you in the resolved-incident note and add you to our acknowledgements page when one exists.
In scope
- yionstack.co.uk and any subdomain hosted at *.yionstack.co.uk
- app.yionstack.co.uk — the authenticated YionStack product
- api.yionstack.co.uk — the YionStack API
- Authentication and session-management flows (sign-in, magic links, passkeys, MFA)
- Business-isolation and authorisation boundaries
- Billing flows, webhook handling, and Stripe integration
- AI Operator tool dispatch and approvals
- Public-site published-business proxies (/p, /s)
Out of scope
- Denial-of-service, volumetric, or resource-exhaustion attacks
- Social engineering of YionStack staff, customers, or vendors
- Physical attacks against YionStack property or personnel
- Findings that require physical access to a victim device
- Attacks against third-party sub-processors (Stripe, Cloudflare, GCP, etc.) — report those to the third party directly
- Vulnerabilities in software we did not write that we are not responsible for shipping (e.g. browser bugs)
- Self-XSS that requires the user to paste payloads into their own browser console
- Missing best-practice security headers without a demonstrable impact
- Reports generated by automated scanners with no proof of impact
- Spam, phishing, or abuse reports — see /contact instead
Rules of engagement
What we ask of researchers.
- Use your own account. Do not access, modify, or destroy data belonging to anyone else. Create test businesses for any reproduction.
- Stop at proof. Demonstrate impact with a single benign payload, then stop. Do not pivot, escalate, persist, or pillage.
- Don't exfiltrate. If a vulnerability exposes data, retrieve only the minimum needed to prove the finding. Delete copies once reported.
- Disclose privately first. Give us reasonable time to fix before sharing publicly. Industry standard is 90 days; for high-severity issues we typically ship inside 7.
- No automated scanning at scale. Scanners that send thousands of requests per minute are indistinguishable from an attack. Throttle, or coordinate with us first.
Bug bounty? Not yet — but we'd like to.
We do not currently run a paid bug-bounty programme. We do credit researchers who disclose responsibly, and we will reach out about a programme as we grow. In the meantime: a clear report, reproduced once, fixed quickly, and credited if you want is the most we can promise — and what we deliver.
General questions about the policy? Get in touch.