fix(security): bump jackson to 2.22.1 [skip-runtime-e2e]

[saurabhjain1592]

Resolves the SDK half of getaxonflow/axonflow-enterprise#3110.

pom.xml pinned <jackson.version>2.17.0</jackson.version>, applied to jackson-databind and jackson-datatype-jsr310. jackson-core — the artifact the reported advisory is actually against — was never named, and arrived transitively at 2.17.0.

Reachability: not reachable from SDK code

The advisory named in the issue, GHSA-72hv-8253-57qq, is a non-blocking (async) parser defect. The SDK never uses that API.

Probe (over all 444 compiled classes in target/classes)	Result
createNonBlocking* / NonBlockingJsonParser / *Feeder	0 references
JsonFactory / createParser / createGenerator	0 references
activateDefaultTyping / enableDefaultTyping / PolymorphicTypeValidator / @JsonTypeInfo	0 references

Every JSON entry point is ObjectMapper.readValue / readTree / convertValue / writeValueAsString — blocking parsers only. The async parser must be constructed deliberately via JsonFactory.createNonBlockingByteArrayParser(); ObjectMapper never routes through it. Jackson is also the SDK's own dependency only — no other artifact on the compile classpath consumes it.

The same probe rules out the two High PTV advisories, which are the more serious finding: CVE-2026-54512 / CVE-2026-54513 require polymorphic typing to be enabled, and it never is.

So the bump is hygiene, not incident response. It still matters: the vulnerable jars land on the consumer's compile classpath, where the same Jackson is shared with application code that may well enable default typing or use the async parser. Our own platform examples already carry a local 2.22.1 override precisely because of this.

Advisories that matched the old pin

Confirmed by resolving each advisory's affected range against 2.17.0 via the GitHub Advisory API (not by trusting a scanner's summary):

Artifact	ID	Severity	Reachable here?
jackson-core	GHSA-r7wm-3cxj-wff9	High	No — async parser
jackson-core	GHSA-72hv-8253-57qq	Moderate	No — async parser
jackson-databind	CVE-2026-54512	High	No — needs polymorphic typing
jackson-databind	CVE-2026-54513	High	No — needs polymorphic typing
jackson-databind	CVE-2026-54514	Moderate	No — no InetSocketAddress deserialization
jackson-databind	CVE-2026-54515	Moderate	No — ACCEPT_CASE_INSENSITIVE_PROPERTIES is off
jackson-databind	CVE-2026-59888	Moderate	No — no Java records (Java 11 target)

jackson-datatype-jsr310 had no applicable advisories at 2.17.0.

This also confirms the issue's open question: the locally-reported CVE-2026-54512 / CVE-2026-54513 HIGHs do resolve against this pin.

Version choice: 2.22.1

Not simply "the newest". The affected ranges are per-line, so several plausible targets do not clear the set:

Candidate	Applicable advisories
2.18.9	0 — but a stale maintenance line
2.19.4	7 — still fully exposed
2.21.5	0
2.22.0	3 (incl. the High jackson-core one)
2.22.1	0

2.22.1 is the current Maven Central release for all three artifacts and is already the version the platform examples pin as their override, so this removes drift rather than adding it.

jackson-core is now declared explicitly so the published POM states a floor on the artifact that carries the advisories, instead of inheriting whatever jackson-databind happens to depend on. That is the structural defect that let a jackson-core advisory hide behind a jackson-databind pin for four majors.

Behavioural verification

A green suite alone would not catch a serialization-default change, so both versions were loaded into a real JVM against real SDK types and the outputs diffed. Byte-for-byte identical apart from the reported version numbers. Covered: @JsonInclude(NON_NULL) omission on AuditSearchRequest; Instant ISO-8601 serialization and parsing including nanosecond precision, offsets and epoch forms under WRITE_DATES_AS_TIMESTAMPS=false + READ_DATE_TIMESTAMPS_AS_NANOSECONDS=false; untyped Map<String,Object> number-type inference (Integer/Long/BigInteger/Double); FAIL_ON_UNKNOWN_PROPERTIES=false round-trip through @JsonCreator; coercion/case-sensitivity defaults; string escaping and non-ASCII; empty collection shapes; StreamReadConstraints defaults.

Jackson's bytecode baseline is unchanged (classfile major 52 = Java 8), so the SDK's Java 11 target is unaffected.

mvn verify: 1325 unit tests, 12 integration tests, 0 failures, jacoco gate met, jar + sources + javadoc all built.

Consumer-visible tree changes

• net.bytebuddy:byte-buddy drops off the compile classpath — jackson-databind 2.17.0 declared it, 2.22.1 does not. Still present at test scope via Mockito.
• jackson-annotations resolves to 2.22, not 2.22.1 — normal Jackson convention, that module is released at major.minor.

Follow-up, deliberately NOT in this PR

The 2.22.1 override pins in the platform repo (76 poms, incl. examples/wcp-retry-idempotency/{community,evaluation}/java/pom.xml) must be dropped only after this SDK version is published to Maven Central — reverting them earlier would reintroduce the exposure. Sequenced in #3110.

Skip-runtime-e2e justification

This PR changes no SDK source and no public API — it is a dependency-version bump plus an explicit re-declaration of an already-present transitive artifact. There is no new runtime surface for a runtime-e2e suite to exercise, and no existing suite's behaviour changes.

The runtime evidence that is meaningful for this class of change was produced instead: both Jackson versions were loaded into a real JVM against real SDK classes and their serialization/deserialization output diffed to byte equality (detailed above), and reachability was established from compiled bytecode rather than from source grep alone. mvn verify exercises the full unit + integration suite against the new dependency set.