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 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).
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.
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].
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.