Confluence 10.0 release is available now

Hi everyone,

Confluence 10.0 is available now.

This release supports only Data Center licenses. If you have a Server license, check out your options for upgrading.

Download the latest version

What’s new?

  • Spring and Jakarta upgrade
  • Removal of deprecated components in AUI 10
  • End of support for LESS
  • Removal of Trusted apps
  • End of support for the Original theme
  • Global serialization filter
  • App signing is now enabled by default for app installations
  • Enhanced security with Content Security Policy
  • Basic authentication disabled by default
  • Monitoring and observability of the Synchrony process
  • Add scopes to REST endpoints to use OAuth 2.0 2LO
  • Control how many labels display in macros
  • Lots more!

Check out the Confluence 10.0 Release Notes to learn more.

Reminder: for future release updates, make sure you visit the Atlassian changelog, and consider subscribing to the RSS feed.

I just wanted to test our app against 10.0.1 but unfortunately the atlassian.upm.signature.check.disabled=true flag seems to be broken, in contrast to 10.0.0-rc2! Installing the app now fails with the dreaded “Signature check failed” error. We’ve tried troubleshooting it by setting ALL possible system flags and also using the upm configuration file.

We use the docker image. I just replace the image tag from 10.0.0-rc2 to 10.0.1 and it breaks, so I’m quite sure the problem is on the Atlassian side. Could you please check that?

Same problem with the tar.gz distribution, UPM version is 8.0.2.

According to the docs, the system property should still be working and is even recommended:

In UPM 8.0, the easiest way to disable the feature is to set the atlassian.upm.signature.check.disabledsystem property to true .

Please fix this quickly. Not being able to upload unsigned apps during development is a very annoying.

We are also running into the signature check failure, using the Confluence 10.0.1 docker image and an upm.properties file with atlassian.upm.signature.check.disabled=true in /var/atlassian/application-data/confluence-shared/upmconfig.

App uploads fail with “Signature check failed”.

Here’s a workaround for the signature checking:

Replace the existing JAR of UPM (version 8.0.2) in the Confluence installation directory with version 8.0.1.
The file is located here: <INSTALL_DIR>/confluence/WEB-INF/atlassian-bundled-plugins/com.atlassian.upm.atlassian-universal-plugin-manager-plugin-8.0.2.jar

You can download version 8.0.1 from here: Atlassian Repository: com/atlassian/upm/atlassian-universal-plugin-manager-plugin/8.0.1/

Docker users should be able to achieve the same by bind-mounting the 8.0.1 file to the above location of version 8.0.2.

:see_no_evil_monkey:

Obviously this should be considered a short-time hack for use until there’s a fixed UPM version available :slight_smile:

@SteffenMueller @jens @cheinig We are really sorry for the inconvenience. Our team noticed the issue and is already working on the fix. We will inform you about the progress.

@jens, thanks for sharing this workaround. Will use it for now, as we are also affected (with the tar.gz distrobution).

@MarekTokarski, your team might also look into this missing velocity-allowlist entry (saw it in my Confluence 10.0.1 logs with UPM 8.0.2):

2025-08-06 14:37:28,581 WARN [http-nio-20204-exec-3] [velocity] log Invocation blocked as method is not allowlisted: com.atlassian.upm.velocity.UpmConfigStatusData#isPluginSigningEnabled() [com.atlassian.upm.atlassian-universal-plugin-manager-plugin] (com.atlassian.upm.atlassian-universal-plugin-manager-plugin [238])

@Kusal @ggautam Just navigating to login.action on Confluence 10.0.1 results in this warning being printed to the logs 7 times:

2025-08-06 17:52:59,727 WARN [http-nio-127.0.0.1-1992-exec-7 url: /confluence/login.action, /confluence/plugins/servlet/login] [velocity] log Invocation blocked as method is not allowlisted: org.apache.commons.lang3.StringUtils#isNotEmpty(java.lang.CharSequence) [webapp] (ParallelWebappClassLoader
  context: confluence
  delegate: false
----------> Parent Classloader:
java.net.URLClassLoader@4abdb505
)
 -- url: /confluence/login.action | userName: anonymous | traceId: 7b32e8aba80d6259

Going to viewpage.action prints it 57 times.

Should probably be fixed as it spams the log quite a bit…

Thanks @AndreasEbert , adding this to the fix.

Will there be a 10.0.2 with the fixes that will then be the official minimum 10.x release available or will the 10.0.1 stay the lowest available 10.x version?

