Changelog

What’s Changing

We're expanding Ecoscanner with new automated security checks for Marketplace Forge apps to ensure compliance with our Security Requirements for Cloud Apps. These checks will be released periodically before December 31, 2026.

The new checks include:

• Arbitrary code execution: Detects untrusted input reaching dynamic code execution (e.g., eval) in Forge functions (Requirement 8, Critical Severity).

• End-of-life Node.js runtimes: Flags apps using Node.js runtimes that have reached end-of-life (Requirement 10, Critical Severity).

• Atlassian API token usage: Detects apps authenticating to Atlassian APIs using user API tokens instead of app-based authentication (Requirement 11, Critical Severity).

• Secrets in logs: Detects sensitive data (e.g., credentials) written to application logs via console.log or similar (Requirement 5, High Severity).

• SQL injection: Detects user input interpolated directly into Forge SQL queries instead of using query parameters (Requirement 8, High Severity).

• TLS and HSTS on Forge remotes: Verifies that remote backends accept only TLS 1.2+ and return an HSTS header with a max-age of at least one year (Requirement 3, Medium Severity).

What You Need to Do

As these scanners go live, findings will be reported to you via AMS tickets in ecosystem.atlassian.net.

To account for the holiday period, we are providing an additional 30 days beyond the standard Security Bug Fix Policy for findings from High or Medium severity checks during this initial launch. Standard resolution timeframes will apply to all findings starting January 1, 2027.

More details on how these checks work will be included in the Ecoscanner documentation as they are released. If you have questions, please contact Developer Support.

We are sunsetting SSH access via bitbucket.org in favor of ssh.bitbucket.org. This is an important change to improve Bitbucket’s security posture and safeguard our customers from denial of service abuse. We have originally announced this change on May 12, 2026 in Changelog announcement. We will be running a series of brownouts to help teams identify and mitigate any remaining usage of the old hostname.

For the brownout schedule and additional details refer to community blogpost.

During each brownout window, we will:

• Temporarily block SSH traffic on bitbucket.org

• Show clear error messages

• Show in-product messaging to create awareness

Following the previous deprecation announcement, we will begin scheduled brownouts of the Bitbucket Cloud Code Search API on 3 November 2026 at 00:00 UTC.

Brownouts are temporary periods when the API is unavailable, intended to help you identify integrations that still need to migrate. The brownout duration will progressively increase before the API becomes permanently unavailable on 15 November 2026 at 00:00 UTC.

Migrate your integrations to the workspace code search API before the brownouts begin.

Registering the new bitbucket:deploymentCheck module. You can use this module to build custom deployment checks for Bitbucket Cloud. The motivation for this change is laid out here, with the aim to create a centralised checks platform. Some more details on future strategy and vision is mentioned in this doc.

What's changing

