See how lightbend compares to other vendors in security performance
End of life: 9/3/2026, End of support: 9/3/2026, Latest version: 3.8.4
End of life: 1/22/2026, End of support: 1/22/2026, Latest version: 3.7.4
End of life: 5/7/2025, End of support: 5/7/2025, Latest version: 3.6.4
End of life: 5/7/2025, End of support: 5/7/2025, Latest version: 3.6.4
End of life: 12/10/2024, End of support: 12/10/2024, Latest version: 3.5.2
End of life: 12/10/2024, End of support: 12/10/2024, Latest version: 3.5.2
End of life: 8/22/2024, End of support: 8/22/2024, Latest version: 3.4.3
End of life: 8/22/2024, End of support: 8/22/2024, Latest version: 3.4.3
Latest version: 3.3.8
When Akka HTTP before 10.5.2 accepts file uploads via the FileUploadDirectives.fileUploadAll directive, the temporary file it creates has too weak permissions: it is readable by other users on Linux or UNIX, a similar issue to CVE-2022-41946.
In Lightbend Akka before 2.8.1, the async-dns resolver (used by Discovery in DNS mode and transitively by Cluster Bootstrap) uses predictable DNS transaction IDs when resolving DNS records, making DNS resolution subject to poisoning by an attacker. If the application performing discovery does not validate (e.g., via TLS) the authenticity of the discovered service, this may result in exfiltration of application data (e.g., persistence events may be published to an unintended Kafka broker). If such validation is performed, then the poisoning constitutes a denial of access to the intended service. This affects Akka 2.5.14 through 2.8.0, and Akka Discovery through 2.8.0.
Lightbend Alpakka Kafka before 4.0.2 logs its configuration as debug information, and thus log files may contain credentials (if plain cleartext login is configured). This occurs in akka.kafka.internal.KafkaConsumerActor.
End of life: 5/23/2023, End of support: 5/23/2023, Latest version: 3.2.2
End of life: 5/23/2023, End of support: 5/23/2023, Latest version: 3.2.2
End of life: 9/1/2022, End of support: 9/1/2022, Latest version: 3.1.3
End of life: 9/1/2022, End of support: 9/1/2022, Latest version: 3.1.3
Play Framework is a web framework for Java and Scala. Verions prior to 2.8.16 are vulnerable to generation of error messages containing sensitive information. Play Framework, when run in dev mode, shows verbose errors for easy debugging, including an exception stack trace. Play does this by configuring its DefaultHttpErrorHandler to do so based on the application mode. In its Scala API Play also provides a static object DefaultHttpErrorHandler that is configured to always show verbose errors. This is used as a default value in some Play APIs, so it is possible to inadvertently use this version in production. It is also possible to improperly configure the DefaultHttpErrorHandler object instance as the injected error handler. Both of these situations could result in verbose errors displaying to users in a production application, which could expose sensitive information from the application. In particular, the constructor for CORSFilter and apply method for CORSActionBuilder use the static object DefaultHttpErrorHandler as a default value. This is patched in Play Framework 2.8.16. The DefaultHttpErrorHandler object has been changed to use the prod-mode behavior, and DevHttpErrorHandler has been introduced for the dev-mode behavior. A workaround is available. When constructing a CORSFilter or CORSActionBuilder, ensure that a properly-configured error handler is passed. Generally this should be done by using the HttpErrorHandler instance provided through dependency injection or through Play's BuiltInComponents. Ensure that the application is not using the DefaultHttpErrorHandler static object in any code that may be run in production.
Play Framework is a web framework for Java and Scala. A denial of service vulnerability has been discovered in verions 2.8.3 through 2.8.15 of Play's forms library, in both the Scala and Java APIs. This can occur when using either the Form#bindFromRequest method on a JSON request body or the Form#bind method directly on a JSON value. If the JSON data being bound to the form contains a deeply-nested JSON object or array, the form binding implementation may consume all available heap space and cause an OutOfMemoryError. If executing on the default dispatcher and akka.jvm-exit-on-fatal-error is enabled—as it is by default—then this can crash the application process. Form.bindFromRequest is vulnerable when using any body parser that produces a type of AnyContent or JsValue in Scala, or one that can produce a JsonNode in Java. This includes Play's default body parser. This vulnerability been patched in version 2.8.16. There is now a global limit on the depth of a JSON object that can be parsed, which can be configured by the user if necessary. As a workaround, applications that do not need to parse a request body of type application/json can switch from the default body parser to another body parser that supports only the specific type of body they expect.
End of life: 10/18/2021, End of support: 10/18/2021, Latest version: 3.0.2
End of life: 10/18/2021, End of support: 10/18/2021, Latest version: 3.0.2
This affects all versions before 10.1.14 and from 10.2.0 to 10.2.4 of package com.typesafe.akka:akka-http-core. It allows multiple Transfer-Encoding headers.
An issue was discovered in Play Framework 2.8.0 through 2.8.4. Carefully crafted JSON payloads sent as a form field lead to Data Amplification. This affects users migrating from a Play version prior to 2.8.0 that used the Play Java API to serialize classes with protected or private fields to JSON.
In Play Framework 2.6.0 through 2.8.2, data amplification can occur when an application accepts multipart/form-data JSON input.
An issue was discovered in PlayJava in Play Framework 2.6.0 through 2.8.2. The body parsing of HTTP requests eagerly parses a payload given a Content-Type header. A deep JSON structure sent to a valid POST endpoint (that may or may not expect JSON payloads) causes a StackOverflowError and Denial of Service.
In Play Framework 2.6.0 through 2.8.2, stack consumption can occur because of unbounded recursion during parsing of crafted JSON documents.
In Play Framework 2.6.0 through 2.8.1, the CSRF filter can be bypassed by making CORS simple requests with content types that contain parameters that can't be parsed.
An issue was discovered in Lightbend Play Framework 2.5.x through 2.6.23. When configured to make requests using an authenticated HTTP proxy, play-ws may sometimes, typically under high load, when connecting to a target host using https, expose the proxy credentials to the target host.
Latest version: 2.13.18