What this checks: whether an Apache Tomcat host runs a version affected by unauth JMX deserialization RCE (precondition: JmxRemoteLifecycleListener enabled). Read-only: it fingerprints Apache Tomcat and reads the version, no exploitation.
3. Detection — reads the Apache Tomcat version from the product's default response and version banner, compares to 6.0.48 / 7.0.73 / 8.0.39 / 8.5.8 / 9.0.0.M12 (per branch). Flags vulnerable on an affected build. No exploitation.
1. Target List — paste your Apache Tomcat URLs here, one per line (e.g. https://host.example.com).
Overview
This workflow finds Apache Tomcat hosts where JmxRemoteLifecycleListener deserialization can lead to remote code execution, tracked as CVE-2016-8735. Give it hostnames, IP addresses, or CIDR ranges you are authorised to test. It fingerprints exposure and version without authenticating or sending exploit payloads. Use the per-host verdict in exposure management to prioritise patching, not as proof of exploitability. The check stays non-destructive end to end.
Pipeline
Normalize the input scope into a bare host list.
Probe each host for product exposure signals used by this check.
Read version or build evidence from unauthenticated responses where available.
Compare that evidence to the known affected range for CVE-2016-8735.
Emit one JSONL record per host with the verdict, plus a summary line.
Inputs
Target scope. Hostnames, IP addresses, or CIDR ranges, one per line. Full URLs and host:port entries work too, since the workflow normalizes each into a bare host. Point it at scope you are authorised to test.
Outputs
Affected host list. Hosts whose fingerprint falls in the affected range for CVE-2016-8735, kept apart from the patched ones.
Per-target evidence. For each host: whether the product was detected, the version or build read, and the verdict, so you can check a finding instead of trusting it.
Final report. A JSON summary counting affected, patched, and verify-manually hosts across the whole list.
Integrations
HTTP fingerprinting for product and version signals.
Sample output
The records below are illustrative and do not come from a real run. They show the shape of a fingerprint verdict for CVE-2016-8735.
Does an affected verdict mean the host is exploitable right now?
No. The workflow fingerprints exposure and version without authenticating or sending exploit payloads. Treat the verdict as a patching signal. It does not prove exploitability on that host.
What scope should I pass in?
Hostnames, IP addresses, or CIDR ranges you are authorised to test. Prefer the edge or CI hosts where Apache Tomcat is expected, so the fingerprint has somewhere to land.
Will this send exploit payloads?
No. Detection stays read-only: exposure and version fingerprint only, matching the workflow README.