Have seen Jackson in parts of my code base (internal, but still)
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
As Jackson is used in Spring, you can assume most banks, big corporations, etc. use it. So, update your dependencies and it's fine.
Gson is kind of to be avoided for the simple reason that it seems to be no longer maintained by Google. I've used it in the past and its fine but wouldn't pick it for something new because of this.
If you are using Kotlin, kotlinx serialization is worth a look. I've been using that recently. One of the nice things is that it relies on compiler plugins and code generation rather than a lot of reflective magic at runtime. From a security and performance point of view, that's a good thing.
It could use some simplified syntax (similar to how Kotson improved on Gson), perhaps a JPath parser. But for something that just went 1.0 very recently, it is terrific.
One rotten egg I can spot: "Supported subset of Jackson". Ow. Jackson is unfortunately a land mine, rattled with CVEs over the years. This was mostly fixed by taking the best ideas from Jackson and standardizing them as JsonB, which not have several good implementations. I would highly suggest they drop Jackson support in flavor of JsonB just so the Jackson libs don't have to be on anyones class path.