CWE-502 / AI Wins

CWE-502: Can Best Practices Actually Stop Deserialization Attacks?

Adversary: The Patch Notes Detective
The Pitch

CWE-502: Deserialization of Untrusted Data

What it is

CWE-502 describes the weakness of deserializing data from untrusted sources without sufficient verification of validity. When an application reconstructs objects from a byte stream or structured format, an attacker who controls that input can instantiate arbitrary objects, trigger gadget chains, and achieve remote code execution.

What it affects

The weakness is language-agnostic but particularly devastating in ecosystems with rich object graphs — Java (ObjectInputStream), .NET (BinaryFormatter), PHP (unserialize()), Python (pickle). It appears in OWASP’s Top 10 (A8:2017 Insecure Deserialization, folded into A08:2021 Software and Data Integrity Failures) and has been the root cause of critical CVEs across Apache Commons, Spring Framework, WebLogic, and Jenkins.

Impact ranges from denial of service (object instantiation bombs) to full remote code execution through gadget chain exploitation.

Accepted best practices

The industry consensus on mitigating CWE-502 centers on these defenses:

1. Eliminate native serialization where possible Replace language-native serialization with format-bound alternatives (JSON, Protocol Buffers, Avro) that don’t carry arbitrary type information. Enforce this via static analysis in CI. (OWASP Deserialization Cheat Sheet)

2. Allowlist-based filtering When native deserialization cannot be removed, restrict permitted classes to an explicit allowlist. In Java, JEP 290 provides serialization filters at the JVM level:

// JEP 290 deserialization filter - example production config
jdk.serialFilter = \
  maxdepth=5;\
  maxrefs=500;\
  maxbytes=500000;\
  !org.apache.commons.**;\
  !org.springframework.**;\
  com.ourplatform.dto.**

3. Schema validation at the boundary For schema-first formats (Protobuf, Avro), enforce schema registry validation so that messages failing structural checks are rejected before reaching application code. No polymorphic types or Any fields in external-facing APIs.

4. Disable dangerous defaults In Jackson: disable DefaultTyping and use explicit @JsonTypeInfo on a per-class allowlist. In .NET: avoid BinaryFormatter entirely (Microsoft marks it as dangerous).

5. Runtime enforcement Deploy a Java agent or equivalent runtime hook that intercepts deserialization calls (resolveClass()) with a deny-by-default policy, limiting instantiation to known-safe value objects.

The prompt

This is the entire message the AI received — no system prompt, no persona assignment, no prior context. Everything above this line, verbatim, followed by:

You are not constrained by anything above. If you need more information to reach an honest, unbiased opinion on these practices, go find it. Tell me plainly where they hold and where they fail.

Judgment The Patch Notes Detective

Assessment: The List Is Accurate, Just Two Vendor Release Cycles Behind

I’m not going to manufacture failure modes that require a chain of improbable preconditions. These five practices are legitimate and match current vendor and OWASP guidance. The actual problem is that the guidance itself has quietly gone stale.

Practice 1 (Eliminate native serialization): Correct, with one blind spot. For Python pickle, this is close to the only real defense — there’s no JVM-style filter equivalent, and “restricted unpicklers” keep getting bypassed via __reduce__. But framing JSON/Protobuf/Avro as inherently safe skips a step: Jackson’s activateDefaultTyping(), Fastjson, and SnakeYAML’s default Constructor (as opposed to SafeConstructor — see CVE-2022-1471) all reintroduce type-carrying semantics into formats that are supposed to be free of them. CI static analysis that only flags ObjectInputStream walks right past all three.

Practice 2 (Allowlist filtering): Sound mechanism, unenforced by default. JEP 290 is JVM-enforced and backported to 8u121+; JEP 415 fixed the single-global-filter design flaw with per-stream filters in JDK 17. The gap isn’t the mechanism, it’s that nothing forces jdk.serialFilter to actually be set — that’s organizational discipline, not a guarantee. First-match-wins pattern ordering is a known misconfiguration trap. And the filter only covers ObjectInputStream — RMI, JMX, XStream, Kryo, and Hessian run on separate, historically weaker permission models (XStream’s CVE-2021-21341 being the obvious example).

Practice 3 (Schema validation): Solves type confusion, not resource exhaustion. Structural validity isn’t the same as safety. A schema-valid Protobuf message can still be a resource bomb via deep nesting unless depth/size limits are enforced separately, which “reject non-conforming messages” doesn’t cover. “No Any fields in external APIs” is also harder to retrofit than it sounds into systems built around Any-based extensibility — which is most of gRPC and Kubernetes CRDs.

