General Information

The vulnerability in Crowd allows an attacker connecting from IP in the allow list to authenticate as the Crowd application by bypassing a password check. This would allow the attacker to call privileged endpoints in Crowd's REST API under the usermanagement path. As explained above, it can only be exploited by IPs specified under the Crowd application’s allowlist in the Remote Addresses configuration. To remediate the vulnerability, Atlassian recommends that you upgrade your instance to one of the fixed versions listed in the ‘Fixed Versions' section below.

This page contains frequently asked questions and answers about this vulnerability. The Atlassian Security Team will continuously 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.

What Crowd versions are affected?

All versions of Crowd released after 3.0.0 are affected, which means all new installations running any of the following versions:

• Crowd 3.0.0 - Crowd 3.7.2

• Crowd 4.0.0 - Crowd 4.4.3

• Crowd 5.0.0 - Crowd 5.02

Only new installations are vulnerable. For example, if you upgraded from version 2.9.1 to 3.0.0, your instance is not affected. But in this case, any default remote addresses that were in version 2.9.1 will be carried over to the instance running version 3.0.0. These can be removed from the Remote Address configuration for the crowd application as well.

I'm using another Atlassian Data Center/Server product that relies on Embedded Crowd for user management, Am I affected?

No, Atlassian Data Center/Server products that rely on Embedded Crowd for user management are not affected.

On which versions of Crowd was this vulnerability fixed?

Please refer to the following list of fixed versions that were released for Crowd Server: 

Is it possible to mitigate this vulnerability?

If you are unable to upgrade Crowd immediately, a temporary mitigation is to remove any entries in the 'Remote Addresses' tab for the Crowd application in the Crowd product. You can navigate to the Remote Address configuration by following the document [here|https://confluence.atlassian.com/crowd/specifying-an-application-s-address-or-hostname-25788433.html].
Note: If your instance was ever running an earlier version of Crowd before 3.0.0, the Remote Addresses tab for the Crowd application could be populated with a reasonably sized list of hostnames & IP addresses matching the local host (typically all ipv4 & ipv6 addresses at the time when Crowd was installed with the <3.0.0 version). 29 30If you feel unsure about removing entries, take a backup/screenshot of the list before removing all entries on the 'Remote Addresses' tab. By default, Crowd does not need any IP addresses listed in the crowd app to function.

Why hasn't this bug fix been released for the version I'm using?

Crowd version 3.0 is deprecated so there is no fix available. Please upgrade to version 4.4.4 or 5.0.3.

I need help upgrading, what should I do?

Please see the Upgrading Crowd documentation for detailed information and step-by-step instructions related to upgrading. It contains all the information in this document as well as other helpful tips to be sure your upgrade is successful.
The most important step to take to avoid production outages is to follow change management best practices by testing the upgrade in a staging environment first. Kindly refer to Migrating Crowd Between Servers to move Crowd data to a staging server to test the upgrade.
If you have questions or concerns, please raise a support request at https://support.atlassian.com/.

How does Atlassian decide who to send these emails to?

Atlassian sends a copy of all critical security advisories to the 'Alerts' mailing list for the product concerned, excluding Sourcetree. To ensure you are on this list, please update your email preferences at https://my.atlassian.com/email.

Can we determine if Crowd has already been compromised?

Unfortunately, Atlassian cannot confirm if a Crowd instance has been compromised.
If you have access logs configured beforehand as outlined in How do I enable Access Logging for Crowd?, it should be possible to narrow down calls to the */usermanagement* path that do not come from any of the other products connected to Crowd. By default, Crowd doesn't offer access logs, if access logs are set up after the possible compromise, you will not be able to see any evidence in the access logs.
Additionally, there is a way to determine if this vulnerability was exploited by checking the *Audit Log* inside Crowd itself by checking for actions done by Crowd. There is a guide on how to use the Audit Log.
We'd highly recommend involving the local security team or a specialist security forensics firm for further investigation.

How can I verify if Crowd was upgraded from a version older than 3.x?

If you are unsure whether Crowd was upgraded from a version older than Crowd 3.x, assume you are affected and follow the mitigation steps or upgrade to a fixed version of Crowd.