This documentation is intended for Confluence developers who want to ensure that their existing plugins and apps are compatible with Confluence 11.0.

Watch this page to find out when a new milestone is available and what’s changed. We will publish formal release notes once we release a beta.

Latest milestones

Issues with this milestone?

Hit the Feedback button on the Confluence EAP header or raise an issue to tell us about it.

On this page:

Planned changes

In this section we'll provide an overview of the changes we intend to make, so you can start thinking how it might impact your app. We'll indicate when a change has been implemented, and in which milestone. 

AUI 11 Visual Refresh

Status: DONE

AUI 11 is coming with Jira 12, Confluence 11, Bitbucket 11, Bamboo 13, and Crowd 8. See Introducing AUI 11 (Jira 12, Confluence 11, Bitbucket 11, Bamboo 13, Crowd 8)

Asynchronous Macro Execution

Status: DONE

Confluence Data Center now supports asynchronous macro execution — a major performance capability that changes how macros are rendered on a page.

Previously, every macro on a Confluence page was executed sequentially on the same HTTP request thread. The browser couldn't receive the page until every last macro had finished — meaning a single slow macro (e.g. a Jira query or a blog-posts roll-up) could block an entire page load for all users.

With this release, macros can be configured to execute asynchronously and concurrently in a dedicated thread pool. The HTTP request thread is freed immediately, and macro results are assembled as they complete. For pages with multiple slow macros, this can dramatically reduce perceived load time.

Configuration required: Yes (opt-in per macro, admin setup)

Concurrent execution
Multiple macros on the same page can now execute in parallel rather than sequentially, significantly reducing total page render time.

Deduplication
If multiple users request the same page simultaneously, identical macro executions (same macro, same parameters, same content) can be deduplicated — one execution runs and its result is shared, avoiding redundant parallel work.

Configurable timeouts and rate limits
Administrators can set per-macro time limits and concurrency limits via the REST API, with global defaults configurable via JVM system properties. If a macro exceeds its time limit, Confluence can signal it to stop gracefully.

Result caching (opt-in)
Macro results can be cached per-user on each node, so repeat visits to the same page don't re-execute expensive macros. Cache TTL and size are configurable.

Execution cancellation
Administrators can cancel in-flight macro executions in real time — by execution ID, by macro name, or all at once — via REST API. Macro developers can implement graceful cancellation support.

Observability
Active macro executions are visible in real time, both via REST API and (on clustered setups) in the Confluence Clustering UI. A scheduled analytics job publishes execution statistics for monitoring.

Safe fallback
If the async thread pool is saturated (queue full or queue latency exceeded), macros fall back to synchronous execution automatically. No requests are dropped.

How to get started
This feature is disabled by default and requires administrator configuration:

1. Enable the dark feature atlassian.macros.async.execution in Confluence Dark Features

2. Use the REST API (PUT /rest/asyncmacros/latest/execution-controls) to configure which macros run asynchronously

3. Optionally tune thread pool and timeout settings via JVM system properties

See the full Administrator & Developer User Guide for step-by-step instructions.

Macro developer impact
Existing macros are not affected unless an administrator explicitly enables async execution for them via the REST API. Macro developers who want to support graceful cancellation should implement isCancellable() and handle InterruptedException / ExecutionCancellationContextThreadLocal.isCancelled(). To enable result caching, implement isCacheable().

Atlassian Keyboard Shortcuts Upgrade

Status: DONE

The com.atlassian.plugins.shortcuts:atlassian-shortcuts-plugin was upgraded from 6.0.2 to 6.1.7 in Confluence 11 to provide compatibility with the Content Security Policy.

While the new minor version is backward compatible, there’s an undocumented feature that may have been used in Marketplace apps for triggering editor operations in the <operation> tag which changes.

Code in Confluence 10 and older:

    <keyboard-shortcut key="tinymce.h1" i18n-name="admin.keyboard.shortcut.tinymce.h1" name="Heading 1">
        <description key="tinymce.advanced.h1"/>
        <shortcut>[Ctrl+1]</shortcut>
        <operation type="execute">FormatBlock-h1</operation>
        <context>tinymce.block</context>
    </keyboard-shortcut>