On Nov 30, 2026 Git requests authenticated using OAuth2.0 via the Git Credential Manager (GCM) will be blocked for versions prior to 3.0.0. This is caused by the lack of support for rotating OAuth refresh tokens, which have recently begun being enforced for Bitbucket’s OAuth 2.0 implementation. See: https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3052. Atlassian contributed changes to the open source project to include support for the rotating refresh token model, which was bundled in the v3.0.0 release (https://github.com/git-ecosystem/git-credential-manager/releases/tag/v3.0.1)

What you need to do

🛠️ Scheduled maintenance window from September 25 @ 5PM PST to Monday, September 28 @ 10AM, AEST

Our support portal is moving to a new home. New ticket submissions and ticket access including comments via email will be unavailable during this window. Starting September 28, submit all requests at Atlassian Support and update your bookmarks. Learn what's changing.

What's changing

Branch restrictions now support adding the following to Write Access and Merge Access branch permissions in your branch restriction rules:

• Repository access tokens (RAT)

• Project access tokens (PAT)

• Workspace access tokens (WAT)

• Forge apps

• Rovo Dev

This applies to both repository and project-level branch restrictions.

What you need to do

No action is required. To use this feature, navigate to Repository settings → Branch restrictions or Project settings → Branch restrictions and add your access tokens, Forge apps or Rovo Dev to the desired permission rules.

For more information see our community post.

Bitbucket pull request (PR) update events for Forge apps now feature an additional changes field in their payloads. This field is present when a PR is updated due to a new commit being pushed to the source branch.

This update allows Forge apps to distinguish between code-level updates (new commits) and metadata updates (such as changes to the title or description). This is a backward-compatible change; no existing fields have been removed or renamed.

What you need to do

For most apps, no action is required. If your app is already listening to Bitbucket PR update events, the additional field will automatically be available in the event payload.

However, if you validate event payloads with a strict schema, ensure your validator is updated to allow the new changes property. You can review the updated payload structures in the Bitbucket pull request updated event reference documentation.

This deprecation was originally announced in 2022, and we are proceeding with the removal of the merge parameter now. More information including about alternative solutions for merge conflict retrieval can be found in our community post about this change. This capability will be removed as of September 4th, 2026.

As was announced in our Community blog deprecation of native Bitbucket Cloud Issues and Wikis, and API change log the API endpoints that support Issue Tracker are now fully removed.

Bitbucket has added support for bearer authentication for API tokens.

What’s changing:
Bitbucket Cloud has added support for Bearer authentication when using API tokens. You can now authenticate your API requests by sending the token in a Bearer authorization header, providing a more standard and secure alternative to Basic authentication.

What you need to do:
No action is required. Bitbucket Cloud continues to support both Basic and Bearer authentication for API tokens. If you have existing integrations using Basic authentication, they will continue to work without modification.

For more information on creating and using tokens, see the API tokens documentation.

Additional fields available in Bitbucket Forge events. This change is backward-compatible; no existing fields are removed or renamed.

What’s changing:

Bitbucket Forge events now include additional fields in their payloads. This update allows Forge apps to access more comprehensive data directly from the event, reducing the need to make separate API calls back to Bitbucket to fetch missing details.

The following event types are updated with additional fields:

• Repository created events

• Repository push events

• Build status events

• Pull request events

What you need to do:

No action is required. If your app is already listening to these Bitbucket Forge events, the additional fields will automatically be available in the event payload. If you validate event payloads with a strict schema, ensure your validator allows additional properties.

You can review the updated payload structures in the Bitbucket events reference documentation.

Bitbucket Forge page modules will now have their menu items grouped into sections by their app. This change improves the organization of the Bitbucket navigation menu, making it easier for users to identify which menu items belong to specific apps.

What’s changing:

The following modules will now have their menu items grouped by app:

• bitbucket:workspaceGlobalPage

• bitbucket:workspaceSettingsMenuPage

• bitbucket:workspacePersonalSettingsPage

• bitbucket:repoMainMenuPage

• bitbucket:repoSettingsMenuPage

• bitbucket:projectSettingsMenuPage

What you need to do:

No action is required from you. If your app uses these modules, their menu items will automatically be grouped. You can see the linked documentation pages for example screenshots of the new grouping behaviour.

As part of end of support for Connect app, we will be deprecating application property APIs.

When we reach Connect EOL, the following endpoints will be removed:

1. GET /repositories/{workspace}/{repo_slug}/commit/{commit}/properties/{app_key}/{property_name}

2. PUT /repositories/{workspace}/{repo_slug}/commit/{commit}/properties/{app_key}/{property_name}

3. DEL /repositories/{workspace}/{repo_slug}/commit/{commit}/properties/{app_key}/{property_name}

4. GET /repositories/{workspace}/{repo_slug}/properties/{app_key}/{property_name}

5. PUT /repositories/{workspace}/{repo_slug}/properties/{app_key}/{property_name}

6. DEL /repositories/{workspace}/{repo_slug}/properties/{app_key}/{property_name}

7. GET /repositories/{workspace}/{repo_slug}/pullrequests/{pullrequest_id}/properties/{app_key}/{property_name}

8. PUT /repositories/{workspace}/{repo_slug}/pullrequests/{pullrequest_id}/properties/{app_key}/{property_name}

9. DEL /repositories/{workspace}/{repo_slug}/pullrequests/{pullrequest_id}/properties/{app_key}/{property_name}

10. GET /users/{selected_user}/properties/{app_key}/{property_name}

11. PUT /users/{selected_user}/properties/{app_key}/{property_name}

12. DEL /users/{selected_user}/properties/{app_key}/{property_name}

We've introduced a structured process for partners and Atlassian to jointly investigate security incidents affecting your app or the customer data it handles.

What's changing

• Log sharing for Forge apps: Atlassian can now share incident-scoped platform logs and app telemetry with you during an investigation. This provides the data you need to diagnose and resolve issues faster.

• A single reporting path: You can now report security incidents through the new developer support portal form. This form serves as the shared record for both you and Atlassian.

What you need to do

• Review the program overview page to understand eligibility and support levels.

• Ensure your security contact information is up to date in the partner account to ensure you are ready before an incident occurs.