PT0-002 Vulnerability Discovery and Analysis Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Accepting serialized objects from user input without sanitization

  Why this is correct

  The application's deserialization endpoint accepts a raw byte stream from the client and reconstructs objects without any validation or integrity check. An attacker can craft a malicious serialized payload containing a 'gadget chain' of existing library classes, causing the JVM to execute arbitrary commands during object reconstruction. Sanitizing the raw bytes or validating the incoming object's class hierarchy is essential; without it, the attack surface is fully exposed.

• ✗

  Use of eval() functions

  Why it's wrong here

  Using eval() methods (such as javax.script.ScriptEngine.eval() or expression-language evaluators) executes dynamically constructed strings as code, enabling command/expression injection if attacker-controlled input reaches it. However, this is an injection/RCE vulnerability in its own right, not an insecure deserialization flaw; it does not involve converting a serialized object graph back into live Java objects. The question specifically targets deserialization, so eval() is a wrong choice.

• ✗

  Hardcoded credentials in configuration files

  Why it's wrong here

  Storing hardcoded credentials in configuration files is a secrets-management issue: it exposes passwords or API keys to anyone with file access, and stolen credentials can be leveraged directly against production systems. While serious, this vulnerability has no connection to Java object deserialization or how the application processes untrusted input streams. The appropriate remediation would involve secure secret storage or environment variables, not serialization filtering.

• ✗

  Use of prepared statements for SQL queries

  Why it's wrong here

  Using prepared statements for SQL queries is a textbook defensive measure that parameterizes input and prevents SQL injection by separating SQL logic from user data. This behavior is secure and encouraged, as it eliminates the possibility of arbitrary query manipulation. Prepared statements have nothing to do with object input handling, so they neither cause nor reveal a deserialization weakness; thus this option is incorrect.

• ✓

  Use of ObjectInputStream without validation

  Why this is correct

  When code calls readObject() on an ObjectInputStream fed by untrusted data, the JVM instantiates the class named in the stream and executes any custom readObject() methods or field setters it contains, potentially triggering gadget chains. Without a class allowlist or an ObjectInputFilter, the stream can specify dangerous classes that chain into remote code execution. This is the low-level API manifestation of the same deserialization flaw, making it a correct answer.

Go deeper

Related to this question