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
- 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. - Acknowledgement — we ask vendors to confirm receipt within 14 days.
- Coordination — remediation schedule and publication date are discussed; reasonable extensions are granted against concrete progress.
- CVE — requested from MITRE or the vendor's CNA.
- 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 athttps://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 |