General Information

A critical severity authentication vulnerability was discovered in Jira Service Management Server and Data Center (CVE-2023-22501). Read more about it here.

This page contains frequently asked questions and answers about this vulnerability. The Atlassian Security Team will update this page as new information becomes available.

Are Cloud instances affected?

No, Atlassian Cloud instances are not vulnerable and no customer action is required. 

My instance isn't exposed to the Internet. Is an upgrade still recommended?

Yes! While ensuring instances are not exposed to the public internet greatly reduces the attack surface, we always recommend upgrading when security fixes are available. We try to provide as much information as possible so that customers can determine the scope and impact. It's ultimately up to each customer to consider this information when determining whether mitigating factors, like no external access to the instance, reduce the risk to their business enough to defer installing an upgrade.

My instance has public signup enabled but we are using an external user directory with SSO enabled. Is an upgrade still recommended?

Yes! Users synced to Jira via read-only User Directories or SSO are not affected, but external customers who interact with the instance via email are still affected, even when SSO is configured.

Will a user be notified that they had their password changed by an attacker?

No notification or email is sent when the password is set.

Does disabling the “Require email verification to create account” setting mitigate the vulnerability?

No, only one of the following actions will mitigate this vulnerability:

• Upgrading Jira Service Management to one of the fixed versions listed in the advisory, located here.

• Updating the version-specific JAR file included in the advisory, located here.

Does any project permission scheme protect against this vulnerability?

No, only upgrading Jira Service Management or upgrading the version-specific JAR file can protect against the exploitation of this vulnerability. You can find the steps to remediate this vulnerability in the advisory, located here.

Do any Project settings protect against this vulnerability?

No, only upgrading Jira Service Management or upgrading the version-specific JAR file can protect against exploitation of this vulnerability. You can find the steps to remediate this vulnerability in the advisory, located here.

Can we determine if Jira Service Management has already been compromised?

Unfortunately, Atlassian cannot confirm if a Jira Service Management instance has been compromised.

However, after you upgrade Jira Service Management or you update your instance with the version-specific JAR file, you can find a list of possibly affected accounts. Accounts that had a password changed and have been logged into since the vulnerable version was installed together could potentially be compromised accounts.

Find potentially compromised accounts

1. Upgrade Jira Service Management or update your instance with the version-specific JAR file.

2. Confirm the upgrade task is finished (after Jira restarts) by polling the property com.jsm.usertokendeletetask.completed for the value “TRUE”
(A test instance of 200K users took less than 20 minutes).

select * from propertyentry where property_key = 'com.jsm.usertokendeletetask.completed';

3. Run the following SQL.

SELECT CWD_USER.*
FROM CWD_USER_ATTRIBUTES
  JOIN CWD_USER ON CWD_USER.ID = CWD_USER_ATTRIBUTES.USER_ID
WHERE (USER_ID in
  (SELECT USER_ID
  FROM cwd_user_attributes
  WHERE attribute_name='password.reset.after.vulnerable.install'))

Verify (and correct) email addresses

Using this list, verify that the email addresses associated with the accounts have not been changed by a possible attacker:

• For internal users, verify the correct email domain

• For publicly signed-up users, verify that the username is identical to the email address

Force password change

Multi-node Data Center (command-line ONLY)

We recommend you force a password change for all users identified as potentially compromised, so it is critical to ensure their email addresses are correct.

You can force a password change on each user via PUT /rest/api/2/user/password see: https://docs.atlassian.com/software/jira/docs/api/REST/9.5.0/#api/2/user-changeUserPassword

Example cURL request:

curl --location --request PUT 'http://NODE_IP/rest/api/2/user/password?username=USERNAME' \
--header 'Authorization: YOUR_AUTH_INFO' \
--header 'Content-Type: application/json' \
--data-raw '{
    "password": "NEW_PASSWORD"
}'

This forces the session to expire, effectively logging out any potential attacker. Subsequently, inform any affected users to recover their account via the Forget Password workflow.

Server or single-node Data Center (UI option)

1. Navigate to User Management, jiraBaseUrl/secure/admin/user/UserBrowser.jspa

2. Search and select using the username.

Additional investigation

You can also navigate to a user’s public profile and look into the activity stream to verify recent interactions with Jira tickets:

<jiraBaseUrl>/jira/secure/ViewProfile.jspa?name=customer

My instance has been compromised, what should I do?

Unfortunately, Atlassian cannot confirm if a customer's instance has been compromised. We strongly recommend involving your local security team for further investigation. If it is determined that your Jira Service Management Server/DC instance has been compromised, our advice is to immediately shut down and disconnect the server from the network/Internet. Also, you may want to immediately shut down any other systems which potentially share a user base or have common username/password combinations with the compromised system. Before doing anything else  you will need to work with your local security team to identify the scope of the breach and your recovery options.

My software maintenance has expired, do I need to renew it to install the patch/upgrade?

Yes, every upgrade requires a license that was active when that version was released (ie. if the license expired on the 25th, an upgrade to a release made on the 26th would not work). The products will block the upgrades if the license is not valid.

I wasn't made aware of the vulnerability, how and when was this communicated by Atlassian?

An alert was sent out to all customers subscribed to the product technical alerts list, after we have developed a fix. You can check your membership of that list by going to https://my.atlassian.com/email. 

I updated my instance with the version-specific JAR file to mitigate the vulnerability but my Instance Health Check via the Atlassian Support Tools plugin continues to display that my instance is affected, why is that?

The Instance Health Check is solely based on application version so your application is safe if it has been updated with the version-specific JAR file according to the instructions included in the advisory, located here.