From Confluence 11, the <operation> requires explicit Javascript code:

    <keyboard-shortcut key="tinymce.h1" i18n-name="admin.keyboard.shortcut.tinymce.h1" name="Heading 1">
        <description key="tinymce.advanced.h1"/>
        <shortcut>[Ctrl+1]</shortcut>
        <operation type="execute">FormatBlock-h1</operation>
        <operation type="execute">require('tinymce').activeEditor.execCommand('FormatBlock-h1')</operation>
        <context>tinymce.block</context>
    </keyboard-shortcut>

More details about keyboard shortcuts module can be found in the documentation.

Complete removal of Bandana and XStream

Status: DONE

After making Bandana read-only in Confluence 10.0, we will remove Bandana entirely in Confluence 11.0. For security reasons, Confluence 11.0 will also no longer bundle the XStream library.

The following packages will be removed and will no longer be available to plugins:

• com.atlassian.bandana*
• com.atlassian.confluence.setup.bandana*
• com.atlassian.confluence.setup.xstream*
• com.thoughtworks.xstream*

Direct access to the Bandana database table will no longer be possible in Confluence 11.0.

Apps that currently use Bandana must migrate to alternative storage (for example, Active Objects or SAL Plugin Settings) before upgrading to 11.0.

For more information, go to Preparing for Confluence 10.0.

The Bandana table will be automatically dropped on a successful upgrade. To retain the data, consider backing up the table before upgrading.

Complete removal of OpenSymphony PropertySet

Status: DONE

The following APIs that leverage PropertySet were made read-only in Confluence 10.0. They have been permanently removed in Confluence 11.0.

• com.atlassian.confluence.user.ConfluenceUserPropertySetFactory

• com.atlassian.confluence.user.UserAccessor#getPropertySet

• com.atlassian.confluence.core.ConfluencePropertySetManager

Content Security Policy

Status: DONE

In Confluence 11, the content security policy (CSP) for the "script-src" directive has been introduced. The following adjustments apply (plugins must update their code to comply with these changes):

1. All direct and indirect uses of eval are blocked.
2. All inline scripts are blocked.
3. Scripts loaded from other domains must be allowed via the CSP script-src header.
4. Script tags with inline code must include a nonce attribute.
5. Keyboard shortcuts with operation type execute are no longer supported.

How is script-src CSP enabled

Confluence 11 enables this by default alongside existing policies. Only system administrators can disable this feature via the configuring of system properties:

http.header.security.content.security.policy.strictness.enabled

(e.g. -Dhttp.header.security.content.security.policy.strictness.enabled=false)

The CSP report-only mode is disabled when the property CSP is enabled (set to true).

There is also a system property http.header.security.content.security.scriptsrc.additional.urls that let admins to allow external scripts if they need.

Handling eval removal

Remove eval and eval-like operations from the codebase. They are harmful and have no safe alternative. Implement features without eval and block direct and indirect uses. Examples include:

1. Function constructor

2. Calls to setTimeout or setInterval with string arguments

3. Dynamically adding scripts using .html or .write

4. usages of underscore’s template method (_.template) will not work as it would throw an eval violation

Handling keyboard shortcut operations

Previously supported tinymce editor keyboard shortcut operations like <operation type="execute">FormatBlock-h1</operation> (inside a <keyboard-shortcut> block of the plugin descriptor) now need to be explicitly converted to a function call. Example:

<operation type="execute">require('tinymce').activeEditor.execCommand('FormatBlock-h1')</operation>

Handling inline scripts

1. Remove inline and add event handlers along with handling key events where applicable

2. Move code in script tags to separate js file or add nonce attribute to the script tag

   Adding nonce in VM files 

   <script type="text/javascript" nonce="$!request.getAttribute('cspNonceId')">

   Adding nonce in soy files

   // Get nonce value from request object
   public String getNonceId() {
           HttpServletRequest request = getActiveRequest();
           if (request != null) {
               Object nonceId = request.getAttribute("cspNonceId");
               return nonceId != null ? nonceId.toString() : "";
           }
           return "";
   }
   
   // Set the nonceId to the soy files data mapping
   .put("nonceId", getNonceId())
   
   
   // set the nonce value in the template
    <script type="text/javascript" {if $nonceId}nonce="{$nonceId}"{/if}>