Hi @jens

I have just tested login.action and viewpage.action and haven’t found this warning. So much so we allow all methods of org.apache.commons.lang3.StringUtils class.

To further reproduce the issue, can you please confirm how did you start the instance, plugins installed, Java version used and attach the logs if possible.

Thanks for reporting this @jens - whilst Velocity has been bolstered with the central blocklist in 10.0, the actual allowlist mechanism has remained unchanged, and certainly hasn’t changed between RC2 and GA. The issue you mention however, has been reported by numerous customers and partners since the release of Confluence 9.0.

Despite all of the customer reports and instance data gathered, I, and none of our support engineers have been able to identify a common factor, nor reproduce this issue.

I am currently investigating a lead that if the very first Velocity template rendered upon instance startup originates from UPM, this allowlist error will trigger and persist until the instance is restarted.

If you’ve any other clues to contributing factors that would help us reproduce it, I’m all ears. You’re also most welcome to attach a debugger yourself - we expect the bug lies in the vicinity of org.apache.velocity.util.introspection.SecureIntrospectorImpl#isAllowlistedClassPackageCached (org.apache.velocity:velocity:1.6.4-atlassian-39).

Thank you all for reporting the issues with UPM.

UPM 8.0.3 has been released with a fix. You may track the release of a fixed version of Confluence 10.0 on CONFSERVER-100507.

Hi All,

We have released Confluence 10.0.2 with the included fix.

Docker images will become available as our pipelines process them over the next couple of hours.

@Kusal I’ve attached a debugger and reproduced it.

I’m sending you a PN with the details, but your assumption seems to be correct: SecureIntrospectorImpl#allowlistedClassesRef contains a Class object loaded from UPM’s classloader (and the UPM JAR includes an exploded commons-lang3).

That explains why isAllowlistedClassPackageInternal returns false when checking the StringUtils Class object loaded from the web app classloader.

Very much appreciated @jens - I’ll continue the investigation and hopefully have a bug report up soon.

@jponting could you please check the docker pipeline. It is 8h after your post and 10.0.2 ubi image is not available yet. Would be great if it will be available soon. Thanks

Hey @clouless,

We’ve identified a problem downstream of us. We’re working with the team in question to get it resolved. Thanks for the heads up on this.

If you need the container desperately, you can build it directly from the repository, but we’ll try and get you the real one ASAP.

We have the pipeline running now. Assuming nothing else goes catastrophically wrong, they should be out shortly.

ETA:: JDK 21 builds are there now, the rest are propagating through.

Concerning the truststore, to be honest:

  • I know that, as vendors, we have special instructions to set up the trust store,
  • But for customers, I’m not sure the instructions are readable, so as a vendor, I’m worried whether it will prevent customers from trying C10,

Example:

So anyway, I think customers will need a few simple instructions, such as:


# Download Atlassian's root certificates for app signing
wget https://confluence.atlassian.com/upm/files/1489470540/1489470539/1/1736436578282/atlassian_ca_bundle-v1.zip
unzip atlassian_ca_bundle-v1.zip

# Build a keystore
keytool -importcert -noprompt -alias atlassianrootcert -storepass atlassian -keystore truststore.jks -file atlassian_mpac_root_ca_v1.crt
keytool -importcert -noprompt -alias atlassianintermediatecert -storepass atlassian -keystore truststore.jks -file atlassian_mpac_intermediate_ca_v1.crt
keytool -list -keystore truststore.jks

# For the docker image:
mkdir -p /var/atlassian/application-data/confluence/upmconfig/truststore
cp truststore.jks /var/atlassian/application-data/confluence/upmconfig/truststore/truststore.jks

RUN chown -R root:confluence       /var/atlassian/application-data/confluence/upmconfig
RUN chmod ug=rx,o=                 /var/atlassian/application-data/confluence/upmconfig
RUN chmod ug=rx,o=                 /var/atlassian/application-data/confluence/upmconfig/truststore
RUN chmod ug=r,o=                  /var/atlassian/application-data/confluence/upmconfig/truststore/truststore.jks

I’ve put it in our scripts here to create docker images for developer environments: launchers-dc/docker/download-atlassian-certs.sh at master · requirement-yogi/launchers-dc · GitHub (My scripts are a subset of Remie’s DCDX works, which are awesome - Thank you @Remie)

Edit: Doesn’t seem to be enough, because, this, and yet, no error message is displayed on the Trusted Certificates screen: