GHSA-5gvw-p9qm-jgwh
MEDIUMjackson-databind: @JsonView ypassed for @JsonUnwrapped container properties on deserialization
Blast Radius
com.fasterxml.jackson.core:jackson-databind☕tools.jackson.core:jackson-databind☕com.fasterxml.jackson.core:jackson-databind☕com.fasterxml.jackson.core:jackson-databind☕tools.jackson.core:jackson-databindReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
UnwrappedPropertyHandler.processUnwrapped() replays the buffered JSON for a @JsonUnwrapped property by iterating its properties and calling prop.deserializeAndSet() with no prop.visibleInView(ctxt.getActiveView()) guard — the exact guard processUnwrappedCreatorProperties() received in the #5971 / GHSA-rcqc-6cw3-h962 fix, and the guard BeanDeserializer.deserializeWithUnwrapped applies to directly-matched properties. As a result, a property annotated with both @JsonView(PrivilegedView.class) and @JsonUnwrapped is written from attacker JSON even when deserializing under a more-restrictive active view.
Correction to the original framing (runtime-verified): the gap is NOT a per-field inner @JsonView (the unwrapped sub-object's own BeanDeserializer gates inner fields correctly). The unchecked gate is the view of the unwrapped CONTAINER property.
Intent proof (runtime, 2.x HEAD 21dd70dd and 3.x HEAD 7a5939d6)
An @JsonView(AdminView) property that is NOT @JsonUnwrapped → null under PublicView (correctly gated). The identical property WITH @JsonUnwrapped → fully populated (bypass). The fix the creator path already received, not applied to the regular-property method.
Impact — write-side mass-assignment / privilege escalation
@JsonView is commonly used as a write-side authorization guard: a public endpoint binds the body under readerWithView(PublicView.class) and groups privileged state in a nested object whose container property is @JsonView(AdminView). When that property is @JsonUnwrapped, an untrusted caller mass-assigns it. PoC: a self-service registration where AccountFlags{role,approved,creditBalance} is @JsonView(AdminView) @JsonUnwrapped; attacker JSON {role:ADMIN,approved:true,creditBalance:1000000} under PublicView binds all three → approved admin with arbitrary balance. The failing gate is a WRITE gate, hence integrity-high (C:N/I:H/A:N); no worse than the C:L/I:L parent and arguably higher as @JsonView-as-write-guard is the exact use case #5971/#5969 defended.
Affected
com.fasterxml.jackson.core:jackson-databind2.x: confirmed bypass at 21dd70dd (== released 2.21.4 / 2.22.0 line; includes the #5973 backport).DEFAULT_VIEW_INCLUSIONdefault=true.tools.jackson.core:jackson-databind3.x: confirmed bypass at HEAD 7a5939d6 (latest 3.x).DEFAULT_VIEW_INCLUSIONdefault=false → the stock-config repro is the common shape where privileged inner fields are individually@JsonView(PublicView)and the developer relies on the container@JsonView(AdminView); the 3.x PoC mass-assigns role/approved/creditBalance under PublicView. (The other simultaneous report's PoC was reportedly fixed on 3.x; this distinct container-property path is not.)
Additive variants (runtime-confirmed both branches; all closed by the same one-line guard)
- nested
@JsonUnwrapped(unwrapped-in-unwrapped) — recursive bypass. - merge /
readerWithView(...).withValueToUpdate(...)(PATCH/partial-update) — bypass; non-unwrapped merge control gates correctly. - builder-based deserializer (
@JsonDeserialize(builder=...)) —BuilderBasedDeserializerroutes through the sameprocessUnwrapped. - Honest non-findings: read-side serialization correctly honors views (no leak);
@JsonAnySetter+view and@JsonTypeInfo+@JsonUnwrappedare separate/unsupported behaviors, not this bug.
Fix
Add prop.visibleInView(ctxt.getActiveView()) (when MapperFeature.DEFAULT_VIEW_INCLUSION/active-view applies) to the processUnwrapped() property loop, mirroring processUnwrappedCreatorProperties(). One change closes the impact PoC + all three variants across BeanDeserializer and BuilderBasedDeserializer. Full runnable PoCs (2.x + 3.x) + variant harnesses available on request.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | com.fasterxml.jackson.core:jackson-databind | ≥ 2.21.0&&< 2.21.5 | 2.21.5 |
| ☕Maven | tools.jackson.core:jackson-databind | ≥ 3.0.0&&< 3.1.5 | 3.1.5 |
| ☕Maven | com.fasterxml.jackson.core:jackson-databind | ≥ 2.18.0&&< 2.18.9 | 2.18.9 |
| ☕Maven | com.fasterxml.jackson.core:jackson-databind | ≥ 2.22.0&&< 2.22.1 | 2.22.1 |
| ☕Maven | tools.jackson.core:jackson-databind | ≥ 3.2.0&&< 3.2.1 | 3.2.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for com.fasterxml.jackson.core:jackson-databind. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update com.fasterxml.jackson.core:jackson-databind to 2.21.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5gvw-p9qm-jgwh is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-5gvw-p9qm-jgwh is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-5gvw-p9qm-jgwh. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-5gvw-p9qm-jgwh in your dependencies?
O3 detects GHSA-5gvw-p9qm-jgwh across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.