The administration backup restore resource in Atlassian Crowd before version 3.0.2 and from version 3.1.0 before version 3.1.1 allows remote attackers to read files from the filesystem via a XXE vulnerability.

The login resource of CrowdId in Atlassian Crowd before version 3.0.2 and from version 3.1.0 before version 3.1.1 allows remote attackers to redirect users to a different website which they may use as part of performing a phishing attack via an open redirect.

The administration SMTP configuration resource in Atlassian Crowd before version 2.10.2 allows remote attackers with administration rights to execute arbitrary code via a JNDI injection.

Various resources in the Crowd Demo application of Atlassian Crowd before version 3.1.1 allow remote attackers to modify add, modify and delete users & groups via a Cross-site request forgery (CSRF) vulnerability. Please be aware that the Demo application is not enabled by default.

The identifier_hash for a session token in Atlassian Crowd before version 2.9.1 could potentially collide with an identifier_hash for another user or a user in a different directory, this allows remote attackers who can authenticate to Crowd or an application using Crowd for authentication to gain access to another user's session provided they can make their identifier hash collide with another user's session identifier hash.

The console login resource in Atlassian Crowd before version 3.0.2 and from version 3.1.0 before version 3.1.1 allows remote attackers, who have previously obtained a user's JSESSIONID cookie, to gain access to some of the built-in and potentially third party rest resources via a session fixation vulnerability.

The 'crowd-application' plugin module (notably used by the Google Apps plugin) in Atlassian Crowd from version 1.5.0 before version 3.1.2 allowed an attacker to impersonate a Crowd user in REST requests by being able to authenticate to a directory bound to an application using the feature. Given the following situation: the Crowd application is bound to directory 1 and has a user called admin and the Google Apps application is bound to directory 2, which also has a user called admin, it was possible to authenticate REST requests using the credentials of the user coming from directory 2 and impersonate the user from directory 1.

Various resources in Atlassian Crowd before version 2.10.1 allow remote attackers with administration rights to learn the passwords of configured LDAP directories by examining the responses to requests for these resources.