From 7c77870d1bd2e0b446f2dc69845adb0c212d0794 Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 30 Jul 2026 00:31:32 +0300 Subject: [PATCH] docs(security): exclude further instances of a root cause the same reporter already reported Exclusion 10 covers instances of a class we are actively remediating, and is worded around in-progress work: an open pull request, a public branch, a not-yet-released fix. It does not fit the case where a remediation is finished and shipped and the same reporter returns with more instances of the same root cause. Adds exclusion 12 for that case: another instance of a root cause the reporter previously reported, reached through a different parameter, endpoint or event, is awarded once under the original submission. Deliberately scoped to the reporter's own earlier report. A rule that let us decline anyone pointing out that one of our fixes was incomplete would suppress exactly the reports worth having, so independent discovery of the same class by a different researcher stays in scope and is assessed on its own merits, and genuinely distinct root causes remain separate reports. The wording also states that it applies whether or not remediation had finished, which is the gap in 10. Co-Authored-By: Claude --- SECURITY.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/SECURITY.md b/SECURITY.md index be2163365cc..18a862a63ef 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -38,3 +38,5 @@ The following are out of scope. They may still be reported, and configuration is 10. **Instances of a vulnerability class already under active remediation.** Findings that are additional instances of a vulnerability class we are already remediating — including work visible in an open or in-progress pull request, a public branch, or another not-yet-released fix — are considered part of that known, ongoing effort and are not separately eligible. Enumerating sibling occurrences of an issue from our published or in-progress remediation is not an independent discovery. Independently discovered issues remain welcome. 11. **Cross-site scripting (XSS) without a working proof of concept.** XSS reports that do not demonstrate actual script execution in an authenticated dashboard session are out of scope. Pointing at a potential sink (for example a `v-html` binding or a DOM write) is not sufficient on its own, since the value reaching a sink may already be neutralized elsewhere in the request handling or rendering pipeline. XSS with a working end-to-end proof of concept — including DOM-based XSS that originates from the URL or other client-controlled input — is in scope and welcome. + +12. **Further instances of a root cause you have already reported.** Where a report is another instance of a root cause you previously reported to us — the same defective function, check, or pattern, reached through a different parameter, endpoint, or event — it is treated as part of that original report and is awarded once, under the original submission. We expect a report to cover the instances its own analysis reaches: having identified a root cause, enumerating the remaining places it applies is part of that finding rather than a new one. This applies whether or not we had finished remediating the first report. Independent discovery of the same class by a different researcher is assessed on its own merits, and genuinely distinct root causes are always separate reports.