Disclosure guidelines

1.Our approach

root-me.cloud follows coordinated disclosure: the person who finds a vulnerability reports it privately to the organization that can fix it, the two work together until it is fixed, and only then do they decide, together, what becomes public.

Three commitments make that work:

• Researchers report through the platform, stay within the program’s policy and keep the details confidential until the report is disclosed.
• Programs respond promptly, keep the reporter informed, fix what is valid and do not take action against good-faith research that followed their policy.
• Nobody publishes alone. A report becomes public only when both the reporter and the program team have agreed to it.

2.Reporting a vulnerability

Start from the program’s page: read its policy, check that the asset is in scope and that the issue is not listed as an exclusion, then use Submit report. A good report contains:

• a short, specific title that names the weakness and where it is;
• the affected asset and the weakness type;
• numbered steps that let the team reproduce the issue, with any request, payload or script needed;
• the realistic impact: what an attacker could do, to whom, and under which conditions;
• what data, if any, you accessed while testing, so the team can assess exposure.

Report one vulnerability per report. If several issues share a root cause, say so in one report rather than splitting it. Never include real user data beyond the minimum needed to prove the issue; redact it instead.

Reports are private: only you and the program team can read them. You can follow every change and comment in your reports.

3.What happens after you submit

Every report moves through the same states. Each change appears in the report thread, so the reporter always knows where things stand.

The team can reopen a closed report if new information appears, until the report is disclosed: disclosed reports no longer change state. Reputation follows the report’s current state, as described on the reputation page.

4.Timelines

Fixing takes as long as it takes, but silence is never acceptable. These are the default expectations on root-me.cloud; a program’s own policy may set different response targets, which its page displays.

5.Requesting disclosure

A report can be disclosed once it is closed as resolved, duplicate, informative or not applicable. Reports closed as spam are never disclosed. The process is the same whoever starts it:

1. One side requests disclosure from the report page. The reporter or the program team can go first, and can add a message explaining what they would like published.
2. The other side agrees, and the report becomes public on Hacktivity at that moment. Until then, nothing changes for the public.
3. A request can be withdrawn by whoever made it, and the program team can decline a reporter’s request. Say why in the thread: “after the next release” is a much better answer than silence.

Before agreeing, both sides should reread the whole report, including comments, and ask for anything sensitive to be removed or summarized instead: secrets, tokens, personal data, internal hostnames or details that would still help an attacker. Disclosure is meant to be permanent.

6.Full or limited disclosure

The program team decides how much of the report is published and can write a public summary, either when it requests disclosure or when it agrees to the reporter’s request.

Choose limited disclosure when the details would still put users at risk, involve a third party, or contain information the organization cannot share. A good summary explains the class of issue, its impact and how it was fixed, without a recipe.

7.What appears on Hacktivity

Hacktivity is the public feed of the platform. It lists two kinds of entries:

• Resolved reports that have not been disclosed appear as a single line naming the program, the reporter’s username and the date. No title, severity, weakness or detail is shown.
• Disclosed reports appear with their title, severity, weakness and public summary, and link to the public report page.

Reports that were not resolved and not disclosed never appear publicly.

8.What you may publish yourself

Before disclosure

Nothing about the vulnerability: no blog posts, talks, videos, social media posts, proof-of-concept code or hints, and no sharing with other people or platforms. This applies to reports that are open, closed or declined for disclosure alike. You may say that you reported an issue to a program, without describing it.

After disclosure

You may write and talk about what the disclosed report makes public. With limited disclosure, that means the title, the metadata and the public summary, not the details that stayed hidden. Ask the program first if you want to go further, and keep its answer in the report thread.

Never

Publish data belonging to the organization’s users or employees, credentials, or anything you obtained beyond what was needed to demonstrate the issue, even after disclosure.

9.CVE identifiers

When a vulnerability affects software that others run, the program may request a CVE identifier from a numbering authority and record it on the report. Once the report is disclosed, its CVE ids are shown publicly and listed in CVE discovery. Researchers who want a CVE should ask in the report thread rather than requesting one independently for an issue that is still private.

10.Exceptions

Coordinated disclosure assumes both sides act in good faith. Two situations change the rules:

• Active exploitation. If you see evidence that the issue is already being exploited, say so in the report immediately. The program should treat it as an emergency and may need to warn users before a fix is ready.
• Third-party software. If the root cause is in a library or product the organization does not control, the program may need to coordinate with that vendor, which can extend timelines. It tells the reporter when that happens.

In every other case, follow these guidelines and the program’s policy. Our code of conduct applies throughout.