When data crosses into a system that interprets structure, without being constrained or transformed, it becomes executable.
Serialized data is deserialized into live objects with side effects before validation
If user input appears inside a query, command, template, object stream, or prompt without an intermediate representation that separates data from structure — you are not passing data. You are modifying structure.
Every new execution context recreates this pattern. SQL gave way to NoSQL, HTML to templates, cookies to JWTs, forms to APIs, prompts to agents. The language changes. The failure does not.
Both allow untrusted input to become executable — one through string concatenation, one through object instantiation
Deserialization trusts object structure. LLMs trust prompt structure. Both execute attacker-controlled instructions disguised as data
Year
2011–2019
Context
Enterprise Java ruled the backend. Applications serialized objects for caching, messaging (JMS), session persistence, and RPC. The serialization format was binary, opaque, and trusted implicitly. When data arrived as a serialized object, the application deserialized it — instantiating real objects with real side effects — before any validation could occur. The attacker's payload wasn't data. It was executable code, packaged as an object.
Who Built This
Enterprise Java developers building SOA architectures, message queues, and distributed caching. The frameworks — Apache Commons Collections, Spring, WebLogic, JBoss — provided the building blocks. Nobody realized those building blocks could be weaponized.
Threat Model at Time
Firewalls. Input validation on form fields. SQL injection prevention. Nobody modeled the serialized object stream as an attack surface because it was "internal" — between services, not from users.
Why It Made Sense
Java serialization was built into the language. ObjectInputStream was in the standard library. It was how you stored objects, sent them between JVMs, persisted sessions. The alternative — manually converting every object to a safe format — felt like unnecessary overhead.
This pattern has been found in applications built by talented developers at respected organizations across every decade of software history. Its presence in a codebase is not a reflection of the developer who wrote it — it is a reflection of what that developer was taught, what tools they had, and the path that was easiest given what they were taught. The goal is not to find fault. The goal is to find the pattern — before it finds you.
Katie's Law: The developers were not wrong. The shortcut was not wrong. The context changed and the shortcut didn't.