Muhammad Zeeshan / security@zeeshan.id

Researcher disclosure terms

How I handle vulnerability disclosure

This document outlines the disclosure timeline and conduct I follow as an independent security researcher. It accompanies every report I submit to a program, vendor, or organization, so the receiving team has a clear understanding of what to expect — and by when.

01

The timeline

Two clocks run depending on how a program responds. Both start the day I submit the report.

Day 0report submitted

Report submitted to vendor security team

The clock starts the moment a report is submitted through the program's official channel. Every disclosure timeline in this policy is measured from this date.

Day 7follow-up

Follow-up if no acknowledgment received

If there's been no acknowledgment by day 7, I send a polite follow-up. Reports can get lost or missed — this is a nudge, not an escalation.

Day 14escalation

Escalation if vendor unresponsive

If the program remains unresponsive past day 14, I escalate — through a platform mediator where one exists (e.g. Bugcrowd, HackerOne, Intigriti), or directly with the vendor for self-hosted programs.

Day 45–90public disclosure

Public disclosure

Absent meaningful engagement, I reserve the right to disclose publicly within this window. A program actively working the issue can always request a reasonable extension rather than have a hard deadline forced on them.

02

Why a fixed timeline at all

For users

Silence shouldn't mean indefinite risk

An unpatched vulnerability that nobody is told about helps no one but an eventual attacker. A disclosure deadline keeps real pressure on programs to act, instead of letting reports go stale forever.

For programs

Predictability, not ambush

A known, published timeline means no program is caught off guard. You always know exactly how long you have, and you can ask for an extension at any point — I'm not looking for a "gotcha."

03

What I commit to before disclosing anything

Private report first, always. Every finding goes to the program or vendor through their official channel before it goes anywhere else. Nothing is disclosed cold.

Clear, reproducible reports. Steps to reproduce, impact, and a suggested fix where relevant — so the clock isn't wasted on back-and-forth clarification.

A heads-up before going public. If the disclosure window passes, I notify the program before publishing, not after.

24-hour response time. Any question, clarification request, or update from the program reaches a reply from me within 24 hours.

Redaction of anything sensitive. Customer data, credentials, or anything that could itself cause harm is never included in a public writeup, regardless of timeline.

No data exfiltration or destructive testing. Proof of concept stays limited to what's necessary to demonstrate impact — never bulk data access, never production damage.

No extortion, no leverage. Disclosure timelines are about transparency, not pressure for payment. Bounty amount is never a condition for staying quiet.

04

If your program already has a VDP

If you run your own VDP or bounty program with a published disclosure window, your terms take precedence for reports I submit under that program — this page is simply my default position when no program-specific terms exist, and a baseline for how I operate in good faith either way. I'm always open to discussing a different timeline or extension directly rather than defaulting to a fixed deadline.

05

Scope and consent

I only test assets that are explicitly in scope under a program's policy, or that I have direct written permission to test. If a finding leads me to an asset I'm not authorized to touch, I stop, document only what's necessary to explain the discovery, and disclose that boundary in the report rather than continuing.

06

Proof of concept handling

PoC videos, screenshots, and request/response captures are stored privately and shared only with the program handling the report. They are never posted, sold, or shown to a third party while a report is open, and any sensitive material (tokens, session data, personal information encountered incidentally) is redacted before it's ever included in a writeup — public or private.

07

Duplicate and known issues

If a program marks a report as a duplicate or already-known issue, I accept that determination in good faith and don't pursue public disclosure to force a bounty reconsideration. Disclosure timelines in this policy apply to genuine, accepted vulnerabilities — not to disputes over report status.

08

Credit and CVE requests

I'll always ask to be credited by name or handle in any public advisory, changelog, or CVE record tied to a report. If a program prefers to credit anonymously or not at all, I respect that — credit is something I ask for, never something I withhold cooperation over.

09

If you're the team receiving my report

This timeline is a default, not an ultimatum

Reply to my report or reach out directly — I'll work with any reasonable timeline you propose.

💬 Response time — 24 hours

security@zeeshan.id