Platform access failure

Update timeline

1. identified Mar 30, 2026, 06:45 PM UTC

   Some users experienced issues when attempting to log into the platform resulting in blank pages and failed requests. As a temporary workaround, users can enter the platform in incognito mode or guest mode and allow all cookies (not just necessary ones).

2. monitoring Mar 30, 2026, 08:19 PM UTC

   A fix has been implemented and we are monitoring results for users.

3. resolved Mar 30, 2026, 08:58 PM UTC

   This incident has been restored and access to all users is back to normal.

4. postmortem Mar 30, 2026, 11:50 PM UTC

   ### Impact At least one user experienced a complete inability to access the application, resulting in a blank white screen upon interaction with the privacy settings. The issue started on UTC-5 26-03-30 13:44 and was reactively discovered 1 minute \(TTD\) later by one of our monitoring tools. An hour later, a staff member reproduced the problem: when users visited [app.fluidattacks.com](http://app.fluidattacks.com) and selected the "Use necessary cookies only" option on the banner, the page stayed blank and users were effectively locked out of the platform while choosing to "Allow all cookies" permitted normal operation. The problem was resolved in 2.2 hours \(TTF\), resulting in a total window of exposure of 2.2 hours \(WOE\). ### Cause The disruption was caused by an automated security feature within our third-party cookie management service, Cookiebot. This service uses an "auto-blocking" mode designed to prevent tracking scripts from running until a user provides consent. During a routine automated scan, the service misidentified our primary application code—the "engine" that runs the interface—as a marketing-related tracking tool. Consequently, when a user declined marketing cookies, the third-party service intercepted our application's main script and changed its instructions so the browser would ignore it. This prevented the application from starting, leaving the user with an empty page. This classification error occurred within the third-party's logic due to outdated or incorrect scan data and was not triggered by any internal changes to our code. ### Solution The immediate issue was temporarily resolved by manually triggering a fresh scan of our web address within the Cookiebot management dashboard. This forced the service to re-evaluate our application scripts, correctly identifying the main bundle as essential rather than promotional. Minutes later, however, Another scan reclassified the main bundle as promotional. The problem was ultimately solved by moving away from the "automatic" blocking mode in favor of a "manual" configuration, where we explicitly tell the service exactly which scripts are for tracking and which are essential for the application to function [\[1\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/99348). ### Conclusion This incident highlights the risks of relying on automated third-party classification systems for critical application delivery. By moving toward a more fine grained and explicit configuration of our privacy layers, we will ensure that security and usability remain consistent regardless of a user's cookie preferences. Our systems are currently stable, and we remain dedicated to refining our external integrations to maintain the highest levels of availability.