← Back to home

/ DISCLOSURE POLICY

Vulnerability Disclosure Policy

Version 1.0 | Effective 2026-08-21

This is a courtesy translation. The Chinese version is authoritative.

This policy has two parts: how we handle vulnerabilities we find in others' systems (Part I), and how to report vulnerabilities in Odysec's systems (Part II).


Part I — When we find a vulnerability

1. Position

Odysec practises coordinated disclosure. Eventual publication serves users, but vendors deserve a reasonable window to remediate first.

We do not sell vulnerabilities. Findings are not sold to brokers, governments, or any third party; they are reported to the affected vendor and the technical details published once the deadline passes.

2. Timeline

Situation Deadline
Standard 90 days from initial report
Vendor actively remediating and communicating Extendable to 120 days total
Patch released Details published 14 days after release
Actively exploited in the wild 7 days
No vendor response within 14 days Escalated to TWCERT/CC or CERT/CC; the clock does not reset

The clock starts when we send the report. It does not pause for unread messages, internal ticket routing, or staff turnover.

3. Process

  1. Report — sent encrypted to the vendor's security contact (searched in order: security.txt, security page, SECURITY.md, general contact), with technical details, reproduction steps, impact assessment, and our contact.
  2. Acknowledgement — we ask vendors to confirm receipt within 14 days.
  3. Coordination — remediation schedule and publication date are discussed; reasonable extensions are granted against concrete progress.
  4. CVE — requested from MITRE or the vendor's CNA.
  5. Publication — a technical report explaining the flaw and its mitigation. We do not release ready-to-use attack tooling.

4. Early publication

We reserve the right to publish early when:

  • the vulnerability is being actively exploited and users need to know to protect themselves;
  • the details have been published or leaked by a third party;
  • the vendor publicly denies the vulnerability or threatens the reporter with legal action;
  • the vendor states it will not fix an issue that poses ongoing risk to users.

5. What we will not do

  • Publish any detail before reporting;
  • Demand payment under threat of publication (voluntarily offered bug bounties are accepted and disclosed in the report);
  • Access more data than verification requires — if user data is encountered accidentally, we stop, notify the vendor, and destroy it;
  • Run destructive tests against production systems.

Part II — Reporting a vulnerability in Odysec systems

6. Safe harbor

If you follow this policy in good faith, Odysec commits:

  • No civil or criminal action against you, and no referral to law enforcement;
  • If a third party sues you, we will state that your conduct was authorised research under this policy;
  • Credit is offered, named or anonymous, at your choice.

7. Scope

In scope: domains under Odysec and their subdomains, published tools and code, public-facing services.

Out of scope: third-party services (even ones we use), social engineering, attacks on members' personal accounts, physical intrusion, DoS/DDoS, and low-quality automated scan output.

8. Allowed and prohibited

Allowed: non-destructive testing, using only your own test accounts, stopping and reporting as soon as a vulnerability is confirmed.

Prohibited: accessing, modifying, or deleting others' data; degrading or interrupting service; disclosure before agreement; using the vulnerability for anything beyond research.

9. How to report

  • Email: security@odysec.org
  • PGP: fingerprint 1360 6273 6DFC 9D4B C9A1 5312 6FD4 6C88 46C0 DA1B; public key at https://odysec.org/pgp-key.txt
  • Response: acknowledgement within 3 business days; initial assessment within 10.
  • Credit: valid reports are listed in our hall of thanks (anonymity available). There is no cash bounty programme at this time.

Version Date Notes
1.0 2026-08-21 Initial release