Responsible disclosure policy
This document describes how TEAM N1TRO handles vulnerabilities we find. It is a statement of our own practice, not a set of demands on vendors. Where a vendor runs its own coordinated disclosure policy, theirs governs.
For reports filed through a bug bounty platform such as Bugcrowd, the program’s terms and disclosure rules take precedence over this document. If the platform forbids publication, we do not publish.
1. Contact
To report a vulnerability to us, or to correct an error in one of our write-ups:
- Email:
leaveleave01@gmail.com - If you need encryption, say so in a first message and we will send you a public key.
Useful things to include:
| Field | Notes |
|---|---|
| Target | Affected product, version, URL |
| Class | Vulnerability type (IDOR, SSRF, privilege escalation, …) |
| Reproduction | In order. Raw requests are ideal |
| Impact | What an attacker actually gains |
| Credit | Whether to name you, and whether you plan to publish |
Please do not send sensitive values — real tokens, real user records. If reproduction genuinely depends on them, mask them, or just tell us that masking is not possible.
2. Disclosure window
Once we have reported a finding to a vendor:
- Default window: 90 days, counted from the date of first report.
- A shipped patch ends the wait. Once the fix has reached users and the vendor is comfortable with publication, we can publish from that point.
- The window expiring does not trigger publication. Day 90 is when we start considering publication and re-open the conversation with the vendor.
- Extensions are the default answer, not the exception. If a vendor tells us a fix is in progress and gives us a timeline, we extend.
In practice this collapses to two cases. The patch ships and we write it up, or the patch has not shipped and we keep waiting while staying in contact. There is no automatic “90 days elapsed, publishing now” trigger anywhere in our process.
3. Exceptions
Cases that accelerate publication
- The issue is already public through a third party, or we have reason to believe it is being exploited. Here we prioritise what lets users defend themselves — affected versions, mitigations — while still withholding the detail that makes exploitation easier.
- The vendor has assigned a CVE and published an advisory.
Cases that delay it, or stop it entirely
- Products where shipping a fix is structurally slow: embedded devices, firmware, anything with a multi-stage distribution chain. We follow the vendor’s timeline.
- Issues that cannot be fixed, or where publishing carries more risk than benefit. These may never be published.
- Program or platform terms that restrict disclosure.
- Vulnerabilities that expose third-party data, where the reproduction steps cannot be written safely. We describe the class and the impact and omit the steps.
Not negotiable
- Payment in exchange for staying quiet. We do not do this.
- Stating something we have verified as false. We do not do this either.
- Removing detail or delaying a post at a vendor’s request is negotiable. The two items above are not.
4. What a reporter can expect
If you report something to us:
- Acknowledgement within 3 business days.
- First assessment within 10 days: whether we reproduced it and what we think. If it falls outside our scope, we say so plainly rather than leaving the thread open.
- Credit in the published note, under the name or handle you choose — or no credit, if you prefer.
- Remediation detail if the report concerns something on our side: what we changed and how.
What you should not expect, stated just as plainly:
- Money. We do not run a bounty program.
- Us relaying a report about a third-party product. Going to that vendor directly is faster and loses less in translation.
- Detail on unpublished research we have in flight. This holds regardless of who is asking.
5. Testing limits we hold ourselves to
The same line applies to our own research.
- We do not read more third-party data than is needed to establish that access is possible, and we stop at that point.
- We do not run tests that threaten availability or integrity: load, deletion, modification.
- Data obtained during testing is deleted once the evidence needed for the report is captured.
- Where a vendor publishes a test scope, we stay inside it.
This policy can change. Material changes will bump the updated date on this post, with a note on what moved. Questions go to the address above.