Vulnerabilities incorrectly reverted to Submitted state

Update timeline

1. identified Jul 11, 2025, 01:53 AM UTC

   Vulnerabilities that were previously reported are being mistakenly shown as "Submitted", disrupting their expected workflow.

2. resolved Jul 11, 2025, 07:40 PM UTC

   The incident has been resolved, and vulnerabilities now display their correct status.

3. postmortem Jul 14, 2025, 12:47 PM UTC

   **Impact** Three groups experienced inconsistencies in vulnerability statuses and reporting. The issue started on UTC-5 25-07-08 19:40 and was proactively discovered 14.8 hours \(TTD\) later by a staff member, who reported through our help desk [\[1\]](https://help.fluidattacks.com/agent/fluid4ttacks/fluid-attacks/tickets/details/944043000040982204) that some vulnerabilities that should have been marked as `Vulnerable` were not being reported to clients because their status had incorrectly changed to `Submitted.` This incident affected only the metadata of the vulnerabilities and the metrics of related findings, both at the database level, in API responses, and in how the information was displayed on the platform. The problem was resolved in 2.2 days \(TTF\), resulting in a total window of exposure of 2.9 days \(WOE\) [\[2\]](https://gitlab.com/fluidattacks/universe/-/issues/16826). **Cause** The issue surfaced after a migration was executed [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/80792). However, complications had already been introduced earlier with the implementation of a new table in DynamoDB to store issue history [\[4\]](https://gitlab.com/fluidattacks/universe/-/issues/9579). To temporarily address data linkage issues, multiple sources were used to populate vulnerability history. The historical data was migrated to the destination table [\[5\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/56327), but due to ongoing inconsistencies, data was being saved in two places. This dual-source approach led to conflicting information and caused some vulnerabilities to display the incorrect statuses. **Solution** A corrective migration was developed and executed to locate and fix the affected records, restoring the appropriate status for the vulnerabilities [\[6\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/80848). **Conclusion** We are moving forward with the implementation of a single, unified data source for vulnerability history. This will reduce complexity, eliminate inconsistencies, and improve the reliability of status reporting across the system. **FAILED\_MIGRATION < DATA\_QUALITY < INCOMPLETE\_PERSPECTIVE**