Changelog

As recently announced in Raising the bar on Marketplace cloud app security: together we are updating the Marketplace Security Bug Fix Policy to shorten vulnerability remediation timelines for Marketplace cloud apps. These changes ensure a higher security standard across our ecosystem.

What’s changing
The remediation Service Level Objectives (SLOs) for Marketplace cloud apps are being shortened. The timelines for Data Center apps remain unchanged.

Updated Cloud App SLOs (Enforceable September 1, 2026):

• Critical: 10 days

• High: 4 weeks

• Medium: 12 weeks

• Low: 25 weeks

Data Center App SLOs (Unchanged):

• Critical: 12 weeks

• High: 12 weeks

• Medium: 12 weeks

• Low: 25 weeks

Additionally, we have published the Marketplace Security Enforcement Policy, a consolidated source of truth for marketplace security compliance expectations, including vulnerability management, OAuth compliance, partner verification, bug bounty participation, and incident response.

What you need to do

• Review the new timelines: Ensure your internal processes are updated to meet the new cloud app SLOs by September 1, 2026.

• Check your tickets: We have corrected an issue where some AMS Data Center tickets incorrectly showed cloud remediation dates. If you believe a ticket still has an incorrect date, please raise an ECOHELP ticket.

• Watch the policy page: The Marketplace Security Enforcement Policy is a living document, we recommend "watching" the page for future updates.

We are introducing rate limits for Forge Realtime to ensure the stability and reliability of the service for all apps.

What’s changing
Starting June 26, 2026, a rate limit of 50 requests per app installation per second will be enforced for Forge Realtime. For more information, see our rate limit documentation.

Based on our current telemetry, no existing Forge apps exceed this limit, so we do not expect any immediate impact on your app's performance. This change is a proactive measure to maintain service health.

What you need to do

• Review your app's use of the Realtime Events API and Bridge API Realtime method to ensure your request frequency remains within the new limit.

• If you anticipate needing a higher rate limit for a specific use case, please reach out via the developer support portal.

As Connect approaches end of support in December 2026, we are starting to roll out customer messaging in the admin experience to inform admins when an installed app runs on a soon to be unsupported platform, Connect. Following on from our previous announcement, this messaging will gradually rollout over the next week to be live in production for non-public apps only and is scoped to the admin experience, end users will not see any notices at this stage.

On Jun 2, 2026, we will enable customer messaging on Developer Canary tenants for public apps. This will include notices in admin facing experiences so enrolled partners can preview the exact messaging their customers will see and have the chance to adopt the new connectToForgeMigration module in their manifest before it goes live in production.

The Forge CLI now supports specifying a limit when starting a bulk-upgrade workflow.

This limit can also specified in non-interactive mode.

If the limit parameter is not specified, the CLI will prompt you for a limit as part of its interactive flow.

The Forge CLI will also now indicate when the number of eligible installations exceeds the number that can be performed in a single workflow.

Forge LLMs will move from EAP to Preview on Jun 1, 2026, making it available to all Forge developers as a billable capability.

To ensure a clean cutover, EAP access will be disabled on May 29, 2026 at 00:00 UTC. From Jun 1, 2026 , all Forge LLM usage will be billed.

We are also deprecating the following older model versions, which will not be included in Preview:

• claude-sonnet-4-20250514

• claude-opus-4-1-20250805

• claude-opus-4-5-20251101

What you need to do

• Review the Forge LLMs pricing to understand how credits and billing work.
• Ensure your apps are added to a developer space with active billing details to continue using Forge LLMs on June 1st.

For more information, see the Forge LLMs reference documentation.

We've introduced the Tile component for Forge UI Kit apps, now available in Preview. The Tile component is a rounded square container for displaying assets like emojis, or objects in a consistent, styled way.

The component supports various sizes (from 16px to 48px), customizable background colors using design tokens, optional borders, and adjustable internal padding for different asset types including third-party logos.

For implementation details and examples, see the Tile component documentation.

The Forge CLI downloads app templates from a CDN when running forge create. As part of our ongoing security and reliability improvements, this CDN URL is being deprecated and replaced with a new one.

What's changing:

• Old URL (deprecated): https://forge-templates.us-west-2.prod.public.atl-paas.net/

• New URL: https://forge-templates-bifrost.prod-east.frontend.public.atl-paas.net/assets/

When:

• Effective from @forge/cli@12.20.1: the CLI fetches templates from the new URL.

• End of support for old URL: 2026-11-26 (6-month deprecation period, per the Forge deprecation policy).

Who is affected:

• Developers running Forge CLI versions older than 12.20.1 that reference the legacy templates URL.

