Security & Vulnerability Disclosure

If you have found a security problem in Pexafy, we want to hear about it — and we would rather hear it from you than read about it later. This page tells you where to send it, what we will do with it, and where the boundaries are.

1. How to Report

Email [email protected] with “Security” in the subject line. The same address is published in our security.txt.

A useful report contains:

• What you found, and the URL or endpoint where you found it.
• The steps to reproduce it — a request, a payload, a short script.
• What an attacker could do with it. This is the part that decides how fast we move.

Write in English or French. You do not need an account with us to report something, and we will never ask you for money or an NDA to accept a report.

2. What We Commit To

Pexafy is a small team, so these are deliberately realistic rather than flattering:

• Acknowledgement within 5 working days. A human reply, not an autoresponder.
• An assessment within 30 days — whether we consider it a vulnerability, how severe, and what we intend to do.
• We will tell you when it is fixed, and credit you by name or handle if you want to be credited (see Acknowledgements). Say so in your report; the default is no public mention.
• We will not pursue you legally for research conducted in good faith and within the rules below, and we will not report you to your ISP or employer.

We do not run a paid bug bounty. There is no reward beyond credit and our thanks — we would rather say so plainly than let you spend a weekend expecting one.

3. Scope

In scope — anything we run:

• pexafy.com and its language-prefixed pages
• api.pexafy.com — the public API
• mcp.pexafy.com — the MCP server, including its OAuth flow
• docs.pexafy.com and status.pexafy.com
• The public repositories under github.com/Pexafy and the pexafy package on PyPI

Out of scope — not ours to fix:

• The source platforms we index (Unsplash, Pexels, Pixabay and the others). Report those to them; their images and their APIs are their responsibility.
• Third-party services we use (payment, email, CDN, hosting). We will forward anything that matters, but we cannot patch them.
• Findings that are only a missing best-practice header, a version banner, or the output of an automated scanner with no demonstrated impact.

4. Rules of Engagement

Testing that stays inside these lines is welcome. Testing that crosses them is not research, and the protections in section 2 do not apply to it.

• Use your own account and your own data. Do not access, modify or store another user's data. If you stumble into someone else's data, stop and tell us what you saw — do not keep it.
• No denial of service, no load testing, no traffic floods. Our rate limits are documented; do not try to knock the service over to prove they can be knocked over.
• No social engineering of our team, our users or our suppliers, and no physical attacks.
• No destructive testing — do not delete collections, exhaust quotas or corrupt data to demonstrate that you could.
• Give us time before going public. 90 days is the norm we work to; tell us if you plan to publish sooner and we will try to keep up.

5. Things You Do Not Need to Report

These are known and deliberate, so a report about them will simply be closed:

• The public API is open by design to anyone holding a free key. Enumerating public photos with a valid key is the product, not a flaw.
• /api/v1/billing/plans answers without authentication on purpose — it carries the same public pricing grid as our pricing page, so MCP clients can word upgrade messages.
• Our OpenAPI description is published at api.pexafy.com/openapi.json intentionally.

6. Contact

Security reports: [email protected] (subject: Security).
Everything else: the contact page.

7. Acknowledgements

Our thanks to the researchers who reported security issues responsibly and asked to be credited:

• MD Rabbi Hossain — unauthenticated OAuth Dynamic Client Registration / consent-phishing on the MCP OAuth flow (2026).