Look for RPC requests that contain encoded values beginning with rO0, which indicates Java serialization data, and check whether the application uses enhanced classes in GWT-RPC. Strong-name policy files can also reveal the classes involved. If payload substitution produces deserialization-related errors instead of a clean reject, that often signals the endpoint is still parsing serialized object data.
What makes a GWT-RPC endpoint look suspicious during testing?
The first clue is not the framework itself, but the wire format. If a request contains values that decode to Java serialization, especially the familiar rO0 prefix, the endpoint may still be accepting serialized object data rather than rejecting it outright. That matters because GWT-RPC can carry server-side type information, and a weak reject path often reveals more than a normal response would.
Enhanced classes in GWT-RPC are another useful indicator because they can expand what the server expects to deserialize. If the request structure changes when you vary the payload, rather than failing cleanly, you may be probing an endpoint that still performs Java object handling deeper in the stack. Strong-name policy files can also help you identify the classes involved and narrow the test surface.
A practical sign is the difference between an application that blocks tampered input and one that returns deserialization-specific errors. If payload substitution yields parser, type, or serialization exceptions instead of a hard reject, that suggests the server is still reaching deserialization logic. In that case, the endpoint should be treated as potentially exposed until proven otherwise.
What request behaviour best indicates unsafe Java deserialization risk?
The strongest indicator is not a single payload string on its own, but a pattern of acceptance. Look for requests that appear to carry serialized Java objects, then test whether the application distinguishes safe GWT-RPC traffic from substituted or malformed content. If the server reflects deserialization failures, attempts to coerce the object stream are likely reaching code that should never be exposed to untrusted input.
That behaviour is important because unsafe deserialization risk is usually confirmed through response quality, not just request shape. A clean, intentional rejection means the parser stopped early. A deserialization error means the application may be parsing the stream, which creates a path for gadget-based abuse if the runtime and classpath are compatible.
Strong-name policy metadata can add precision here by showing which classes are permitted or expected. When the policy exposes more than a narrow set of safe types, or when enhanced classes broaden the surface, the application may be relying on type expectations instead of truly eliminating deserialization risk.
Which supporting clues help you confirm the finding without overcalling it?
Use multiple clues together. Encoded serialization markers, class-policy references, and error behaviour should line up before you conclude the endpoint is still vulnerable. A single odd response can be a false positive, but repeated deserialization-related exceptions across small payload changes are harder to dismiss.
It also helps to separate transport quirks from actual object handling. Some GWT applications encode data without being vulnerable, so the key question is whether the server is still interpreting attacker-controlled bytes as Java objects. If the endpoint accepts, transforms, or partially processes substituted payloads, that is more informative than a generic HTTP error page.
When you find a likely exposed endpoint, treat the result as a verification lead, not a final exploit finding. The next step is to confirm whether the deserialization path reaches risky gadget classes, whether any allowlist is actually enforced, and whether the observed failures are consistent across equivalent requests.
Risk and Threat Considerations
Unsafe Java deserialization is dangerous because the boundary is crossed before the application has a chance to apply normal business logic. A GWT-RPC endpoint that still parses serialized object data can turn a malformed request into code execution, object corruption, or deeper application abuse if attacker-controlled classes are reachable.
Failure mechanism: The application accepts data that should have been rejected at the parser boundary, then attempts to rebuild Java objects from untrusted input. If gadget classes are present, the attacker may be able to trigger unintended behaviour during deserialization rather than through the application’s intended request handling path.
Impact: The consequence can range from reliable application faults and information leakage to remote code execution, depending on classpath exposure and gadget availability. Even when exploitation is not immediately proven, a deserialization error path is a control failure that deserves prioritisation because it signals unsafe trust in inbound object data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V5 — File Handling | Serialized payload handling is a file-like input parsing risk in the app layer. |
| V15 — Secure Coding and Architecture | Unsafe deserialization is a secure-architecture failure at the request boundary. | |
| Recommendation — Treat serialized inputs as untrusted data and reject unexpected object formats before parsing. Remove object deserialization from untrusted request paths and use safer data formats. | ||
| MITRE ATT&CK | T1203 — Exploitation for Client Execution | Deserialization flaws can let attacker-controlled input trigger unintended code execution paths. |
| Recommendation — Map deserialization findings to exploitation paths and hunt for execution-abuse indicators. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The issue is rooted in failing to validate and constrain untrusted inbound data. |
| SA-11 — Developer Testing and Evaluation | Testing should confirm that unsafe deserialization paths are absent or blocked. | |
| Recommendation — Validate and constrain inbound request data before any parsing or object reconstruction. Test application parsing paths for unsafe deserialization before release and after changes. | ||
Practitioner Guidance
What to verify: Confirm whether the application truly rejects tampered GWT-RPC payloads before deserialization begins. The best evidence is a consistent, early reject with no serialization-specific error detail, not merely a generic failure that still changes based on payload contents.
Common mistake: Treating the absence of a successful exploit as safety. For this class of issue, the meaningful signal is whether the endpoint still reaches deserialization logic at all, because that means the attack surface remains present even if the test payload did not weaponise it.
Practitioner takeaway: If substituted GWT-RPC payloads produce deserialization-specific behaviour, assume the endpoint still has an unsafe object-handling path until you can prove a strict allowlist, a hard reject boundary, and no reachable gadget exposure.
Related resources from NHI Mgmt Group
- What is the difference between safe YAML parsing and unsafe Java deserialization in application security?
- How should security teams handle a GWT application that still depends on binary Java serialization?
- What are the signs that an application may be vulnerable to SQL injection?
- What are the signs that a web application is vulnerable to CSRF?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