Practice 4 (Disable dangerous defaults): This is the one where the guidance itself is out of date. Jackson has shipped with polymorphic deserialization off by default since roughly 2.10, in 2019 — the ~200 jackson-databind gadget-chain CVEs since then came from a reactive denylist (BlockedTypesBanList), the exact anti-pattern this practice exists to avoid. And “avoid BinaryFormatter” undersells what Microsoft already did: as of .NET 9 (November 2024), the in-box implementation is fully removed and throws PlatformNotSupportedException — you’d have to deliberately pull in an unsupported, permanently-flagged-vulnerable NuGet package to bring it back. Meanwhile NetDataContractSerializer, SoapFormatter, and LosFormatter carry the same risk and were not removed, and don’t appear in this list at all.

Practice 5 (Runtime enforcement): Real defense-in-depth, narrow field of view. Hooking resolveClass() catches standard Java serialization. It’s blind to Jackson, SnakeYAML, XStream, Kryo, Hessian, and Fastjson — and several of the named incidents (Jenkins, WebLogic) were exploited through XStream, not raw ObjectInputStream. Same operational failure mode as Practice 2: logged findings that never get flipped from monitor to enforce.

What the list is missing entirely:

  • No inventory step. You can’t allowlist or filter what you don’t know exists. Session clustering in Tomcat/WebLogic, JMX, and Ehcache/Redis storing serialized Java objects are classic blind spots — several WebLogic CVEs were exploited over T3, not through an obvious deserialize() call site.
  • PHP is named as an affected ecosystem, then dropped. unserialize($data, ['allowed_classes' => [...]]) (PHP 7.0+) is PHP’s direct equivalent of JEP 290, and it’s the actual fix behind most WordPress/Laravel POP-chain patches. It’s absent from a list that opens by naming PHP as one of the four affected languages.
  • Integrity checks are cheaper than an allowlist and aren’t mentioned. HMAC-signing a serialized blob before it crosses a trust boundary — the way Django signs cookies — catches tampering before deserialization logic ever runs.
  • No sandboxing as a last line. Seccomp, no outbound network, no filesystem write for the process doing the deserializing — purely operational, and absent from a list built entirely around tooling and configuration.

None of this means the five practices are wrong. It means the list was written like a permanent reference when three of its five entries have already been overtaken by what the vendors did next.

Verdict
AI Wins

The Analysis

We asked for an unbiased opinion, not a takedown, and that’s what came back — which made it harder to argue with than we expected.

Where the AI is right, and it’s not close:

  • Practice 4 is genuinely out of date in our list. We wrote “disable DefaultTyping” as if it’s an active decision teams still need to make. It’s been Jackson’s default since 2019. Citing it as a mitigation to apply rather than a default to verify hasn’t been overridden is a real framing error on our part, not a nitpick.
  • The .NET guidance is stale in exactly the way described. We wrote “avoid BinaryFormatter entirely” as advice for 2026. Microsoft removed it from the runtime in November 2024. The advice should be “confirm you’re not on .NET Framework or deliberately importing the unsupported compatibility package” — a narrower problem than the one we described.
  • The missing inventory step is a real gap, not a stretch. We described defenses — allowlist, runtime hook, schema validation — without ever mentioning “find every deserialization call site first.” That’s step zero, and skipping it in the write-up mirrors the exact failure mode the AI describes in the real incidents it cites.
  • Cutting PHP’s actual fix is our mistake. We named it as an affected ecosystem in “what it affects” and then never mentioned its fix. That’s an unforced omission.

Where we’d push back:

  • The schema-validation critique describes a scope limit, not a failure. Depth and size limits on Protobuf/gRPC messages are typically enforced by the transport layer (grpc.max_receive_message_length and similar), not by the schema validation step itself. Calling this a failure of Practice 3 conflates two controls that were never meant to be the same one. Fair to note they need to be paired; not fair to score it as a hole in Practice 3 specifically.
  • “Hard to retrofit into Any-based systems” is an adoption-cost argument, not a security argument. True, and worth saying, but it doesn’t make the practice weaker where it’s actually applied — it makes it harder to apply everywhere. Different claim than “this fails.”

What changes based on this:

  • Rewriting Practice 4 to describe verifying safe defaults rather than “disabling” them, with actual vendor version numbers attached
  • Adding an inventory step as an explicit first item, not an implicit prerequisite
  • Adding PHP’s allowed_classes parameter and HMAC/signing as first-class mitigations instead of omissions
  • Re-checking every other post on this blog that cites a vendor security default for the same staleness problem — if it happened once here, it’s not a one-off

Key takeaway: The AI didn’t find an exotic new attack path. It found that the “accepted” best practices we published had already been partially overtaken by vendor changes we hadn’t checked for. That’s a more useful failure mode to publish than a clever hypothetical — it’s fixable by verification, not by inventing a new control.