Is Fluid Attacks down?

Users may experience an unexpected error when accessing the Evidence page. The application fails to load due to a null reference issue while processing evidence data. Our team is investigating and working on a fix.

The issue has been identified and a fix is being implemented.

A fix has been implemented and we are monitoring the results.

The issue causing the Evidence page to crash has been identified and resolved. The page is now loading correctly for all users. We apologize for the disruption and appreciate your patience while we worked through it.

## Impact All users on the platform experienced the inability to view or upload evidence on finding pages for approximately 58 minutes. Both the web interface and the desktop application were affected. Users without access to certain findings were additionally stuck in a reload loop during the same window. The issue started on UTC-5 26-05-26 14:35 and was proactively discovered 57.6 minutes \(TTD\) later by a staff member who noticed that evidence data was not loading and alerted the team. The problem was resolved in 57.6 minutes \(TTF\), resulting in a total window of exposure of 1.9 hours \(WOE\). ## Cause A planned dependency upgrade deployed to remediate reported security vulnerabilities introduced an undocumented behavioral change in a core library responsible for mapping GraphQL field names to their internal data keys. Under the previous version, fields whose names were entirely lowercase were left unchanged during this mapping. Under the upgraded version, all fields, regardless of casing were passed through a name converter that inserts underscores before numeric characters. As a result, fields such as those used to store evidence items were silently redirected to keys that did not exist in the underlying data, causing them to return empty values instead of their content. The behavioral change was documented in the library's internal pull request history but was not prominently surfaced in the official changelog, and the existing test suite did not cover the full name-resolution flow against a live schema. ## Solution An emergency rollback to the previous dependency versions was deployed the same day, restoring all affected functionality within the incident window. A definitive fix was subsequently developed and deployed two days later: the dependency upgrade was re-applied alongside a custom name-mapping configuration that preserves the correct resolution behavior for all-lowercase field names while still applying the standard conversion to mixed-case names. Automated tests were added to explicitly validate that all numbered evidence fields resolve to their expected values, preventing silent regressions of this class in future dependency upgrades. ## Conclusion Major-version upgrades to core GraphQL infrastructure libraries must be accompanied by integration tests that exercise the full field-name resolution pipeline against a real executable schema not only unit tests of business logic. The failure was silent by design: fields returned empty values without raising errors, making it indistinguishable from missing data until users reported it. Future upgrades to schema-handling libraries require an explicit end-to-end assertion that no field resolves to null when data is present. **THIRD\_PARTY\_CHANGE < MISSING\_TEST < INCOMPLETE\_PERSPECTIVE**

An issue was found in DOCS. Click for details: https://availability.fluidattacks.com

We are continuing to work on a fix for this issue.

This incident has been resolved.

## Impact On May 20, 2026, users visiting [docs.fluidattacks.com](http://docs.fluidattacks.com/) may have encountered a "Server failed to respond" error for approximately 1.3 hours. The issue was detected internally by our team and resolved within the same window. ## What happened During a routine deployment operation, an outdated version of the documentation service was accidentally restored to production. This older version was missing a configuration component required for the service to start up correctly, which caused the site to become unavailable. Think of it like accidentally restoring an old backup that was missing a key setting the service came back up in an incomplete state and was unable to respond to requests. ## What we changed Service was restored by redeploying the latest stable version of the documentation site, bringing `docs.fluidattacks.com` back online. We then applied a permanent fix to ensure the required configuration is always present and correctly loaded when the service starts, preventing the same failure mode from recurring. ## Going forward We have updated our deployment process to prevent outdated versions from being restored to production. Safeguards are now in place to ensure that only verified, fully configured versions of the service can be deployed. **COMMUNICATION\_FAILURE < INCOMPLETE\_PERSPECTIVE.**

An issue was found in DOCS. Click for details: https://availability.fluidattacks.com

This incident has been resolved.

# Postmortem ## Impact On May 19, 2026, users visiting docs.fluidattacks.com may have encountered a "Server failed to respond" error for approximately 2.6 hours. The issue was detected internally by our team and resolved within the same window. ## What happened During a routine deployment operation, an outdated version of the documentation service was accidentally restored to production. This older version was missing a configuration component required for the service to start up correctly, which caused the site to become unavailable. Think of it like accidentally restoring an old backup that was missing a key setting the service came back up in an incomplete state and was unable to respond to requests. ## What we changed Service was restored by redeploying the latest stable version of the documentation site, bringing `docs.fluidattacks.com` back online. We then applied a permanent fix to ensure the required configuration is always present and correctly loaded when the service starts, preventing the same failure mode from recurring. ## Going forward We have updated our deployment process to prevent outdated versions from being restored to production. Safeguards are now in place to ensure that only verified, fully configured versions of the service can be deployed. **COMMUNICATION\_FAILURE < INCOMPLETE\_PERSPECTIVE.**

An issue was found in DOCS. Click for details: https://availability.fluidattacks.com

This incident has been resolved.

#### Postmortem ##### Impact On May 15, 2026, some users visiting `docs.fluidattacks.com` encountered errors for approximately 15 minutes during a planned security update. Our team detected the issue and had it fully resolved within the same day. ##### What happened We were rolling out a security improvement to the site when two parts of the update ran out of order. One piece finished before another critical piece was ready, leaving the site in an inconsistent state for a short window. Think of it like changing the locks on a door before the new keys have arrived the door ends up neither fully open nor properly secured. Once we identified the root cause, we pushed a corrected version of the update that ensures both pieces always complete in the right order before anything becomes visible to users. ##### What we changed We updated the deployment process so that user-facing parts of the site can only go live after the underlying security layer has been fully confirmed. A failed step now stops the whole update cleanly, with no partial changes reaching the site. ##### Going forward We are applying this same safeguard to all similar updates across our infrastructure to prevent this from happening again. **MISSING\_TEST < INCOMPLETE\_PERSPECTIVE**

An unintended feature update to the SCA pipeline caused a set of Go runtime advisories to appear in client SARIF reports via prebuilt SBOM outputs. The change was identified proactively by our team and fully reverted. Affected clients can disregard any unexpected Go-related findings received during this period, as they do not reflect actual vulnerabilities in their systems.

### Postmortem #### Impact Some users received unexpected vulnerability findings in their SCA \(Software Composition Analysis\) reports related to Go runtime dependencies. The issue began on May 8, 2025 at 14:02 \(UTC-5\) and was identified proactively by our team 5.3 hours later through routine monitoring. The change was fully reverted in 3.8 minutes \(TTF\), resulting in a total window of exposure of 5.3 hours \(WOE\). No customer data was lost or compromised. The findings were informational in nature and did not reflect actual vulnerabilities in client systems. A total of 19 groups across 12 organizations were exposed to 154 spurious advisories in their reports. #### Cause A feature update to the SCA pipeline, adding detection of Go runtime and toolchain versions from dependency files was released to production before completing the required internal review process. This caused a set of Go standard library advisories to be included in client SARIF reports via prebuilt SBOM outputs. The release process lacked an explicit gate to enforce sign-off before deployment. #### Solution The feature was fully reverted. Go runtime and toolchain package detection was removed, and the 154 affected advisories were suppressed from all client reports. Clients who received these findings can disregard them, they do not reflect real vulnerabilities in their systems. #### Conclusion This incident reinforces that any feature affecting client-visible vulnerability reports must receive documented product team approval as a mandatory gate before merging to production. Going forward, this sign-off will be required and recorded in the corresponding issue prior to any deployment to the SCA pipeline. **COMMUNICATION\_FAILURE < INCOMPLETE\_PERSPECTIVE**