3. For scripts using external urls, allow the domain in the CSP Header
   
   Add the following dependency in your pom file.

     <dependency>
               <groupId>com.atlassian.security</groupId>
               <artifactId>atlassian-secure-api</artifactId>
               <scope>provided</scope>
     </dependency>

   Create a CSP fragment in atlasian-plugin.xml

   <csp name="onboarding-youtube-scripts"
            key="onboarding-csp-fragment"
            class="<FULL CLASS PATH LIKE(COM.YOUR.APP.CLASS)>"/>

   Create the Class File

   package <PACKAGE_NAME>
   
   import com.atlassian.security.csp.api.CspDirective;
   import com.atlassian.security.csp.api.CspFragment;
   
   import java.net.URI;
   import java.util.Set;
   
   /**
    * CSP Fragment to whitelist a url
    * Registered via the {@code <csp>} module descriptor in atlassian-plugin.xml.
    */
   public class CLASS_NAME implements CspFragment {
   
       private static final Set<URI> SCRIPT_ORIGINS = Set.of(
               URI.create("<URL>")
       );
   
       @Override
       public Set<CspDirective> getCSPDirectives() {
           return Set.of(CspDirective.SCRIPT_SRC);
       }
   
       @Override
       public Set<URI> getCSPOrigins(CspDirective cspDirective) {
           if (CspDirective.SCRIPT_SRC == cspDirective) {
               return SCRIPT_ORIGINS;
           }
           return Set.of();
       }
   
       @Override
       public Set<String> getUrlPatterns() {
           return Set.of("/**");
       }
   }

Custom HTML Editing Now Disabled by Default

Status: DONE

To improve security, editing custom HTML is now disabled by default. If you need to enable custom HTML, set the confluence.custom.html.config.enabled system property to true. Only system administrators can enable this feature.

How to configure system properties

Fair Journal Index Queue

Status: DONE(enabled by default from 11.0.0-m202)

The content index queue is now drained fairly across content types instead of strictly in queue order. Entries are grouped by content type (pages and blogs, attachments, comments, user profiles, custom content, other), each with its own checkpoint, and each cycle takes entries round-robin across the groups. A bulk operation on one content type — a mass attachment upload, a space import — can no longer delay indexing of everything queued behind it. Queue depth per content type is shown on the Content indexing admin page.

Applies to the content index journal (main_index) only; other journals keep the linear path.

Configuration required: No. To turn it off, disable the confluence.fair.journal.index.queue dark feature.

Fair Journal Index Queue Concurrent Processing

Status: DONE (enabled by default from 11.0.0-beta3)

Each batch taken from the fair index queue is now indexed by a pool of worker threads instead of one, increasing throughput on multi-core nodes. Entries are chunked by content identity — same content always in the same chunk, in queue order — and chunks run in parallel, each worker on its own Hibernate session. The pool is sized from the CPUs available to the JVM (capped at 50) and gives each worker at least 100 entries. Per-group ordering is preserved, and a checkpoint only advances over a confirmed run of entries.

Configuration required: No. Requires the fair journal index queue to be enabled. To fall back to serial processing, disable the confluence.fair.journal.index.queue.parallel.processing dark feature — the gate is read every cycle, so no restart is needed.

Frontend AMD and WRM Resources Removal

Status: DONE

Confluence file dialog view

• Removed AMD confluence-editor/files/file-dialog/file-dialog-view

• Removed JavaScript global Confluence.Editor.FileDialog.FileDialogView

Confluence placeholder

• Removed AMD confluence/placeholder

• Removed JavaScript globals

  • AJS.Confluence.Binder.placeholder

  • Confluence.Binder.inputDefaultText

• Replacement: placeholder HTML attribute - HTML | MDN

Confluence position

• Removed JavaScript globals AJS.Position

• Replacement: AMD module confluence/position

Confluence tooltip

• Removed WRM

  • confluence.web.resources:tooltip

  • com.atlassian.confluence.plugins.confluence-frontend:tooltip

• Removed AMD module confluence/tooltip

• Removed the global AJS.Tooltip

• Replacement: AUI Tooltip component

Confluence underscore

• Removed WRM confluence.web.resources:underscore

• Replacement: com.atlassian.confluence.plugins.confluence-frontend:underscore

HttpClient 4 Removal

Status: DONE

We're removing Apache HttpClient 4 because this version is no longer actively developed and has reached its end of life. To ensure the security and stability of our next major versions, HttpClient 4 will no longer be available as a core platform dependency.

