Preparing your learning space...
57% through Ethical Hacking tutorials
Responsible Disclosure (also known as Coordinated Disclosure) is a security practice where a security researcher or ethical hacker reports a discovered vulnerability to the affected organization privately and gives them a reasonable amount of time to fix it before making any details public.
The core idea: Give the defenders a head start before revealing the flaw to the world (including malicious actors).
The term "Responsible Disclosure" was coined by security expert Scott Culp (Microsoft) in 2002 to distinguish ethical disclosure from "Full Disclosure" (immediate public release). However, some prefer "Coordinated Disclosure" because the word "responsible" can imply that any other approach is "irresponsible" — which is a point of debate in the security community.
Without responsible disclosure, the security ecosystem breaks down:
| Scenario | Result |
|---|---|
| Immediate public disclosure | Attackers learn about the flaw before a fix exists → Zero-day exploitation |
| No disclosure at all | Vulnerability remains unpatched indefinitely → N-day exploitation (after someone else finds it) |
| Responsible disclosure | Organization has time to fix; users are protected |
| Selling to criminals | Active exploitation with no public fix; victims have no protection |
| Selling to governments | Stockpiled for intelligence/offense; no fix for civilians |
| Vulnerability | Who Found It | Disclosure Decision | Impact |
|---|---|---|---|
| Heartbleed (2014) | Google Security + Codenomicon | Responsible — coordinated with OpenSSL | ~17% of SSL servers vulnerable, but patched before mass exploitation |
| EternalBlue (2017) | NSA | Not disclosed — used as weapon; later leaked by Shadow Brokers | WannaCry ($4B damage), NotPetya ($10B+) |
| Log4j / Log4Shell (2021) | Chen Zhaojun (Alibaba) | Responsible — reported to Apache on Nov 24, 2021 | CVE fixed Dec 6; public disclosure Dec 9. Still massive exploitation within hours |
| SolarWinds (2020) | FireEye | Detected during an attack (supply chain compromise) | Not a disclosure case — it was an active state-sponsored attack |
A researcher finds a vulnerability through many possible avenues:
| Discovery Method | Legitimate? | Authorization? |
|---|---|---|
| Authorized pentest (within scope) | ✅ Yes | ✅ Yes |
| Bug bounty program | ✅ Yes | ✅ Yes (by program terms) |
| Accidental discovery (stumbled upon it) | ⚠️ Grey area | ❌ No |
| Personal research (public software) | ⚠️ Depends on ToS | ❌ Unlikely |
| Reverse engineering (purchased software) | ⚠️ Varies by jurisdiction | ❌ May violate EULA |
| Unauthorized testing | ❌ No | ❌ No — illegal |
Before contacting the organization, the researcher should:
The researcher contacts the organization privately.
Where to report (in order of preference):
| Contact Method | How to Find | Security Level |
|---|---|---|
| Bug bounty platform | HackerOne, Bugcrowd, Synack (if program exists) | 🔒 Encrypted |
| security@company.com | Falls through to security team | ⚠️ May not be encrypted |
| PSIRT email (Product Security Incident Response Team) | psirt@company.com | 🔒 Usually monitored |
| Security contact page | /.well-known/security.txt or /security | ✅ Standard |
| PGP-encrypted email | Find key on keyserver or company website | 🔒 Best |
What a good disclosure report includes:
Subject: Security Vulnerability: [Product X vY.Z] - [Vulnerability Type]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. SUMMARY
Product: ExampleApp v2.1.0
Type: SQL Injection (Time-Based Blind)
CVE Status: Not yet assigned
Severity: Critical (CVSS 9.8)
2. IMPACT
An unauthenticated attacker can extract the full database
contents including user credentials, PII, and financial data.
3. STEPS TO REPRODUCE
1. Navigate to https://app.example.com/login
2. Intercept POST /api/v2/login
3. Send: username=admin' OR (SELECT sleep(5) FROM users)='
4. Observe 5-second delay confirming SQL injection
4. AFFECTED VERSIONS
ExampleApp v2.1.0 through v2.1.3 confirmed vulnerable.
v2.0.x and earlier not tested.
5. PROOF OF CONCEPT (see attachment)
- PoC script: sqli_exploit.py
- Screenshot: evidence.png (redacted)
6. SUGGESTED FIX
Use parameterized queries / prepared statements.
See OWASP SQL Injection Prevention Cheat Sheet.
7. DISCLOSURE TIMELINE (Proposed)
- Today: Initial report
- +30 days: Vendor patch expected
- +45 days: Public disclosure (if no patch, discuss extension)
8. CONTACT
Researcher: Jane Researcher
PGP Key ID: 0xDEADBEEF
Phone: [optional, for critical issues]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Typical industry-standard timelines:
| Severity | Fix Window | Extended (Complex Issues) |
|---|---|---|
| Critical (CVSS 9.0+) | 7 days | 14 days |
| High (CVSS 7.0-8.9) | 30 days | 45 days |
| Medium (CVSS 4.0-6.9) | 60-90 days | 120 days |
| Low (CVSS 0.1-3.9) | 90-120 days | 180 days |
Considerations for extended timelines:
- OpenSSL / cryptographic libraries — affect millions of products
- Kernel vulnerabilities — require reboots, careful testing
- Hardware/firmware flaws — may require physical replacement
- Third-party dependencies — fix must propagate through supply chain
- Regulatory environments — some industries (medical, aviation) require certification of patches
Google Project Zero's 90-Day Policy:
Google Project Zero follows a strict 90-day deadline from the date of first report. Regardless of whether a patch is ready, the vulnerability details are publicly disclosed on day 91. This has been controversial:
| Pros | Cons |
|---|---|
| Forces vendors to prioritize security | Can expose users to attacks if no patch exists |
| Public accountability | Zero-days become N-days without fix |
| Industry has improved (Windows, iOS patching cycles are faster) | Increased pressure can lead to rushed/broken patches |
The organization develops, tests, and deploys a fix:
What a good security advisory includes:
SECURITY ADVISORY: SA-2026-007
─────────────────────────────────
Product: ExampleApp v2.1.0 - v2.1.3
CVE ID: CVE-2026-12345
Severity: CRITICAL (CVSS 9.8)
Published: July 20, 2026
Description:
An SQL injection vulnerability in the login endpoint allows
unauthenticated attackers to execute arbitrary SQL queries.
Affected Versions:
ExampleApp v2.1.0 through v2.1.3
Fixed in:
ExampleApp v2.1.4
Remediation:
Upgrade to v2.1.4 immediately. If upgrade is not possible,
block access to /api/v2/login at the WAF level until upgrade
can be performed.
Credit:
Jane Researcher (HackerOne: @janeresearcher)
After the fix is deployed, the researcher may publish:
Best Practices for Public Disclosure:
| Do | Don't |
|---|---|
| Wait for the patch to be available | Publish before the fix is released |
| Redact sensitive data from PoC | Include working exploit code targeting unpatched systems |
| Credit the vendor for their response | Shame the vendor for slow response (unless unreasonable) |
| Acknowledge any bug bounty received | Publish confidential communications without permission |
| Provide constructive analysis | Make it easy for script kiddies to weaponize |
| Detail | Info |
|---|---|
| Type | Buffer over-read in OpenSSL's TLS heartbeat extension |
| Severity | Critical — leaked memory contents (private keys, passwords, session data) |
| Impact | ~17% of all SSL servers affected |
| Discovered by | Google Security (Neel Mehta) + Codenomicon independently |
| Disclosure Process | Reported to OpenSSL Foundation → Coordinated fix developed → Public disclosure April 7, 2014 |
| Result | Patched released simultaneously with public disclosure. No known exploitation before disclosure. Considered a model case of responsible disclosure. |
| Detail | Info |
|---|---|
| Type | Remote Code Execution via JNDI lookup in Apache Log4j logging library |
| Severity | Critical (CVSS 10.0) — unauthenticated RCE |
| Impact | Billions of devices, virtually every enterprise software vendor affected |
| Discovered by | Chen Zhaojun (Alibaba Cloud Security Team) |
| Disclosure Process | Reported to Apache on Nov 24 → Patch released Dec 6 → Public CVE Dec 9 |
| Result | Despite responsible disclosure, attackers began scanning within hours of the CVE being published. Automated worm-like exploitation began within 48 hours. Shows that even responsible disclosure cannot prevent mass exploitation of high-impact vulnerabilities. |
| Detail | Info |
|---|---|
| Type | SMB protocol Remote Code Execution in Windows |
| Severity | Critical — wormable (no user interaction required) |
| Impact | WannaCry ($4B damage), NotPetya ($10B+), and numerous other attacks |
| Discovered by | NSA (Equation Group) — not disclosed responsibly |
| What happened | NSA developed and stockpiled the exploit. The Shadow Brokers group leaked it in April 2017. Microsoft had already released a patch in March 2017 (MS17-010) but many systems were unpatched. |
| Key Lesson | Governments stockpiling vulnerabilities instead of disclosing them responsibly leads to catastrophic civilian damage when those exploits inevitably leak. The EternalBlue leak is the strongest argument against vulnerability stockpiling. |
| Detail | Info |
|---|---|
| Type | OS X privilege escalation — bypass system integrity protection |
| Discovered by | Emil Kvarnhammar (Swedish security researcher) |
| Disclosure Process | Reported to Apple in October 2014. Apple released a fix in April 2015 (6+ months later). |
| Result | Researcher disclosed at a conference after the patch. Apple credited him. Good example of patience with a complex OS-level fix. |
The debate continues:
| Aspect | Responsible Disclosure | Full Disclosure |
|---|---|---|
| Disclosure to vendor | Private, immediate | Private, brief delay or none |
| Public disclosure | After patch is ready (7-120 days) | Immediately or after short deadline |
| Risk to users | Low (patch available first) | High (attackers exploit before patch) |
| Risk to vendor | Low-Moderate | High (public pressure/shame) |
| Argument FOR | Protects users; gives time to fix | Forces vendors to act; no secrets |
| Argument AGAINST | Vendors may delay; users at risk during "window of vulnerability" | Attackers benefit; users caught in crossfire |
| Proponents | Most security professionals, vendors, CERT/CC | Security purists, some researchers |
Bug bounty programs are the formal implementation of responsible disclosure — companies pay researchers for valid vulnerability reports.
| Platform | Researchers | Notable Programs | Model |
|---|---|---|---|
| HackerOne | 700,000+ | Google, Toyota, US DoD, Twitter, Atlassian | Managed + Community |
| Bugcrowd | 400,000+ | Apple, Atlassian, Mastercard, OpenAI | Managed + Community |
| Synack | 1,500+ (invite-only) | US DHS, DoD, major banks | Private (vetted researchers) |
| Intigriti | 25,000+ | European-focused; KBC, Proximus | Community |
| YesWeHack | 25,000+ | European; Orange, La Poste | Community |
| Immunefi | 45,000+ | Crypto/DeFi focused; Ethereum, Polygon, Solana | Smart contract bounties |
| Vulnerability Type | Typical Payout | Max Recorded |
|---|---|---|
| Low (XSS, Open Redirect) | $100 - $1,000 | $5,000 |
| Medium (IDOR, CSRF, SSRF) | $500 - $5,000 | $15,000 |
| High (Auth Bypass, SQLi) | $2,000 - $20,000 | $50,000 |
| Critical (RCE, Chain Exploit) | $10,000 - $100,000 | $1,000,000+ |
| Year | Researcher | Target | Vulnerability | Payout |
|---|---|---|---|---|
| 2022 | (Anonymous) | Apple | Kernel RCE | $500,000 |
| 2023 | (Anonymous) | Meta | Account takeover chain | $200,000+ |
| 2024 | (Multiple) | Microsoft | Hyper-V RCE | $250,000 |
| 2024 | (Anonymous) | TikTok | Various | $100,000+ |
A controversial aspect of disclosure is the vulnerability broker market:
| Broker | Type | What They Do | Controversy |
|---|---|---|---|
| ZDI (Trend Micro) | White market | Buy vulnerabilities, report to vendors, publish after patch | Generally respected |
| Exploit Group | Grey market | Buy exploits, resell to governments | Secretive, may not fix |
| Dark Web Markets | Black market | Buy/sell exploits for criminal use | Illegal |
The Bigger Controversy — Government Stockpiling:
| Country | Known Vulnerability Stockpiling Program | Example |
|---|---|---|
| USA | NSA (Equation Group) | EternalBlue — leaked, caused WannaCry/NotPetya |
| Russia | FSB, GRU | Zero-day exploits used against Ukraine, US |
| Israel | NSO Group | Pegasus spyware — used zero-days against journalists |
| China | PLA/Political | Zero-day exploitation in APT attacks |
The Vulnerability Equities Process (VEP): In the US, the government has a formal process (VEP) to decide whether to disclose a vulnerability to the vendor or retain it for national security purposes. Critics argue the VEP is broken, citing EternalBlue as proof.
CVE (Common Vulnerabilities and Exposures) is the dictionary of publicly known cybersecurity vulnerabilities.
CVE-YYYY-NNNNN
│ │ │
│ │ └── Sequential ID (≥4 digits)
│ │
│ └────────── Year assigned
│
└────────────── Fixed prefix "CVE"
Examples:
CVE-2021-44228 — Log4ShellCVE-2014-0160 — HeartbleedCVE-2017-0144 — EternalBlueCVE-2023-44487 — HTTP/2 Rapid Reset DDoSCNA Types:
| Type | Example | Who They Serve |
|---|---|---|
| Vendor CNA | Microsoft, Google, Apple, Apache | Their own products |
| Researcher CNA | Talos, ZDI | Vulnerabilities they discover |
| National CNA | CERT-Bund (Germany), CERT-FR (France) | Organizations in their country |
| MITRE (Root CNA) | MITRE Corporation | Everything not covered by other CNAs |
| Unethical Practice | Why It's Wrong | Legal Consequence |
|---|---|---|
| Selling on dark web | Enables criminals to attack innocent users | Felony (conspiracy to commit fraud) |
| Public shaming without notice | Puts users at risk for zero-day attacks | Possible lawsuit (negligence) |
| Extortion | Threatening to publish unless paid (beyond bounty) | Blackmail — felony |
| Full disclosure of unfixed flaws | Gives attackers a free map to unpatched systems | May violate terms of bug bounty / NDA |
| Doxxing security contacts | Harassing the individuals who fix bugs | Harassment — criminal |
Many organizations offer Safe Harbor — a legal promise not to sue researchers who follow responsible disclosure:
"We will not pursue legal action against researchers who follow our disclosure policy."
What Safe Harbor covers:
What Safe Harbor does NOT cover:
The US Cybersecurity Information Sharing Act (CISA) and some state laws protect:
| Country/Region | Key Law | Protects Researchers? | Notes |
|---|---|---|---|
| United States | CFAA (18 U.S.C. §1030) | ⚠️ Partially (after Van Buren v. US, 2021) | CFAA reform narrowed "unauthorized access" definition |
| European Union | GDPR + NIS Directive | ✅ Yes (for authorized testing) | Strong data protection; privacy impact |
| United Kingdom | Computer Misuse Act 1990 | ❌ No explicit protection | £5,000 fine + 6 months for unauthorized access (even benign) |
| Germany | §202a StGB (Hacking paragraph) | ✅ Recent reform (2023) protects security research | One of the most progressive EU researcher protections |
| Canada | Criminal Code §342.1, PIPEDA | ⚠️ Mixed | Some specific exemptions for research |
| Australia | Criminal Code Act 1995, Privacy Act | ❌ Limited | High-profile case of researcher prosecuted |
| Netherlands | Dutch Computer Crime Act | ✅ Good (prosecutorial guidelines protect researchers) | Clear published guidelines |
Use this when you find a vulnerability:
You found a vulnerability
│
▼
Are you authorized to test this system?
│ │
YES NO
│ │
▼ ▼
Report via bug bounty Do you have permission
or client channel from the system owner?
│ │
▼ YES │ NO
(Go to │ │
remediation) ▼ │
Report via ────► STOP
security@ │ (It is illegal.
or PSIRT │ Do not proceed.)
│
▼
Is there a bug bounty
or disclosure policy?
│
YES │ NO
│ │
▼ ▼
Follow program Propose a
guidelines timeline to
vendor (7-120 days)
│
▼
Did vendor respond?
│
YES │ NO
│ │
▼ ▼
Coordinate Escalate via
the fix CERT/CC or
reconsider
timeline
Save your progress and earn XP for completing tutorials.
Technology
Cyber Security & Networking
Lesson group
Ethical Hacking
Progress
57% complete