A repeat submission is a new report for a vulnerability that was previously fixed but later reappeared or was still present after supposed remediation. It is a sign that the security control or release process did not preserve the fix across the application lifecycle.
Expanded Definition
Repeat submission describes a vulnerability report that returns after an earlier fix, or was never fully removed despite a closure decision. In security operations, the key issue is not the original finding itself but the failure of remediation to persist across code merges, deployment pipelines, configuration changes, or environment drift. That makes repeat submission a lifecycle quality signal as much as a vulnerability-management outcome.
Definitions vary across vendors and bug bounty programs on whether a report is a repeat submission only when the exact root cause recurs, or also when the same observable weakness reappears in a different component. For governance purposes, NHI Management Group treats it as any re-report of a condition that should have been eliminated by the prior fix. That framing aligns with control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls, where change control, flaw remediation, and configuration integrity are inseparable.
The most common misapplication is labelling a genuinely new issue as a repeat submission, which occurs when triage teams rely on symptom matching instead of verifying whether the underlying weakness, affected asset, and remediation history are actually the same.
Examples and Use Cases
Implementing repeat-submission handling rigorously often introduces triage overhead, requiring organisations to balance faster closure against the cost of deeper root-cause validation.
- A SQL injection path is patched in one endpoint, but a parallel endpoint in the same service remains vulnerable after release, leading to a repeat submission when the issue is rediscovered.
- An authentication bypass is fixed in staging, yet a later deployment overwrites the patched configuration in production, so the same weakness is reported again after go-live.
- A secrets exposure in a repository is remediated by removing the file, but the same token is reintroduced through a build artifact, causing the vulnerability to reappear in a subsequent scan.
- A buffer overflow is marked resolved after a code change, but the fix was applied only to one branch and never propagated to the long-term support branch, so the issue returns in a later audit.
- A cloud storage misconfiguration is corrected once, then reintroduced by infrastructure-as-code drift, which makes the second report a repeat submission even though the business context has changed.
For teams building repeatable validation processes, the reporting and resubmission workflow should be paired with evidence of fix verification, regression testing, and release gating. The NIST control set is useful here because it treats change oversight and remediation tracking as part of security operations, not an afterthought.
Why It Matters for Security Teams
Repeat submissions are a governance warning that remediation is not durable. If the same vulnerability can reappear, security teams may have a patching process, but not a control assurance process. That weakens vulnerability metrics, distorts severity reporting, and makes it harder to tell whether engineering teams are fixing root causes or merely closing tickets. It can also erode trust with researchers, bug bounty participants, and internal red teams when the same issue keeps resurfacing under different labels.
For identity and agentic AI environments, the implication is sharper. If a repeated issue affects access controls, token handling, service identities, or an agent’s tool permissions, the organisation may be repeatedly exposing privileged paths even after believing the defect was eliminated. In NHI-heavy systems, that can mean the same secret, credential, or delegation flaw reappears across deployments because the fix was not applied to every identity instance.
Organisations typically encounter the real cost only after a “fixed” issue shows up again in production or in a fresh assessment, at which point repeat submission handling becomes operationally unavoidable to resolve.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.MI, PR.IP | Repeat submissions expose weaknesses in remediation execution and maintenance of protections. |
| NIST SP 800-53 Rev 5 | CM-3, SI-2 | Change control and flaw remediation controls address fixes that fail to persist. |
| NIST SP 800-63 | Identity systems depend on durable credential and authenticator handling across lifecycle changes. | |
| OWASP Non-Human Identity Top 10 | Repeated identity or secret handling flaws are common when NHI controls are not propagated. | |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes controls must hold across change, not only at initial remediation. |
Treat repeats as evidence to strengthen remediation tracking, change control, and regression validation.
