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.

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.

Jenkins Play Framework Plugin 1.0.2 and earlier lets users specify the path to the play command on the Jenkins master for a form validation endpoint, resulting in an OS command injection vulnerability exploitable by users able to store such a file on the Jenkins master.

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.

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.

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