Get Started
- CodeAnt AI
- Setup
- Control Center
- Pull Request Review
- IDE
- Compliance
- Anti-Patterns
- Code Governance
- Infrastructure Security Database
- Application Security Database
- Apex
- Bash
- C
- Clojure
- Cpp
- Csharp
- Dockerfile
- Elixir
- Fingerprints
- Generic
- Go
- Html
- Java
- Android
- Aws-lambda
- Castor
- Java-jwt
- Jax-rs
- Jboss
- Jdo
- Jedis
- Jjwt
- Jsch
- Kryo
- Lang
- Audit
- Classloader-object-deserialization
- Correctness
- Security
- Security
- Micronaut
- Mongo
- Mongodb
- Mysql
- Okhttp
- Rmi
- Servlets
- Spring
- Thymeleaf
- Xstream
- Javascript
- Json
- Kotlin
- Ocaml
- Php
- Problem-based-packs
- Python
- Ruby
- Rust
- Scala
- Solidity
- Swift
- Terraform
- Typescript
- Yaml
Classloader object deserialization
The application may convert user-controlled data into an object, which can lead to an insecure deserialization vulnerability. An attacker can create a malicious serialized object, pass it to the application, and take advantage of the deserialization process to perform Denial-of-service (DoS), Remote code execution (RCE), or bypass access control measures. To prevent this vulnerability, leverage data formats such as JSON or XML as safer alternatives. If you need to deserialize user input in a specific format, consider digitally signing the data before serialization to prevent tampering. For more information, see: Deserialization prevention We do not recommend deserializing untrusted data with the ObjectInputStream. If you must, you can try overriding the ObjectInputStream#resolveClass() method or using a safe replacement for the generic readObject() method.
Likelihood: MEDIUM
Confidence: LOW
CWE:
- CWE-502: Deserialization of Untrusted Data
OWASP:
- A08:2017 - Insecure Deserialization
- A08:2021 - Software and Data Integrity Failures