rabbitmq-server: RabbitMQ: CORS * reflects Origin with Allow-Credentials
What fixes it
- 3.13.17rabbitmq-server, otherGitHub
- 4.0.22rabbitmq-server, otherGitHub
- 4.1.13rabbitmq-server, otherGitHub
- 4.2.6rabbitmq-server, otherGitHub
A fixed version on one release line is not the upgrade target for every line. Check your exact version and any vendor backports.
Description
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.17, 4.0.22, 4.1.13, and 4.2.6, match_origin/1 returned the bare reflected Origin and allowed credentials even when the wildcard "" was configured, so the response echoed the attacker's origin together with Access-Control-Allow-Credentials. The affected code is rabbit_mgmt_cors.erl. When the management plugin is configured with a wildcard CORS origin (cors_allow_origins = ""), the handler reflects the request Origin back in Access-Control-Allow-Origin and also sends Access-Control-Allow-Credentials: true. A malicious web page that a signed-in administrator visits can then use that administrator's cached HTTP Basic credentials to issue authenticated, state-changing requests to the management API. Preconditions include The management plugin is configured with the wildcard cors_allow_origins = "*", which is an explicit operator misconfiguration A target administrator has a cached HTTP Basic-auth session in the browser. This issue is fixed in versions 3.13.17, 4.0.22, 4.1.13, and 4.2.6.
Text from CVE List
Affected versions 8
- rabbitmq-serveraffected: >= 3.13.0, < 3.13.17CVE List
- rabbitmq-serveraffected: >= 4.0.0, < 4.0.22CVE List
- rabbitmq-serveraffected: >= 4.1.0, < 4.1.13CVE List
- rabbitmq-serveraffected: >= 4.2.0, < 4.2.6CVE List
- rabbitmq-server, other>= 3.13.0, < 3.13.17GitHub
- rabbitmq-server, other>= 4.0.0, < 4.0.22GitHub
- rabbitmq-server, other>= 4.1.0, < 4.1.13GitHub
- rabbitmq-server, other>= 4.2.0, < 4.2.6GitHub