CVE-2022-31023
Dev error stack trace leaking into prod in Play Framework
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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
Dev error stack trace leaking into prod in Play Framework
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.
- Record
CVE-2022-31023- CVSS 3.1
- 5.9 Medium
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N - Weakness
- CWE-209
- Updated
- 2026-11-02
EUVDEUVD-2022-6107
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.
- Record
EUVD-2022-6107- CVSS 3.1
- 5.9 Medium
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-p9p4-97g9-wcrh
Dev error stack trace leaking into prod in Play Framework
Impact
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.
Patches
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.
Workarounds
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 your application is not using the DefaultHttpErrorHandler static object in any code that may be run in production.
References
https://www.playframework.com/documentation/2.8.x/ScalaErrorHandling#Supplying-a-custom-error-handler https://www.playframework.com/documentation/2.8.x/JavaErrorHandling#Supplying-a-custom-error-handler
For more information
If you have any questions or comments about this advisory:
- Open an issue in playframework/playframework
- Email us at [email protected]
- Record
GHSA-p9p4-97g9-wcrh- CVSS 3.1
- 5.9 Medium
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N - Weakness
- CWE-209
- Updated
- 2026-11-02
NVD
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.
- Record
CVE-2022-31023- CVSS 3.1
- 5.9 Medium
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N - CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N - CVSS 2.0
- 5.0 Medium
AV:N/AC:L/Au:N/C:P/I:N/A:N - Weakness
- CWE-209
- Updated
- 2026-11-02
OSV
Dev error stack trace leaking into prod in Play Framework
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.
- Record
CVE-2022-31023- CVSS 3.1
- 5.9 Medium
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N - Weakness
- CWE-209
- Updated
- 2026-11-02
OSVGHSA-p9p4-97g9-wcrh
Dev error stack trace leaking into prod in Play Framework
Impact
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.
Patches
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.
Workarounds
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 your application is not using the DefaultHttpErrorHandler static object in any code that may be run in production.
References
https://www.playframework.com/documentation/2.8.x/ScalaErrorHandling#Supplying-a-custom-error-handler https://www.playframework.com/documentation/2.8.x/JavaErrorHandling#Supplying-a-custom-error-handler
For more information
If you have any questions or comments about this advisory:
- Open an issue in playframework/playframework
- Email us at [email protected]
- Record
GHSA-p9p4-97g9-wcrh- CVSS 3.1
- 5.9 Medium
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N - Weakness
- CWE-209
- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
com.typesafe.play:play_2.12Maven |
before 2.8.16 | 2.8.16 |
com.typesafe.play:play_2.13Maven |
before 2.8.16 | 2.8.16 |
com.typesafe.play:play_2.12Maven |
before 2.8.16, plus listed versions 2.6.02.6.0-M12.6.0-M22.6.0-M32.6.0-M4 Show 45 moreShow less2.6.0-M52.6.0-RC12.6.0-RC22.6.12.6.102.6.112.6.122.6.132.6.142.6.152.6.162.6.172.6.182.6.192.6.22.6.202.6.212.6.222.6.232.6.242.6.252.6.32.6.52.6.62.6.72.6.92.7.02.7.0-M12.7.0-M22.7.0-M32.7.0-M42.7.0-RC32.7.0-RC42.7.0-RC52.7.0-RC82.7.0-RC92.7.12.7.22.7.32.7.42.7.52.7.62.7.72.7.82.7.9 |
2.8.16 |
com.typesafe.play:play_2.13Maven |
before 2.8.16, plus listed versions 2.7.32.7.42.7.52.7.62.7.7 Show 29 moreShow less2.7.82.7.92.8.02.8.0-M22.8.0-M32.8.0-M42.8.0-M52.8.0-M62.8.0-RC12.8.0-RC22.8.0-RC42.8.0-RC52.8.12.8.102.8.112.8.122.8.132.8.142.8.152.8.22.8.32.8.42.8.52.8.62.8.72.8.82.8.8-RC12.8.92.8.9-RC1 |
2.8.16 |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2022-31023 is a medium vulnerability (CVSS 5.9) in Lightbend Play Framework, published June 2, 2022. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 1.35%, the 71st percentile. Fixed in com.typesafe.play:play_2.12 2.8.16.
References
github.com/playframework/playframework/releases/tag/2.8.16
nvd.nist.gov/vuln/detail/CVE-2022-31023
Left out here: 28 versions. The JSON record has them.