Object injection

What it means

Serialisation turns an object in memory into text or bytes so it can be stored or sent, and deserialisation turns it back into an object. Object injection is what happens when an attacker controls that data, so your app rebuilds objects they designed, with values they chose.

The danger is that rebuilding an object can run code. Some classes do work automatically when they are created, changed or destroyed. By picking which classes appear and what they hold, an attacker can steer that work toward something your developers never intended.

Why it matters

The worst outcome is remote code execution, where the attacker runs commands on your server. Lesser outcomes include deleting files, reading data, bypassing a sign-in check or crashing the service. Because the payload looks like ordinary data, it can pass checks that look only for obvious attack strings.

It is one of the main ways the broader weakness of insecure deserialisation turns into a real break-in. It matters most in older code, plugins and anything that accepts a serialised value from a cookie, form field or API. Updating libraries is part of the defence, since attacks reuse classes they already contain.

How it shows up

You meet it where an app reads a serialised object from a place the user controls: a cookie that stores a session object, a hidden field, a message queue, a cache entry or an uploaded file. PHP, Java, .NET and Python all have native formats that can be abused when they accept untrusted data.

The safest fix is not to deserialise untrusted data in those native formats at all. Use plain data formats such as JSON with a fixed schema, sign and verify any value you must round-trip through the client, and keep libraries patched, since attacks often chain classes already present in them.