Report a security issue.
Safely and in good faith.

Section 1

How to report

Email the dedicated security inbox. It's monitored by a person, not an autoresponder, and it's the only address we treat as a security channel.

If your report contains sensitive proof-of-concept material and you'd like to encrypt it, get in touch first and we'll exchange a PGP key. Plain-text email is fine for anything that can safely travel over TLS.

Section 2

What to include in your report

Reports triage faster when we can reproduce quickly. None of the fields below are compulsory — they're what usually helps most.

If your report depends on a specific vendor or buyer account, please use your own test account. Do not access, modify, or attempt to access data belonging to other users — see the safe-harbour promise in Section 6.

Section 3

Scope

These are the surfaces we own and operate. Reports on anything below are in scope for the disclosure programme.

The FYSH web application at www.fysh.uk, all public and authenticated pages under that host, every API endpoint under /api/, the vendor workbench, the admin surface, and the shared session, authentication and CSRF flows across all of them.

We're especially interested in reports covering:

• Authentication, session, MFA, and account-recovery flaws
• Authorisation and access-control bypasses (a buyer seeing vendor-only data, cross-tenant access, admin-only endpoints reachable without admin)
• Server-side injection: SQL, command, template, deserialisation, XXE
• Content-Security-Policy bypasses leading to XSS
• CSRF against state-changing endpoints
• Server-side request forgery (SSRF)
• File-upload handling and stored malicious content
• Cryptographic failures — the encryption at rest for PII fields, the master-key wrapping, session tokens, password reset tokens
• Business-logic flaws in Price Broker bidding, EOI lifecycle, or vendor payouts

Section 4

Out of scope

These aren't accepted — either because we already know, because they don't map to a real user impact, or because they'd break the site for other people.

The following are also excluded from the programme:

• Reports based purely on the output of automated scanners (SSL Labs, Observatory, sitesecurityscore, etc.) without a concrete exploit path
• Missing security headers on responses where the CSP already blocks the underlying risk
• Rate-limit weaknesses without a demonstrated escalation path
• SPF / DKIM / DMARC misconfigurations that aren't exploitable in practice
• Vulnerabilities affecting only end-of-life browsers
• Third-party services and libraries — please report those upstream
• Self-XSS, tab-nabbing without a real impact, clickjacking on pages with no sensitive actions
• Reports without a proof of concept

Section 5

Our response commitments

What you can expect from us after you send a report. These are commitments, not aspirations — if we're going to miss one, we'll tell you before the deadline.

Section 6

Safe-harbour promise

Good-faith security research is welcome. If you're acting in line with the conditions below we won't pursue legal action, and we'll actively defend your position where we're asked to.

• Report the issue promptly and privately using the contact in Section 1
• Make a good-faith effort to avoid privacy violations, data loss, and service disruption
• Never access, modify, download, exfiltrate or destroy data belonging to other users — use your own test accounts
• Never perform any denial-of-service testing
• Stop testing and contact us immediately if you encounter user data
• Give us reasonable time to fix the issue before disclosing publicly (see Section 7)

This safe harbour is a promise from FYSH; it can't waive statutory or third-party rights and it can't authorise conduct that would breach the Computer Misuse Act 1990 or equivalent overseas law. Where a research method sits at the edge, ask us first — we'd rather clarify scope than have to declare something out-of-bounds after the fact.

Section 7

Disclosure timeline

We follow coordinated disclosure. That means the fix goes live first, then we agree the shape and timing of any public write-up with you.

The default window is 90 days from your first report to public disclosure. Complex fixes needing architectural change can extend this by mutual agreement — we'll tell you if we need more time and why. Simple fixes may happen much faster: some go out within a day.

Once the fix is live you're welcome to publish a technical write-up, present at conferences, blog about it — we'll happily review a draft for accuracy if you want a sanity check.

Section 8

Recognition

Public credit if you'd like it, private thanks if you'd prefer. We do not currently offer a monetary bounty — that may change, and if it does, past reporters are counted retroactively.

Tell us in your report how you'd like to be credited: a real name, a handle, a link, or "please stay anonymous". We publish acknowledgments at /security-acknowledgments once the fix is live and any embargo has passed.

Section 9

Legal & jurisdiction

This policy is offered under the laws of England & Wales.

Nothing on this page creates a contract between you and FYSH, but the commitments here are made in good faith and will be honoured. Reports that describe illegal activity by third parties — for example, credential-stuffing operations or account takeover services — may be shared with law enforcement, but only after we've had a chance to contact the reporter and only where genuinely required by law.

This policy supersedes any previous FYSH statement on vulnerability handling. If you're looking at an older screenshot or archived version, please use the current version at fysh.uk/security-policy.