See how lightbend compares to other vendors in security performance
XML external entity (XXE) vulnerability in the Java XML processing functionality in Play before 2.2.6 and 2.3.x before 2.3.5 might allow remote attackers to read arbitrary files, cause a denial of service, or have unspecified other impact via crafted XML data.
Lightbend Akka 2.5.x before 2.5.16 allows message disclosure and modification because of an RNG error. A random number generator is used in Akka Remoting for TLS (both classic and Artery Remoting). Akka allows configuration of custom random number generators. For historical reasons, Akka included the AES128CounterSecureRNG and AES256CounterSecureRNG random number generators. The implementations had a bug that caused the generated numbers to be repeated after only a few bytes. The custom RNG implementations were not configured by default but examples in the documentation showed (and therefore implicitly recommended) using the custom ones. This can be used by an attacker to compromise the communication if these random number generators are enabled in configuration. It would be possible to eavesdrop, replay, or modify the messages sent with Akka Remoting/Cluster.
The decodeRequest and decodeRequestWith directives in Lightbend Akka HTTP 10.1.x through 10.1.4 and 10.0.x through 10.0.13 allow remote attackers to cause a denial of service (memory consumption and daemon crash) via a ZIP bomb.
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, data amplification can occur when an application accepts multipart/form-data JSON input.
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.
A directory traversal vulnerability has been found in the Assets controller in Play Framework 2.6.12 through 2.6.15 (fixed in 2.6.16) when running on Windows. It allows a remote attacker to download arbitrary files from the target server via specially crafted HTTP requests.
Lightbend Spray spray-json through 1.3.4 allows remote attackers to cause a denial of service (resource consumption) because of Algorithmic Complexity during the parsing of many JSON object fields (with keys that have the same hash code).
Lightbend Spray spray-json through 1.3.4 allows remote attackers to cause a denial of service (resource consumption) because of Algorithmic Complexity during the parsing of a field composed of many decimal digits.
In Play Framework 2.6.0 through 2.8.2, stack consumption can occur because of unbounded recursion during parsing of crafted JSON documents.
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.
A flaw was found in the way Netty’s CookieDecoder method validated cookie name and value characters. An attacker could use this flaw to bypass the httpOnly flag on sensitive cookies.
Upstream patch:
https://github.com/slandelle/netty/commit/800555417e77029dcf8a31d7de44f27b5a8f79b8
External References:
https://www.playframework.com/security/vulnerability/CVE-2015-2156-HttpOnlyBypass http://engineering.linkedin.com/security/look-netty%E2%80%99s-recent-security-update-cve%C2%AD-2015%C2%AD-2156
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.
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.
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.
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.
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.
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.
Latest version: 3.3.8
Latest version: 2.13.18
Latest version: 2.13.18
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
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: 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
End of support: 6/7/2019, Latest version: 2.12.21