[RETROACTIVE SEV2] - All Web Capture App impacted by "Session Expired" errors during capture links

Update timeline

1. investigating Feb 25, 2026, 05:06 PM UTC

   Between approximately 10:30 AM and 11:26 AM EST on February 25th, all users of the Web Capture App were likely impacted by “session expired” errors when accessing existing capture links. The issue has been fully resolved, and existing capture application links and new links are now functioning as expected. This only affected Web Capture App and not our native IOS/Android SDKs.

2. investigating Feb 25, 2026, 05:07 PM UTC

   We are continuing to investigate this issue.

3. resolved Feb 25, 2026, 05:08 PM UTC

   This incident has been resolved.

4. postmortem Mar 02, 2026, 05:19 PM UTC

   **Root Cause Analysis:** **Incident: DocV Capture App Production Environment Mismatch \(DR Build\)** **Date Range:** February 25, 2026 **Impact: 35% error rate; Production Capture App served DR endpoints, causing "Session Expired" errors due to CSP blocks.** **Summary:** On February 25, 2026, between 10:34 AM EST and 12:26 PM EST, the DocV Capture App experienced a service degradation where **35% of sessions failed.** The incident was triggered when a build intended for a Disaster Recovery \(DR\) test was uploaded to a DR S3 bucket. An undocumented replication rule automatically propagated this DR configuration into the Production S3 bucket. Consequently, the production application attempted to communicate with DR endpoints, which were blocked by the Production Content Security Policy \(CSP\), resulting in "Session Expired" errors for end users. **Timeline:** | **Date / Time \(ET\)** | **Event** | | --- | --- | | 09:58 AM | DR-specific build published to DR S3 bucket \(PLT-6791\). | | **10:34 AM** | **Start of Incident:** Manual update of `index.html` in DR bucket triggers replication to Production bucket. | | 11:06 AM | BrowserStack automated tests fail \(results posted to a private Slack channel; no alert triggered\). | | **11:26 AM** | **Deployed Capture App fix**. Fixes issues for over 99% customers. | | 12:56 PM | **Complete Restoration confirmed by all impacted customers** | **3. Root Cause** * **Primary Root Cause:** An active, undocumented S3 replication rule existed between the DR bucket and the Production bucket. This caused non-production artifacts to overwrite production files automatically. * **Contributing Factors:** * **Security Policy Enforcement:** As a security best practice, the Capture App utilizes a **Content Security Policy \(CSP\)**. Because the production application was served with DR instructions, the CSP correctly identified a mismatch and blocked the connection attempts. While this prevented data from being sent to the wrong environment, it resulted in the "Session Expired" error experienced by users. * **Non-contributing Factors:** * **Core Application Logic:** The underlying source code for the Capture App was verified as stable; the issue was strictly isolated to build replication to the production environment. * **Backend Services:** All Socure backend APIs remained healthy and operational throughout the incident; the disruption was limited to the front-end to backend api call. **4. Resolution** The resolution involved disabling the automatic replication rule and redeploying the verified build to the production environment. Subsequently, a global invalidation of CloudFront caches was performed to ensure all edge locations were updated. **5. Corrective and Preventive Actions** | **Action** | **Description** | **ETA / Status** | | --- | --- | --- | | Disable Replication | Review and remove unauthorized S3 replication rules between DR and Prod. | **Done** | | Monitoring | Implement Application Performance Monitoring \(APM\) spike monitors for `source:csp-report` logs to detect any bad CSP changes immediately. Add alerts for "Session Expired" error spikes in our monitoring platform and application level Increase the frequency of our synthetic automated tests and add new Alerts on tests failures | March 13, 2026 | | Infra Cleanup | Conduct a comprehensive audit of all S3 bucket policies and cross-region replication rules Add guardrail to our DR environment deployments and refine our rollback procedures to ensure more rapid service restoration. | March 27, 2026 | **6. Lessons Learned** * **Infrastructure Awareness:** Cross-bucket dependencies must be known. * **Proactive vs. Reactive:** Internal synthetic testing \(BrowserStack\) caught the issue, but it was not run immediately after the release, and those automation failures did not automatically create an incident page for the on-call team. * **Inventory Management:** We will refine our rollback procedures to ensure more rapid service restoration. **7. Next Steps & Ongoing Commitment** Socure takes full accountability for this configuration error. To prevent recurrence, we are conducting a comprehensive audit of all S3 bucket policies and cross-region replication rules. Furthermore, we are integrating CSP violation telemetry into our core alerting suite to ensure that any environment mismatch is identified and remediated before it impacts the customer experience.