Command injection and insecure deserialization explained
Learn how untrusted input can change system commands or unsafe object reconstruction, and how to reduce the risk.
Applications commonly pass data to other software and reconstruct saved data. Problems arise when untrusted data is interpreted as instructions or is used to create objects with unsafe behavior. Command injection and insecure deserialization are different weaknesses, even though either can sometimes lead to code execution.
## What is command injection?
Operating-system command injection occurs when an application builds or invokes a system command using externally influenced input and that input changes what the command does. For example, a service that builds a shell command by combining a fixed program name with a user-supplied filename may allow input to be interpreted as shell syntax instead of a filename. Impact depends on the command, environment and permissions; not every unsafe input leads to a successful attack. [OWASP's command injection guidance](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html) describes this boundary.
Prefer a library or platform API that performs the intended operation without a shell. When a separate process is necessary, choose a fixed executable and pass arguments separately through a suitable process API. Validate each permitted value for the specific program, apply length and format limits, and control options and destinations. Argument separation avoids shell parsing when a shell is not invoked, but it does not stop an argument from being interpreted as an option or otherwise misused by the called program. Do not assume quoting alone validates a path, URL or destination.
## What is deserialization?
Serialization turns data or object state into a representation that can be stored or transmitted; deserialization reconstructs data or objects from that representation. This is an ordinary programming operation. Insecure deserialization occurs when an application reconstructs objects from untrusted input in a way that allows unsafe behavior or changes application logic. The result can include denial of service, unauthorized actions or, in some environments, code execution; the result depends on the serializer, available classes and application behavior.
For example, a service may accept a saved object supplied by a client and restore it using a mechanism that invokes application behavior during reconstruction. If the client can alter the representation, simply treating the result as a normal application object can cross a trust boundary. A signature can help detect tampering only when its key, verification and trust assumptions are sound; it does not make a dangerous parser safe for arbitrary input.
Avoid deserializing untrusted inputs with mechanisms that instantiate arbitrary objects or execute code. Where suitable, use a data-only format and a parser configured for untrusted input, validate the resulting structure and business rules, and apply size and nesting limits. JSON is not a universal guarantee: unsafe type handling or later interpretation of parsed values can still introduce vulnerabilities. Review [OWASP's deserialization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) for the relevant language and library.
## How do they relate to RCE and other injection?
Remote code execution (RCE) is a possible impact; command injection and unsafe deserialization describe different ways an application may reach an unsafe state. Neither weakness guarantees RCE, and RCE can have other causes. SQL injection concerns the interpretation of data as database instructions; cross-site scripting concerns attacker-controlled script running in a browser context. The correct control depends on the interpreter and trust boundary. See [our XSS and CSRF guide](https://blog.mithril.fund/cross-site-scripting-xss-vs-csrf?lang=en).
## Practical review
Identify entry points and whether data comes from an authenticated user, third party, stored record or another service. Trace that data to process execution and deserialization calls, replace unsafe interfaces where possible, verify arguments and object types against explicit expectations, and test rejection paths. Restrict process privileges and isolate sensitive operations as defense in depth. Record affected versions and review logs when investigating suspected exploitation. Sources reviewed on 2026-10-30.