If your app relies on Apache HttpClient or another HTTP client, you'll need to embed and manage it as your own dependency. To prepare for this change, review your code for any imports from org.apache.http.* or any usage of com.atlassian.httpclient.apache.httpcomponents that assume the library is provided by the platform. You should also verify that your apps don’t rely on the transitive exposure of HttpClient 4 through Atlassian HttpClient, as the library will be removed from the platform classpath.

JNDI Sanitisation

Status: DONE

To reduce RCE risks, we’ve sanitized Java Naming and Directory Interface (JNDI) locations across Data Center. We restricted locations to the java: prefix or permitted relative prefixes jdbc/ and mail/. This change affects lookup, doLookup, lookupLink, and rename methods.

We’ve also deleted some OSWorkflow packages to further mitigate JNDI vulnerabilities and reduce maintenance.

The following packages and their classes have been removed from OSWorkflow:

• com.opensymphony.workflow.timer

• com.opensymphony.workflow.util

• com.opensymphony.workflow.soap

• com.opensymphony.workflow.ejb

• com.opensymphony.workflow.spi.ejb

• com.opensymphony.workflow.util.ejb.local

• com.opensymphony.workflow.util.ejb.remote

• com.opensymphony.workflow.spi.hibernate

• com.opensymphony.workflow.loader

• com.opensymphony.workflow.spi.hibernate3

• com.opensymphony.workflow.spi.jdbc

• com.opensymphony.workflow.spi.ojb

• com.opensymphony.workflow.spi.prevayler

JQuery 4 upgrade

Status: DONE

We’re upgrading to jQuery 4 to align all Data Center products on a single version. This update will make developing cross-product apps easier, especially for products currently using older versions of jQuery. As part of this change, we're also removing jQuery migrate.

Because much of our frontend code depends on jQuery, this upgrade will likely require updates to your apps and custom integrations. To help you prepare, we’re backporting as many compatible changes as possible to the following product versions:

• Jira Software 11.3

• Jira Service Management 11.3

• Confluence 10.2

• Bamboo 12.1

• Bitbucket 10

• Crowd 7

This allows you to test your apps for jQuery 4 compatibility without worrying about other breaking changes.

Additionally, AUI 10.1 now supports jQuery 4. We’ll continue to provide jQuery web resources and ask that you use them so we can roll out security patches quickly when needed. While jQuery 4 will be included in future Early Access Program (EAP) releases, it might not be available in the first few versions.

How to upgrade to jQuery 4

JQuery plugins removal

Status: DONE

As part of the jQuery upgrade, we have removed the following jQuery plugins from Confluence and no replacement is provided.

Autocomplete plugin

• Removed WRM

  • confluence.web.resources:jquery-autocomplete

  • com.atlassian.confluence.plugins.confluence-frontend:jquery-autocomplete

• Removed AMD confluence/autocomplete

• Removed jQuery plugin $.fn.autocomplete

• Replacements:

  • AUI Select2

  • Atlaskit Select

Fancybox plugin

Usage (unsupported from 11.0): $jqueryElement.fancybox([settings])

Replacement: not provided, plugins need to bundle their own copy of the plugin if needed.

Removed web-resources:

• com.atlassian.confluence.plugins.confluence-frontend:jquery-fancy-box

• confluence.web.resources:fancy-box

JSON plugin

Usage (unsupported from 11.0): $.toJSON(str)

Replacement: JSON.stringify() - JavaScript | MDN

Removed web-resources:

• com.atlassian.confluence.plugins.confluence-frontend:jquery-json

Mousewheel plugin

Usage (unsupported from 11.0): $jqueryElement.on('mousewheel', handler)

Replacement: Element: wheel event - Web APIs | MDN 

Progressbar plugin

• Removed WRM confluence.web.resources:jquery-progressbar

• Removed jQuery prototype $.fn.progressBar

• Replacements:

  • HTML progress indicator element

  • AUI progress indicator

  • Atlaskit progress bar

Viewport plugin

$jqueryElement.viewport([settings]) 

Replacement: not provided, plugins need to bundle their own copy of the plugin if needed.

Jackson 3 Upgrade

Status: DONE

