Coordinated Vulnerability Disclosure Policy

Why this page exists

We do independent security research on software used by organisations that did not ask us to look. When we find something, we write to the people who can fix it, privately, first. This page states how we do that — what we will and will not do, what we ask for, and how long we wait — so that an organisation receiving a letter from us can see that we published the rules before we used them.

It is also our commitment to you. If we depart from what is written here, you are entitled to say so.

---

1. How we research

We work from published artifacts. Source repositories, published packages, installers, firmware images and documents that the publisher has made available to the public.

We do not test against systems we do not own. Specifically:

• We do not authenticate to your systems. Not with credentials we were given, not with credentials we found, not with credentials we recovered.
• We do not scan or probe your hosts. Scanning tools - nmap, masscan, sqlmap and their kin - are blocked at the project level, not merely avoided.
• We do not attempt to exploit a live service, even to confirm a finding we are confident about.
• We do not access, copy, modify or delete data that is not ours.
• We do not use a finding to reach another system.

And where we have crossed one of those lines, we say so in the report that rests on it You will find sentences in our advisories of the form "settling this would require one request against your service; we did not make it and will not." Those are not hedges. They are the boundary, stated.

Reproduction happens in our own lab, on our own copies, disconnected. Where a finding was confirmed by running it, we say LAB. Where it was confirmed by reading code, we say STATIC. Where we could not confirm it, we say that too, and we tell you what would settle it.

---

2. What we send you

A private advisory containing, for each finding:

• the affected component and the version range, established from published release history — not guessed from a version string in a repository;
• the vulnerability class (CWE);
• a CVSS v3.1 and v4.0 base score, each with its full vector and a per-metric justification. Scores are computed with the FIRST reference implementation, never estimated;
• how we verified it — LAB or STATIC — stated per finding;
• what we could not establish, and what would establish it;
• remediation advice that is specific enough to act on.

What we deliberately withhold from the first letter: working proof-of-concept code, reproduction harnesses, and any recovered secret or key material. Where a finding concerns a key or credential, we send a cryptographic fingerprint — enough for you to confirm we mean the same artifact, not enough to reproduce the exposure. We will share the rest over an encrypted channel once you name a technical contact.

---

3. The timeline

Day 0 is the date of our first email to you. Everything else is relative to it.

We publish earlier than Day 90 only if the vulnerability is already being exploited in the wild, or if it is published by someone else first. In either case we will tell you before we do it.

We publish later than Day 90 whenever a fix is genuinely in flight and you are keeping us informed. A deadline exists to prevent a report being ignored, not to punish an organisation that is doing the work.

If you never respond, we still publish at the deadline — but the advisory will say plainly that we tried, when, and to which addresses.

---

4. CVE identifiers

We request identifiers before we write to you where the finding is CVE-eligible, and the advisory states plainly whether that has happened yet. If nothing has been requested at the moment you read it, the advisory says so in those words rather than leaving a tense to imply otherwise.

Where the vendor is itself a CVE Numbering Authority, the identifiers are the vendor's to assign. We ask the vendor to assign them and do not approach another CNA while coordination is live.

This sometimes surprises people, so here is the reasoning. A reserved CVE places a timestamped record of the research with a neutral third party rather than with either of us. It protects your position as much as ours: if a second party reports the same defect, or if the finding surfaces publicly from another direction, there is an independent record of what was known and when.

A RESERVED identifier publishes nothing and discloses nothing. Its record text is not fixed. At Day 30 you get the draft text for every finding and we file your corrections. Nothing publishes before the coordinated date.

Where a defect is remediated by the operator of a single service rather than by a software update, we do not request a CVE — that is not what CVE identifiers are for, and filing one would waste a reviewer's time and cost us credibility on the findings that do belong there.

Where a defect turns out to be an incomplete fix for an existing CVE, we file it as incomplete remediation of that CVE, not as a new one.

---

5. What we ask of you

1. An acknowledgement within 14 days, naming a technical contact. It does not need to contain an assessment.
2. Tell us if we are wrong. We will correct it in writing, and the correction will be as prominent as the original claim. Our advisories routinely contain corrections against our own earlier conclusions; this is not a concession we make reluctantly.
3. Credit, if you publish. "Reported by MottaSec" is sufficient. We will not ask for more, and we will not publish your name in a way you have not seen first.

6. What we will not do

• We will not sell a finding to anyone, including you.
• We will not make remediation conditional on a payment, a contract, an engagement, or an NDA.
• We will not threaten publication to obtain any of the above.
• We will not publish your data. If a finding exposed personal data, we will tell you what class of data and where, and we will not retain it.

If you offer us payment for silence, we will decline and the timeline will not change.

---

7. If you are a researcher looking at our systems

Same rules, pointed the other way. Write to us at the address below. Test only against *.mottasec.com hosts that we operate, take no action that degrades service, and do not access data belonging to our clients. We will acknowledge within 5 working days, keep you informed, and credit you publicly unless you ask us not to. We do not operate a paid bounty and we will say so up front rather than leaving it ambiguous.

If what you have is sensitive, do not put it in a first email. Write to us saying only that you have something and roughly what it concerns. We will reply with an encrypted channel for you to send it into — see the contact table below. You will not need an account, a key, or any software.

We will not pursue legal action against a researcher who follows this policy, and we will say so in writing if you ask.

---

8. Contact

Mail to the security contact is read by a person. If you are reporting something time-critical and have had no reply within one working day, call.

---

Changes to this policy

---

This policy is published so that the organisations we write to can hold us to it. If we have not followed it, tell us.