Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@mkurz
Copy link
Member

@mkurz mkurz commented Oct 9, 2025

Just like Jackson 2.15+ we restrict the maximum allowed number of nested arrays or objects (or mixed) to 1000. Currently this limit is hardcoded, unlike Jackson, which allows to configure it. (we have sys property now, just like in the main branch as of #1072) 1000 should be enough for most real world use cases. We can still make it configurable later.

Note this is about OutOfMemoryError's, not about StackOverflowError's. StackOverflowError's are not a problem since we use a @tailrec optimized method. Therefore this fix is not 100% about CVE-2025-52999 (which in theory we do not run into) but just an additional precaution.

See

@mkurz mkurz force-pushed the avoid_OutOfMemoryError_nesting_2.10.x branch 2 times, most recently from a1066a5 to 73d4ba8 Compare October 10, 2025 07:36
throw new RuntimeException("We should have been reading an object, something got wrong")
}

val defaultMaxDepth = 1000 // Same as Jackson's 2.15+ StreamReadConstraints.DEFAULT_MAX_DEPTH
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fyi, in Play itself we cap the depth for json form handling at just 64: https://github.com/playframework/playframework/blob/3.0.9/core/play/src/main/scala/play/api/data/Form.scala#L375-L381
So I guess 1000 should absolutely not be a problem.


val defaultMaxDepth = 1000 // Same as Jackson's 2.15+ StreamReadConstraints.DEFAULT_MAX_DEPTH
// system property to override the max nesting depth for JSON parsing.
val maxNestingDepth: String = "play.json.parser.maxNestingDepth"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We introduced the same sys property in the main branch's pr when we upgraded jackson to 2.19: https://github.com/playframework/play-json/pull/1072/files

…ects

Just like Jackson 2.15+ we restrict the maximum allowed number of nested arrays or
objects (or mixed) to 1000. This default can be changed via a sys property.
1000 should be enough for most real world use cases.
Note this is about OutOfMemoryError's, not about StackOverflowError's.
StackOverflowError's are not a problem since we use a @tailrec optimized
method. Therefore this fix is not 100% about CVE-2025-52999 (which in
theory we do not run into) but just an additional precaution.
@mkurz mkurz force-pushed the avoid_OutOfMemoryError_nesting_2.10.x branch from 73d4ba8 to 90ad9c3 Compare October 10, 2025 07:53
@mkurz mkurz merged commit 9722c66 into playframework:2.10.x Oct 10, 2025
5 of 6 checks passed
@mkurz mkurz deleted the avoid_OutOfMemoryError_nesting_2.10.x branch October 10, 2025 07:53
@mkurz
Copy link
Member Author

mkurz commented Oct 10, 2025

@Mergifyio backport main 3.0.x

@mergify
Copy link
Contributor

mergify bot commented Oct 10, 2025

mergify bot pushed a commit that referenced this pull request Oct 10, 2025
…ects (#1226)

Just like Jackson 2.15+ we restrict the maximum allowed number of nested arrays or
objects (or mixed) to 1000. This default can be changed via a sys property.
1000 should be enough for most real world use cases.
Note this is about OutOfMemoryError's, not about StackOverflowError's.
StackOverflowError's are not a problem since we use a @tailrec optimized
method. Therefore this fix is not 100% about CVE-2025-52999 (which in
theory we do not run into) but just an additional precaution.

(cherry picked from commit 9722c66)
mergify bot pushed a commit that referenced this pull request Oct 10, 2025
…ects (#1226)

Just like Jackson 2.15+ we restrict the maximum allowed number of nested arrays or
objects (or mixed) to 1000. This default can be changed via a sys property.
1000 should be enough for most real world use cases.
Note this is about OutOfMemoryError's, not about StackOverflowError's.
StackOverflowError's are not a problem since we use a @tailrec optimized
method. Therefore this fix is not 100% about CVE-2025-52999 (which in
theory we do not run into) but just an additional precaution.

(cherry picked from commit 9722c66)
mkurz added a commit that referenced this pull request Oct 10, 2025
…ects (#1226) (#1228)

Just like Jackson 2.15+ we restrict the maximum allowed number of nested arrays or
objects (or mixed) to 1000. This default can be changed via a sys property.
1000 should be enough for most real world use cases.
Note this is about OutOfMemoryError's, not about StackOverflowError's.
StackOverflowError's are not a problem since we use a @tailrec optimized
method. Therefore this fix is not 100% about CVE-2025-52999 (which in
theory we do not run into) but just an additional precaution.

(cherry picked from commit 9722c66)

Co-authored-by: Matthias Kurz <[email protected]>
mkurz added a commit that referenced this pull request Oct 10, 2025
…ects (#1226)

Just like Jackson 2.15+ we restrict the maximum allowed number of nested arrays or
objects (or mixed) to 1000. This default can be changed via a sys property.
1000 should be enough for most real world use cases.
Note this is about OutOfMemoryError's, not about StackOverflowError's.
StackOverflowError's are not a problem since we use a @tailrec optimized
method. Therefore this fix is not 100% about CVE-2025-52999 (which in
theory we do not run into) but just an additional precaution.

(cherry picked from commit 9722c66)
mkurz added a commit that referenced this pull request Oct 10, 2025
…ects (#1226) (#1227)

Just like Jackson 2.15+ we restrict the maximum allowed number of nested arrays or
objects (or mixed) to 1000. This default can be changed via a sys property.
1000 should be enough for most real world use cases.
Note this is about OutOfMemoryError's, not about StackOverflowError's.
StackOverflowError's are not a problem since we use a @tailrec optimized
method. Therefore this fix is not 100% about CVE-2025-52999 (which in
theory we do not run into) but just an additional precaution.

(cherry picked from commit 9722c66)

Co-authored-by: Matthias Kurz <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant