SerializeKiller: Mass Scanning for Java Deserialization Vulnerabilities That Shouldn’t Still Exist
Hook
A Python 2 script from 2015 made it into Mr. Robot because it solved a problem that enterprise security teams still face today: finding decade-old vulnerabilities in production systems that nobody wants to admit are still running.
Context
In November 2015, security researchers published details about CVE-2015-4852, a critical deserialization vulnerability in Apache Commons Collections that affected nearly every major Java application server in enterprise environments. The vulnerability was devastating in its simplicity: attackers could achieve remote code execution without authentication by sending malicious serialized Java objects to exposed endpoints. WebLogic, WebSphere, JBoss, and Jenkins installations became instant targets, and the vulnerability earned a CVSS score of 10.0.
The theoretical fix was straightforward—patch your servers. The reality was messier. Enterprise environments don’t upgrade quickly. Applications that worked fine on vulnerable versions faced compatibility issues with patches. Security teams needed a way to inventory their exposure across hundreds or thousands of servers before they could even begin remediation. SerializeKiller emerged as a focused solution to this inventory problem: scan everything, identify vulnerable endpoints, and generate actionable reports without triggering IDS alerts or crashing production systems.
Technical Insight
SerializeKiller’s architecture reveals a pragmatic approach to mass vulnerability detection that prioritizes speed and stealth over comprehensive verification. The tool operates in two distinct phases: service discovery via NMAP and targeted HTTP probing for deserialization endpoints.
The service discovery phase leverages NMAP’s speed and reliability rather than reimplementing port scanning in Python. The script constructs NMAP commands dynamically based on input targets, extracting open ports and service banners from the structured output. This design decision acknowledges a fundamental principle: don’t rewrite what already works well. NMAP’s C-based implementation scans orders of magnitude faster than pure Python alternatives, and its fingerprinting database identifies services more accurately than custom regex patterns.
The HTTP probing phase demonstrates the subtlety required for non-destructive vulnerability detection. Rather than sending exploit payloads, SerializeKiller performs reconnaissance against known vulnerable endpoints. Here’s the core detection logic for WebLogic servers:
def check_weblogic(host, port, protocol):
vulnerable_paths = [
'/wls-wsat/CoordinatorPortType',
'/wls-wsat/RegistrationPortTypeRPC',
'/wls-wsat/ParticipantPortType',
'/wls-wsat/RegistrationRequesterPortType',
'/wls-wsat/CoordinatorPortType11',
'/wls-wsat/RegistrationPortTypeRPC11'
]
for path in vulnerable_paths:
try:
url = protocol + '://' + host + ':' + str(port) + path
response = requests.get(url, timeout=5, verify=False)
if response.status_code == 200:
if 'CoordinatorPortType' in response.text:
return 'VULNERABLE'
except:
continue
return 'NOT VULNERABLE'This approach exploits a crucial characteristic of the vulnerability: the affected endpoints are predictable SOAP services that respond to GET requests with identifiable content. The scanner doesn’t need to deserialize objects or trigger exceptions—it merely confirms that vulnerable endpoints are exposed and responding. This passive detection strategy reduces false positives while avoiding the ethical and legal complications of active exploitation.
The multi-target processing implements parallel execution through Python’s threading module, though the implementation is rudimentary by modern standards. Each target host spawns a worker thread that performs the NMAP scan and subsequent HTTP checks independently. The lack of connection pooling or async I/O means that HTTP requests block their threads, but for scanning hundreds of servers with multi-second timeouts, the threading model provides sufficient parallelism without the complexity of asyncio.
The output formatting deserves attention for its simplicity. SerializeKiller produces plaintext reports with color-coded results using ANSI escape sequences—green for safe, red for vulnerable, yellow for uncertain. This terminal-first design aligns with the tool’s intended use case: security professionals running scans from bastion hosts or jump boxes, not automated CI/CD pipelines requiring machine-readable JSON output.
One particularly interesting design choice is the handling of WebSphere detection. The script marks WebSphere servers as ‘possibly vulnerable’ rather than definitively vulnerable or safe because the server often returns generic error pages that don’t confirm the presence or absence of the deserialization flaw. This honest uncertainty reflects the tool’s philosophy: provide actionable intelligence without false confidence. A ‘possibly vulnerable’ result triggers manual verification, which remains necessary for servers running custom configurations or partial patches.
Gotcha
SerializeKiller’s most obvious limitation is its Python 2 dependency. The tool was written when Python 2 was still mainstream, but running it today requires either maintaining a legacy Python 2.7 environment or attempting to port the code to Python 3—a task complicated by changes in the urllib and SSL libraries that affect HTTPS scanning. Several users report that JBoss and Jenkins detection fails entirely on modern systems due to SSL/TLS handshake incompatibilities between Python 2’s ssl module and current server configurations.
The default port assumption creates significant blind spots. SerializeKiller checks standard ports for each service type (7001 for WebLogic, 9060/9043 for WebSphere, 8080 for JBoss), but enterprise environments frequently run services on custom ports for security through obscurity or to avoid conflicts. While you can manually specify custom ports in the targets file, this defeats the purpose of mass scanning—you’d need prior knowledge of non-standard configurations. The tool also cannot detect vulnerable applications running behind reverse proxies or load balancers that don’t preserve original port information, which describes most production enterprise deployments in 2024. The scanner sees the proxy, not the vulnerable backend server, and reports a clean result while the actual risk remains hidden.
Verdict
Use if: You’re conducting historical security research, teaching about deserialization vulnerabilities, performing emergency triage on legacy Java infrastructure that hasn’t been touched since 2015, or you need to demonstrate the scope of technical debt in enterprise environments to justify modernization budgets. The tool excels at rapidly inventorying exposure across large server populations when you suspect but cannot prove that ancient vulnerable systems still exist. Skip if: You’re building modern security scanning infrastructure, need Python 3 compatibility, require detection of custom-port configurations, want integration with vulnerability management platforms, or expect ongoing maintenance and updates. Nearly a decade has passed since this vulnerability was disclosed—if you’re discovering CVE-2015-4852 in production systems today, SerializeKiller is the least of your concerns. Modern vulnerability scanners detect this issue alongside thousands of other CVEs with better accuracy, active support, and compliance reporting. Use this tool as a monument to how slowly enterprise security moves, not as your primary scanning solution.