• Enterprise environments with firewall allow-lists that include the old CDN domain.

Action required:

• Update your Forge CLI to @forge/cli@12.20.1 or later: npm install -g @forge/cli@latest

• If you maintain a corporate firewall allow-list, add forge-templates-bifrost.prod-east.frontend.public.atl-paas.net to your permitted domains. You can safely remove forge-templates.us-west-2.prod.public.atl-paas.net after 2026-11-26. Refer to Use the Forge CLI on a corporate network for the full list of required outbound connections.

• No changes to app code or manifests are required.

More details: Use the Forge CLI on a corporate network

New UI Kit components for managing file upload are now in preview:

• File picker: allows the user to select files stored locally.

• File card: displays information about a file (including name, type, and size); this can be used to managed selected files and displaying upload progress.

See how to implement these in our example app.

A new RFC is ready for review at RFC-136

Previously we announced an issue where storage:app as a scope increase was not able to be managed by bulk upgrade. This issue has now been resolved, and storage:app support via bulk upgrade has been restored.

Previously, we announced an upcoming fix to how Forge SQL returns DATETIME column values when the time component is 00:00:00. We are now rolling out this update on Jun 5, 2026 instead of Oct 6, 2026

As this change relates to a bugfix in an underlying library dependency, deferring the update could expose the platform to security vulnerabilities. However, updating the library as scheduled means rolling out the DATETIME fix earlier than expected.

What's changing:

Previously, querying the value of a DATETIME column where the time component is set to 00:00:00 would result in only the date portion being returned. For example, the value '1970-01-01 00:00:00' would be returned as '1970-01-01'. After this update, the full value including the time component will be correctly returned ('1970-01-01 00:00:00').

This affects DATETIME column values that were set in the following ways:

1. The value was explicitly set with a time component of 00:00:00, or

2. The value was set with only the date component, in which case the time component defaults to 00:00:00.

What you should do:

If your Forge app reads DATETIME values from Forge SQL and parses the returned string, verify that your parsing logic handles the full YYYY-MM-DD HH:MM:SS format.

Why we're accelerating this:

Remaining on an outdated version of this library dependency has the potential to leave Forge SQL exposed to security vulnerabilities. We cannot responsibly defer a necessary security update to honour the original grace period. We apologise for the shortened notice and appreciate your understanding.

A new optional boolean parameter, generateAppEvents has been introduced to the following Jira Cloud REST API endpoints

• POST /rest/api/2/app/field/value - Update custom fields

• PUT /rest/api/2/app/field/{fieldIdOrKey}/value - Update custom field value

What it does: When set to false, this parameter suppresses the generation of app events triggered by the update. Specifically, it prevents issue updated events from being dispatched to:

• Forge app event listeners

• Connect app event listeners

• OAuth 2.0 app webhooks

• Admin-configured webhooks (registered via the Jira admin UI)

Default behavior: When omitted or set to true, all app events are generated as usual.

The jira:actionValidator module (Preview) now supports the workItemTypeChanged action across multiple flows, enabling custom validation whenever a user changes a work item's type. The validator is triggered in:

• Issue view - the user changes the work item type from the type field on the issue view.

• Move issue - when the work item type changes as part of moving an issue.

• Bulk move/migrate - the work item type changes as part of a bulk move or migration.

• Convert to subtask - when a standard work item is converted to a subtask type.

• Convert subtask to a work item - when a subtask is converted to a standard work item.

Also, a new context variable newIssueTypeData (type: IssueType) has been onboarded alongside the existing newIssueType (type: String, returns the issue type ID), allowing more refined conditions on the target work item type within your Jira expression.

Read more here - https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-action-validator/#workitemtypechanged

A filter to breakdown usage of function compute by compute type (sync or async) is now available in the Forge Developer Console’s Usage and Charges section.

• Sync: Synchronous function executions.

• Async: Asynchronous function executions.

This filter is available on the detailed Usage view of Functions - compute usage and the Site breakdown view.

No action is required. However, we recommend using this filter to understand your asynchronous compute consumption before billing for this compute type begins on July 1, 2026. For more context, see our previous announcement: CHANGE-3120

We’ve added an optional urlFormat field to the webtrigger module in manifest.yml so you can choose which URL format Forge uses for each web trigger. This field accepts two values:

• v1: uses the existing app-based URL format, and remains the default when urlFormat isn’t specified (for backwards compatibility).

• v2: uses a new installation-based URL format with an improved domain and path. Use v2 for new web triggers and when you want to opt in to the newer URL style.

Future web trigger capabilities will require urlFormat: v2, and at that point urlFormat will become a required field.