Actually it isn't enough. you can check with running dependencyTree, you will see that when adding only jackson-module-scala it will pull in:

[info]   +-com.fasterxml.jackson.module:jackson-module-scala_2.13:2.13.4 [S]
[info]   | +-com.fasterxml.jackson.core:jackson-annotations:2.13.4
[info]   | +-com.fasterxml.jackson.core:jackson-core:2.13.4
[info]   | +-com.fasterxml.jackson.core:jackson-databind:2.13.4
[info]   | | +-com.fasterxml.jackson.core:jackson-annotations:2.13.4
[info]   | | +-com.fasterxml.jackson.core:jackson-core:2.13.4
[info]   | | 
[info]   | +-com.thoughtworks.paranamer:paranamer:2.8

but not jackson-datatype-jdk8, jackson-datatype-jsr310, jackson-dataformat-cbor, etc. - these will stay on the old version.
I recommend to explictily define all those depencies, like in the above comment.

libraryDependencies is the weaker form of an dependency override.

If a dependency in your project pulls Jackson 2.13, you have a libraryDependency with Jackson 2.14…

SBT should pick the 2.14, as it is the latest revision - with default conflict management.

But: In case of Jackson, all modules must be defined via libraryDependencies.

https://www.scala-sbt.org/1.x/docs/Library-Management.html#Conflict+Management

If a dependency pulls a higher revision than the one you defined via libraryDependencies, you must override with dependencyOverride.

Thus, if you have via libraryDependencies 2.14 and have e.g. logstash-logback-encoder in v7.4 which pulls 2.15… You will get 2.15 with the default conflict management as it is the highest revision.

With dependencyOverride SBT will forcefully override the version, performing an downgrade to 2.14 - despite logstash-logback-encoder pulling in the newer revision 2.15.

no CVE yet, apparently

There will never be a CVE because this "issue" is not a 'high' vulnerability.

published on 26th July 2024

This is not correct. If you look closer, the report was published on 8 Dec 2022 already, it's nothing new. If you look at the discussion in the jackson repo (FasterXML/jackson-core#861) you will find out that the jackson maintainers got a bit annoyed the this so called "disclosure". If I read this right, what happend is that a commit made it into jackson (FasterXML/jackson-core@3af7e3e), like total normal development, nothing special, to limit the sizes of numbers, then someone reported this as "vulnerability", which never was, because nothing was ever exploited in the wild. The fix never was intented to fix a vulnerability, the commit was done on Nov 29, 2022, the report was filed one week later on Dec 8, 2022. But of course everone got nervos when security alerts pop up...
IMHO you don't need to worry abou this report.

So the first version of Play that could contain Jackson 2.15 would be Play 3.1, given that Play is on v3.0.5 (and Jackson 2.14.3) at the moment?

Yes, plan is to upgrade to latest Jackson in the next upcoming release.
I know about the open PRs, they will be worked on.

@mkurz - thank you for that background, including the pointer to FasterXML/jackson-core#861 - much appreciated.