We’re upgrading the Jackson dependency from version 2 to 3. If your app depends on Jackson for REST modules, we recommend testing your integration early to ensure compatibility with version 3. The official Jackson 3 upgrade guide can be found at Jackson 3 Migration Guide

Libraries migrated and moved:

• confluence-rest-jersey-jackson2 is renamed to confluence-rest-jersey-jackson, including the package rename to be com.atlassian.confluence.plugins.rest.jersey.jackson (instead of jackson2.*).
• confluence-rest-plugin-jackson2 is renamed to confluence-rest-plugin-jackson, including a package rename to com.atlassian.confluence.plugins.rest.jackson.* (instead of jackson2.*).
• New Jackson3 rest module confluence-rest-serialization-jackson3 as drop-in replacement of confluence-rest-serialization-jackson2
• Jackson2Soy now renamed to Jackson3Soy

If you have any tests that build any ObjectMapper objects, you may also need to specify the Jakarta annotations library:

        <!-- Jackson 3 jakarta-xmlbind module is required transitively when a unit test
             builds a real ObjectMapper (jackson-databind itself is visible via provided scope). -->
        <dependency>
            <groupId>tools.jackson.module</groupId>
            <artifactId>jackson-module-jakarta-xmlbind-annotations</artifactId>
            <scope>test</scope>
        </dependency>

Jakarta 11 and Spring 7 upgrade

Status: DONE

We’re migrating to Jakarta 11 and Spring 7 to keep our technology stack current.

Jakarta 11 upgrade

Most Jakarta APIs in the Atlassian ecosystem have undergone only minor updates, indicating backward-compatible changes. While major updates may affect specific use cases, we expect less impact than the previous migration from Jakarta 8 to Jakarta 10. We recommend reviewing the official Jakarta documentation to understand how these updates might affect your work. Refer to the Jakarta documentation for more details

Spring 7 upgrade

While key concepts remain stable and some apps may work without recompilation, this upgrade carries similar complexity to the Spring 6 migration. Certain advanced features may change and require updates. We recommend reviewing the official Spring documentation to understand how these updates might affect your work. Refer the Spring documentation for more details

Java 25 is Now the Minimum Supported Version

Status: DONE

Java 25 is the minimum supported version for both compile and runtime environments. To ensure a smooth transition, we’ve confirmed that all platform apps support Java 25 through dedicated CI testing.

Joda-Time removal

Status: DONE

Confluence Data Center core will no longer provide Joda-Time as a runtime dependency or OSGi export. A migration to java.time is strongly recommended. As an interim measure, Plugins may temporarily bundle their own package-private Joda jar, as long as Joda types do not cross plugin boundaries.

Jsoup 1.22.2 upgrade

Status: DONE

To upgrade to Jsoup 1.22.2 safely in Confluence 11, use com.atlassian.confluence.util.JsoupUtil.parse() instead of org.jsoup.Jsoup.parse() for HTML parsing.

Upgrade Recommendation

• Target library: Jsoup 1.22.2

• Affected versions: Confluence 9.2.23, 10.2.15, and 11

• Old method: org.jsoup.Jsoup.parse()

• New method: com.atlassian.confluence.util.JsoupUtil.parse()

Code Migration Steps

1. Replace direct calls to Jsoup.parse with the Confluence utility wrapper.

2. Ensure proper import statements point to Atlassian's utility class.

3. Test HTML rendering behavior after updating. 

Log4j 1.x API No Longer Available to Apps

Status: DONE

The log4j 1.x API is no longer part of the Confluence public API. Apps can no longer import the following package:

• org.apache.log4j

An app that still imports it will fail to resolve when installed on Confluence 11.0. Log the same information through either of these, both of which are public API in Confluence 11.0:

• org.slf4j — recommended. LoggerFactory.getLogger(MyClass.class) returns an org.slf4j.Logger.

• org.apache.logging.log4j — the log4j 2 API, along with org.apache.logging.log4j.message and org.apache.logging.log4j.util.

Most callers only need to change the import and the logger factory call. The common log4j 1.x methods (debug, info, warn, error) have direct SLF4J equivalents.

Logging Configuration Moved to log4j2.xml

Status: DONE

From Confluence 11.0, the log4j.properties format will no longer be used and is replaced by log4j2.xml. Below are the affected files:

Up to 10.2.x

• WEB-INF/classes/log4j.properties

• WEB-INF/classes/log4j-diagnostic.properties

From Confluence 11.0

• WEB-INF/classes/log4j2.xml

• WEB-INF/classes/log4j2-diagnostic.xml

A log4j.properties left in place after an upgrade is ignored, not merged. Any logging customisation in it stops applying. Confluence logs a warning at startup when it finds one. If you customised logging, re-apply those changes to log4j2.xml before upgrading, then delete log4j.properties to silence the warning. Setting log levels at runtime through Logging and Profiling in the admin UI is unchanged.

Look and Feel layouts editing now disabled by default

Status: DONE

To improve security, configuring Look and Feel customization is now disabled by default. Admins can only view existing layout configurations. To enable look and feel customization, set the confluence.custom.look.and.feel.enabled system property to true. Only system administrators can enable this feature.

How to configure system properties

React 19 upgrade

Status: DONE

We're upgrading to React 19. React is a core frontend dependency in DC products and a dependency for other important frontend libraries such as Atlaskit. Because of this, Marketplace apps using React will also need to upgrade to React 19.

Areas affected by this upgrade:

• com.atlassian.plugins:react web resource will now provide React 19

• Clientside Extensions (CSE) will now use React 19

As we learn more and develop tools to help with the migration, we will update the developer documentation.

More details can be found in community post at React 19 upgrade in Data Center (Jira 12, Confluence 11, Bitbucket 11, Bamboo 13, Crowd 8)

Removal of support for transformed plugins

Status: DONE

We are deleting all transformation code and infrastructure from the platform. This means the runtime transformation process, which previously converted older plugin formats at startup, will no longer exist.

If a user attempts to install or enable a transformed plugin, the UPM will block the action and display a clear error message. Any transformed plugins already installed will be forcibly disabled upon upgrading to a Platform 9-based product version.

To ensure your apps continue to work on Data Center Platform 9, you must migrate them to the "transformerless" format. The following guides might help you in this process:

• How to automate the migration process

• More about identifying and converting plugins

We provide a conversion script to help automate this process. For further guidance and best practices, you can refer to our documentation on Spring Java configuration of app components.

Restore from Local Drive now disabled by default

Status: DONE

To improve application security, restoring of data from local drives is now disabled by default. To enable restoring of data from local drive , set confluence.restore.from.local.drive.enabled system property to true. Only system administrators can enable this feature via the configuring of system properties.

SSRF Protection: Default Outbound Denylist and Allowlist Enforcement

Status: DONE

