PT0-002 Practice Question: A penetration tester discovers a web application…

Answer analysis

Option-by-option breakdown

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

• ✗

  The application must be running with root privileges

  Why it's wrong here

  The application's effective user ID determines the privilege level of the spawned process, but Java deserialization exploits operate entirely within the JVM's security context. Although root would expand the blast radius of a successful exploit, the gadget chain triggers code execution with whatever privileges the JVM runs under—typically the web application's service account. Requiring root is a common misconception because many believe OS-level privilege escalation is necessary, but the deserialization vulnerability itself is a logic flaw in the application's object instantiation, independent of the OS account. Thus, an unprivileged JVM can still be fully compromised, making root a condition that increases impact, not a prerequisite for exploitation.

• ✗

  The application must use a custom ClassLoader

  Why it's wrong here

  A custom ClassLoader is an advanced Java mechanism used to load classes from non-standard sources, but it is not needed for deserialization-based code execution. The attack leverages classes already present on the application's classpath, which are loaded by the default system ClassLoader (AppClassLoader) or the application's existing loaders. The exploit chain constructs a serialized stream that causes the JVM to instantiate and invoke methods on those existing classes, such as those in Apache Commons Collections, without any custom loading logic. Therefore, requiring a custom ClassLoader confuses the deployment environment with the attack's dependency on available gadget classes; the attacker only needs the default class loading to resolve the gadget chain.

• ✓

  The Java runtime must have a gadget chain available in its classpath

  Why this is correct

  The correct precondition for a successful Java deserialization attack is the presence of one or more gadget chains—sequences of existing classes with methods that, when invoked through crafted serialized objects, perform dangerous operations like executing commands. These chains are typically found in popular third-party libraries such as Apache Commons Collections, Commons Beanutils, or Spring, which are on the application's classpath (including nested JARs or dependency directories). The runtime must be able to resolve these classes when the serialized stream triggers their methods; without them, the deserializer may only throw exceptions or create benign objects. This is why the classpath composition is the decisive factor, not OS-specific behavior, and why penetration testers aggressively enumerate dependencies to identify exploitable gadget libraries.

• ✗

  The application must be running on a Windows operating system

  Why it's wrong here

  Java's deserialization vulnerability is platform-independent because the JVM abstracts the underlying operating system, and gadget chains rely purely on Java class loading and method invocation. The same malicious serialized payload can execute on Windows, Linux, or macOS as long as the required library classes are present. OS-specific details like file paths or shell syntax are handled within the gadget chain itself (e.g., using Runtime.exec with a command string), but the deserialization mechanism does not depend on Windows APIs or process management. Thus, assuming Windows is necessary is a false heuristic; the attack surface is determined by the Java application's dependencies, not the host OS.

Go deeper

Related to this question