Is Fluid Attacks down?

Since October 29 at 18:57 GMT-05:00, repositories connected through Bitbucket OAuth credentials cannot be cloned, and their cloning status shows “Invalid credentials, access could not be granted prior to the cloning task”. Adding or re-authorizing Bitbucket OAuth credentials from the Credentials section of the organization also fails, with the Bitbucket error “Invalid client_id”. Repositories that use HTTPS or SSH credentials, or other providers (GitHub, GitLab, Azure DevOps), are not affected, and no data was lost or exposed. Our team is working on a fix.

We are continuing to work on a fix for this issue

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

This incident has been resolved.

#### Impact Some users were unable to clone repositories connected to Bitbucket through OAuth, and could not connect or reconnect Bitbucket through OAuth. The issue started on UTC-5 26-10-29 18:57 and was reactively discovered 2.9 days \(TTD\) later by a staff member who reported, on behalf of a client, that one of its groups had lost access to its Bitbucket repositories. The problem was resolved in 1 day \(TTF\), resulting in a total window of exposure of 3.9 days \(WOE\). * **Cloning**: repositories connected through Bitbucket OAuth were marked as failed, so they did not receive new code for analysis, and their pending reattack requests were put on hold. * **Connections**: users who tried to add or reconnect a Bitbucket OAuth credential received an error from Bitbucket instead of the authorization screen. New connections had probably been failing since October 22. * **Scope**: signing in with Bitbucket, repositories from other providers, and Bitbucket repositories connected with other credential types kept working normally. #### Cause Our platform accesses Bitbucket repositories through an OAuth app, which must be associated with a Bitbucket account. The account that held this app became inactive, and as a result Bitbucket disabled the app and the access it had granted. This change occurred on Bitbucket’s side, with no changes to our platform. Our platform interpreted the resulting errors as a temporary Bitbucket issue, and we did not have an alert for failures affecting all Bitbucket connections at once, so the problem was not detected until it was reported. #### Solution We registered a new Bitbucket OAuth app under a company-managed account, with the same read-only access as before, and switched the platform to use it[.](https://gitlab.com/fluidattacks/universe/-/merge_requests/121323) New Bitbucket OAuth connections now work as expected. Since access granted through the previous app cannot be transferred, affected credentials need to be reconnected from the organization’s Credentials section; our team is reaching out to each affected organization to help with this. We will also document a rotation procedure for this app, add an alert for widespread Bitbucket connection failures, improve how the platform handles this type of error, and use a separate app for our development environment. #### Conclusion This incident showed that a key integration depended on an account that was not centrally managed, and that our monitoring did not distinguish a widespread failure from a temporary provider issue. Managing integration apps under company accounts with documented ownership and rotation steps, and monitoring connection failures across all credentials, would have prevented this outage and allowed us to detect it sooner. **ROTATION\_FAILURE < INCOMPLETE\_PERSPECTIVE < MISSING\_ALERT**

Since 11:35 GMT-05:00, several AI-powered services on our platform are unavailable: the AI agent chat fails with "Failed to connect to chat service", connections to the Fluid Attacks MCP server (https://app.fluidattacks.com/mcp/messages/) from MCP clients such as Claude Desktop, Claude Code and other AI assistants fail with the error "Unexpected content type: text/html", and pull request reviews from the PR Assistant may not complete.

This incident has been resolved.

#### Impact Some users experienced an outage of the AI-powered services on our platform: the AI agent chat failed with "Failed to connect to chat service", sessions from external MCP clients could not start, and some pull request reviews from the PR Assistant did not finish processing. The issue started on UTC-5 26-10-26 11:35 and was reactively discovered 5.8 hours \(TTD\) later by a staff member who noticed that the AI agent had stopped responding. The problem was resolved in 1.2 hours \(TTF\), resulting in a total window of exposure of 7 hours \(WOE\). * **AI Agent**: users who opened the AI agent on the platform did not get an answer. * **MCP server**: connections from MCP clients such as Claude Desktop, Claude Code and IDEs failed with "Unexpected content type: text/html". * **PR Assistant**: some pull request review runs never finished processing. * **Scope**: the API, vulnerability management, reports and scans kept working normally, and no data was lost or exposed. #### Cause The services inside our infrastructure locate each other through an internal name resolution service. A change that enabled a new network security layer on some groups of servers modified how name resolution works on those servers[.](https://gitlab.com/fluidattacks/universe/-/merge_requests/118341) On those servers the internal name resolution service ended up forwarding requests to itself, detected the loop, and stopped. Nothing restricted this service to the servers where it works correctly, and since servers are replaced every day, one of its two instances landed on an affected server on October 19 and stopped working. The service kept running on a single instance for a week without any alert. On October 26, an unrelated infrastructure change automatically updated this service to a newer version[.](https://gitlab.com/fluidattacks/universe/-/merge_requests/119719) The restart moved the last healthy instance onto an affected server, leaving no instances available, so every AI service that depends on internal name resolution stopped responding. The new version itself was not the cause; both versions behave the same way on the affected servers. #### Solution The service was restored by restricting the internal name resolution service to servers without the new network layer, after which both instances started correctly. The permanent fix keeps this service on a dedicated group of base servers, the same placement already used by other core components, and raises that group to a minimum of two servers[.](https://gitlab.com/fluidattacks/universe/-/merge_requests/120043) A complementary change fixes the versions of the base components of our infrastructure, so updates are deliberate and reviewed instead of a side effect of unrelated changes[.](https://gitlab.com/fluidattacks/universe/-/merge_requests/120037) The team will also add an alert on the availability of this service. #### Conclusion This incident showed that the change to the network configuration of our servers was validated for the services it targeted but not for the base components of our infrastructure that could run on those servers, so the defect stayed hidden until the daily server rotation exposed it. Without an alert on the availability of name resolution and with component versions not fixed, a routine infrastructure update turned a silent degradation into an outage. Placing base components on dedicated servers, fixing their versions and monitoring their availability would have prevented any user from being affected. **INFRASTRUCTURE\_ERROR < MISSING\_ALERT < INCOMPLETE\_PERSPECTIVE**

An issue was found in PLATFORM. Click for details: https://availability.fluidattacks.tech

This incident has been resolved.

An issue was found in AGENT. Click for details: https://availability.fluidattacks.tech

This incident has been resolved.

An issue was found in API. Click for details: https://availability.fluidattacks.tech

This incident has been resolved.