To strengthen protection against Server-Side Request Forgery (SSRF) attacks, we have introduced a default outbound request denylist and extended allowlist enforcement to additional platform components. The denylist automatically blocks outbound connections to sensitive internal endpoints - such as cloud metadata services (AWS, Google Cloud, Azure) and link-local IP addresses - as well as dangerous non-HTTP protocols (e.g., file://, ftp://, ldap://).

Additionally, several platform components that previously bypassed the allowlist - including OAuth2, Gadgets, UPM/Marketplace, Application Links, and Webhooks - now respect the allowlist configuration, ensuring consistent outbound request filtering across the platform.

Why we are making this change

This work is being undertaken to address security vulnerabilities related to SSRF, which could allow attackers to use servers to make unauthorized requests to internal or external resources.

Default outbound denylist

A new hardcoded denylist has been added to the allowlist plugin that blocks outbound requests to known-dangerous destinations. The denylist is evaluated if the allowlist is disabled.

The denylist blocks:

• Cloud Metadata Services: AWS, Google Cloud, and Azure instance metadata endpoints ( 169.254.169.254, metadata.google.internal, metadata.azure.internal)

• AWS Metadata Service IP Ranges: The entire 169.254.0.0/16 IPv4 range and the fd00:ec2::254 IPv6 AWS metadata address

• dangerous protocols: file://, ftp://, gopher://, ldap://, dict://, smtp://, tftp://, ssh://, sftp://, jdbc://, mysql://, postgres://, ws://, smb://, jar://, phar://, nfs://

• loopback and localhost: 127.0.0.0/8, ::1/128

• private networks: 10.0.0.0/8 (Class A), 172.16.0.0/12 (Class B), 192.168.0.0/16 (Class C), fc00::/7 (IPv6 ULA)

The denylist also performs DNS resolution of domain URIs to compare resolved IP addresses against IP/CIDR denylist rules, preventing bypasses via DNS rebinding or custom domain resolution to blocked IPs.

Allowlist enforcement extended to additional platform components

We've extended allowlist enforcement to several platform and product plugins that previously made outbound network requests without going through the allowlist. The following components now respect the allowlist configuration:

• OAuth2: outbound requests made by the OAuth2 plugin

• Gadgets: outbound requests made by the gadgets framework, such as gadget spec fetching, HTTP cache

• UPM and Marketplace: outbound requests made by the UPM (Marketplace URLs are allowlisted by default)

• Application Links: outbound requests made via application link connections

• Webhooks: outbound requests made when delivering webhook events

If your app relies on any of these components to make outbound requests to external services, ensure those URLs are included in the allowlist configuration. Marketplace URLs are automatically allowlisted.

What you need to do

These protections are enabled by default and require no configuration, providing immediate out-of-the-box SSRF protection for Jira, Confluence, and JSM instances. If needed, administrators can disable the denylist via JVM system properties (e.g., -Dssrf.denylist.enabled=false), though this is not recommended for production environments.

To mitigate SSRF attacks, we ask you to configure a proper allowlist, which is an effective defense against SSRF. While a denylist can help protect against some obvious SSRF vulnerabilities, the ultimate solution should be a comprehensive allowlist.

More granular control of the denylist is achievable via the following system properties:

ssrf.denylist.enabled

ssrf.denylist.dns.enabled

ssrf.denylist.protocols.enabled

ssrf.denylist.localhost.enabled

false

V3 Attachment Storage Removal

Status: DONE

Confluence 8.1 introduced the v4 attachment layout and a background migration that moved attachment data from ver003 to v4. Confluence 11.0 removes version 3 (ver003) attachment storage entirely: the storage implementation, the automatic V3 → V4 migration, and the related APIs.

Note that the V3 → V4 migration no longer runs in Confluence 11.0 and must have been completed prior to upgrading.

Confluence Mobile Web Removal

Status: DONE

We have removed the legacy Confluence mobile web interface in Confluence 11.0. This change does not affect the Confluence Data Center mobile app.

When users access Confluence from a mobile browser, Confluence now prompts them to either:

• download the Confluence Data Center mobile app, or

• continue to the desktop version of Confluence in their browser.

Existing links to the former mobile interface redirect to the corresponding standard Confluence page where possible.

Implemented changes

In this section we'll provide details of changes we have implemented, organised by the milestone they are first available in. This will help you decide which milestone to use when testing.

Beta –  8 September 2026

Milestone 11.0.0-beta3

Contains:

• Complete migration to Jackson 3

• Removal of Log4j 1 (and migration to Log4j 2)

• Removal of Joda time

• Concurrent processing of the fair journal index queue

• HttpClient 4 removal

• Removal of OpenSymphony PropertySet

• Minor Bug fixes, including fix for CONFSERVER-104454

EAP 08 - 5 August 2026

Milestone 11.0.0-m221

Contains:

• Asynchronous macro execution

• Minor bug fixes

EAP 07 - 13 July 2026

Milestone 11.0.0-m202

Contains:

• Migration of REST to Jackson 3

• Fair journal index queue implemented

• Minor bug fixes

EAP 06 - 15 June 2026

Milestone 11.0.0-m177

Contains:

• Minor bug fixes

EAP 05 - 02 June 2026

Milestone 11.0.0-m168

Contains:

• Concurrent attachment uploads

• Minor bug fixes

EAP 04 – 06 May 2026

Milestone 11.0.0-m148

Contains:

• Look and Feel customization editing is now disabled by default

• CSP strict mode enabled by default

• JQuery Fancybox and JSON plugins removed

• Minor bug fixes

EAP 03 – 08 April 2026

Milestone 11.0.0-m116

Contains:

• A stricter Content Security Policy (CSP) is now configurable via a system property

• A default outbound request denylist has been added as protection against SSRF

• Minor bug fixes

• JQuery 4

EAP 02 – 3 March 2026

Milestone 11.0.0-m79

Contains:

• Look and Feel layouts editing now disabled by default

• Minor bug fixes

EAP 01 – 10 February 2026

Milestone 11.0.0-m55

Contains:

• Custom HTML editing now disabled by default

• Minor bug fixes