Rossabaker

**Name of the Vulnerable Software and Affected Versions** http4s versions 0.21.26 and prior http4s versions 0.22.0 through 0.22.2 http4s versions 0.23.0 and 0.23.1 http4s versions 1.0.0-M1 through 1.0.0-M24 **Description** The default CORS configuration in http4s is vulnerable to an origin reflection attack and a Null Origin Attack. This allows a malicious script to exfiltrate sensitive information with the user's credentials. The issue is related to the `anyOrigin` flag in `CORSConfig` being `true` by default, which allows sharing resources regardless of the `allowedOrigins` setting. Additionally, the `allowCredentials` setting being `true` by default approves sharing responses that may have required credentials for sensitive information with any origin. **Recommendations** For versions 0.21.26 and prior, update to version 0.21.27 or later. For versions 0.22.0 through 0.22.2, update to version 0.22.3 or later. For versions 0.23.0 and 0.23.1, update to version 0.23.2 or later. For versions 1.0.0-M1 through 1.0.0-M24, update to version 1.0.0-M25 or later. As a temporary workaround, consider setting `anyOrigin` to `false` and specifically including trusted origins in `allowedOrigins`, or disabling credentials by setting `allowCredentials` to `false`.

**Name of the Vulnerable Software and Affected Versions** http4s versions 0.21.7 through 0.21.23 http4s versions 0.22.0-M1 through 0.22.0-M8 http4s version 0.23.0-M1 http4s versions 1.0.0-M1 through 1.0.0-M22 **Description** The `StaticFile.fromUrl` function can leak the presence of a directory on a server when the `URL` scheme is not `file://`, and the URL points to a fetchable resource under its scheme and authority. The function returns `F[None]`, indicating no resource, if `url.getFile` is a directory, without first checking the scheme or authority of the URL. If a URL connection to the scheme and URL would return a stream, and the path in the URL exists as a directory on the server, the presence of the directory on the server could be inferred from the 404 response. The contents and other metadata about the directory are not exposed. **Recommendations** For versions 0.21.7 through 0.21.23, update to version v0.21.24. For versions 0.22.0-M1 through 0.22.0-M8, update to version v0.22.0-RC1. For version 0.23.0-M1, update to version v0.23.0-RC1. For versions 1.0.0-M1 through 1.0.0-M22, update to version v1.0.0-M23. As a temporary workaround, avoid calling `StaticFile.fromUrl` with non-file URLs.

Name of the Vulnerable Software and Affected Versions: blaze-core versions prior to 0.14.15 http4s-blaze-server versions prior to 0.21.17 Description: The issue is caused by unbounded connection acceptance in blaze-core, leading to file handle exhaustion. This can amplify degradation in services that are unable to handle their current request load, as incoming connections are still accepted and added to an unbounded queue. Each connection allocates a socket handle, which drains a scarce OS resource. This can also confound higher level circuit breakers which work based on detecting failed connections. The vast majority of affected users are using it as part of http4s-blaze-server. http4s provides a mechanism for limiting open connections, but it is enforced inside the Blaze accept loop, after the connection is accepted and the socket opened. Recommendations: For blaze-core versions prior to 0.14.15, update to version 0.14.15 or later, which includes a `maxConnections` parameter to limit concurrent connections. For http4s-blaze-server versions prior to 0.21.17, consider using an Nginx side-car as a reverse proxy to apply connection limiting semantics before the sockets reach blaze-core, or use alternative servers such as http4s-ember-server, http4s-jetty, or http4s-tomcat. As a temporary workaround, consider setting a negative number for the `maxConnections` parameter to run unbounded, but this is not recommended.

Name of the Vulnerable Software and Affected Versions: http4s versions prior to 0.21.17 http4s versions prior to 0.22.0-M2 http4s versions prior to 1.0.0-M14 Description: The issue is related to the blaze-core library, which accepts connections unboundedly on its selector pool. This can lead to a denial-of-service, as incoming connections are still accepted and added to an unbounded queue, draining scarce OS resources. The `MaxActiveRequests` middleware mechanism in http4s only limits the number of connections that can be simultaneously processed, not the number of connections that can be held open. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited. Technical details about exploitation include the fact that each connection allocates a socket handle, which can confound higher level circuit breakers that work based on detecting failed connections. Recommendations: For versions prior to 0.21.17, consider using an Nginx side-car as a reverse proxy to apply connection limiting semantics before sockets reach blaze-core. For versions prior to 0.22.0-M2, consider using an Nginx side-car as a reverse proxy to apply connection limiting semantics before sockets reach blaze-core. For versions prior to 1.0.0-M14, consider using an Nginx side-car as a reverse proxy to apply connection limiting semantics before sockets reach blaze-core. Alternatively, consider using http4s-ember-server, http4s-jetty, or http4s-tomcat as alternatives to http4s-blaze-server, but note that they may have performance differences and limited feature support. As a temporary workaround, consider setting the `maxConnections` property to a positive value to limit the number of concurrent connections.