Skip to content
SecretPNG

Responsible Disclosure Policy

How to report security vulnerabilities in SecretPNG, the safe harbor for good-faith research, and what to expect from us.

Effective 2026-07-14 · Last updated 2026-07-14

This document is a draft prepared for launch and requires review by qualified legal counsel before public launch.

Our commitment to security research

SecretPNG (secretpng.com), operated by SecretPNG (legal entity to be confirmed before launch), is a security tool in beta that has not yet been independently audited. That makes outside scrutiny more valuable to us, not less. Our encryption formats are open and documented precisely so that researchers can inspect them, and this policy exists so that people who find problems can tell us safely.

If you believe you have found a vulnerability in SecretPNG — in the in-browser cryptography, the tool implementations, the secret-link service, or the site itself — we want to hear from you.

How to report

Email security@secretpng.com. Reports in plain English are fine; you do not need a formal template. A useful report typically includes:

  • A description of the vulnerability and where it lives (tool, endpoint, or format).
  • Steps to reproduce, proof-of-concept code, or a worked example.
  • The impact as you understand it — what an attacker could actually do.
  • Your environment (browser, OS) if the issue is client-side.
  • How you would like to be credited, or a note that you prefer to stay anonymous.

Scope

In scope: the secretpng.com site, the in-browser tools and their documented encryption formats, the secure secret-link service (Cloudflare Workers endpoints and their behavior), and the interaction between them — for example, a way to make the client leak key material to the server, a flaw in the cryptographic design, a way to read another user's ciphertext or metadata, or a bypass of expiration, view limits, or the hashed management token.

Out of scope: vulnerabilities purely in third-party platforms (Cloudflare, Google, Resend) that are not specific to our configuration; clickjacking on pages with no sensitive action; reports that a browser extension or a compromised device can read what the user is doing (that is outside any web app's threat model); volumetric denial-of-service findings; and social engineering of any person.

Rules of engagement

To keep research safe for our users, we ask that you:

  • Never test against other users' data. Create your own secret links and test against those. Do not attempt to access, decrypt, enumerate, or delete secrets you did not create.
  • Do not degrade the service: no denial-of-service testing, no sustained automated flooding, no resource exhaustion.
  • Do not exfiltrate data beyond the minimum needed to demonstrate the issue, and delete anything you obtained once the report is resolved.
  • Use test data, not real secrets, in proofs of concept.
  • Give us a reasonable opportunity to fix the issue before disclosing it publicly (see the coordinated disclosure section).

Safe harbor

We will not pursue or support legal action against you for security research conducted in good faith and in accordance with this policy. We consider such research authorized under applicable anti-hacking and anti-circumvention laws (including the Computer Fraud and Abuse Act and DMCA section 1201 in the United States, and analogous laws elsewhere) to the extent we are able to authorize it, and we waive claims we might otherwise have under our own terms for actions taken in genuine compliance with this policy.

If a third party initiates legal action against you for research covered by this policy, we will make it known, upon your request, that your actions were conducted in compliance with this policy. This safe harbor does not cover research that violates the rules of engagement — in particular, testing against other users' data is never authorized.

What to expect from us

When you report a vulnerability in good faith, we commit to:

  • Acknowledging your report promptly and telling you who is handling it.
  • Keeping you informed as we validate, prioritize, and fix the issue.
  • Not referring you to law enforcement or initiating legal action for good-faith research within this policy.
  • Telling you when the fix ships, and crediting you if you want credit.

Coordinated disclosure and the 90-day target

We work to a 90-day coordinated disclosure target: from the date we validate your report, we aim to ship a fix and agree on public disclosure within 90 days. If a fix is ready sooner, we are happy to disclose sooner by mutual agreement; if an issue is unusually complex, we may ask for a limited extension and will explain why.

If we are unresponsive or fail to act in that window, we recognize your right to disclose responsibly on your own timeline. We only ask that disclosure not include working exploits against unfixed issues affecting live user data.

Acknowledgments

We maintain an acknowledgments page crediting researchers who have reported valid vulnerabilities, listed with their permission and in the form they prefer (name, handle, or link). Anonymous reporting is always an option, and choosing anonymity does not affect how we handle the report.

No paid bounty program at this time

SecretPNG is a free service in beta and does not currently operate a paid bug bounty program. We are transparent about this up front so there is no ambiguity: valid reports earn our genuine thanks, a fix, and public credit if you want it. If we introduce a paid program later, this policy will be updated to say so.

Why some classic findings do not apply here

SecretPNG's architecture removes some common vulnerability classes, and reports should account for it. There are no accounts, so there is no authentication to bypass, no password database to leak, and no session fixation. The server never holds plaintext or decryption keys for secrets, so a server-side database exposure — while still a serious finding we want reported — yields ciphertext and metadata, not user secrets. Findings that demonstrate a path from this baseline to actual plaintext exposure are the highest-severity reports we can receive.

Reporting non-security issues

Bugs without security impact, accessibility barriers, and general feedback should go to support@secretpng.com rather than the security address, so that the security inbox stays fast for vulnerability reports. Abuse of the service (for example, a phishing campaign using secret links) should also go to support@secretpng.com, as described in the Acceptable Use Policy.

Changes and draft status

We may update this policy as the service and its threat model evolve; updates are posted with a new effective date, and research conducted under the version in force at the time remains covered by that version's safe harbor.

This document is a draft prepared for launch and requires review by qualified legal counsel before public launch.