What this checks: whether a VMware vCenter host runs a version affected by unauth arbitrary file upload -> RCE in Analytics/CEIP service. Read-only: it fingerprints VMware vCenter and reads the version, no exploitation.
3. Detection — reads the VMware vCenter version from the version exposed at /sdk, compares to 6.5 line: not affected; 6.7 line: 6.7 U3o (6.7.0 build-18485166); 7.0 line: 7.0 U2c (7.0.2 build-18356314). Flags vulnerable on an affected build. No exploitation.
1. Target List — paste your VMware vCenter URLs here, one per line (e.g. https://host.example.com).
Overview
This workflow finds VMware vCenter Server and sorts each host by whether its version and build fall below the CVE-2021-22005 floors in the graph. CVE-2021-22005 is remote code execution through an analytics file-upload path on vCenter. This check never hits the analytics upload URL and never uploads a file. Give it hostnames, IP addresses, or URLs you are authorised to test. The workflow GETs /sdk only, fingerprints vCenter from markers in that response, parses the VMware vCenter Server version and build- number, and compares the tuple to the branch floors: 6.5 not affected, 6.7 U3o build 18485166, and 7.0 U2c build 18356314. Every host comes back affected or not, so a fleet advisory becomes an evidenced list for exposure management. There is no SOAP POST body and no confirm step.
Run it on a schedule when VCSA appliances change. A cloned 6.7 appliance that missed U3o is the reason the same fingerprint stays useful.
Pipeline
Read the target list. Hosts, URLs, or ranges, one per line, become the scope.
GET /sdk on each host and fingerprint vCenter from response markers such as VMware vCenter Server, urn:vim25, build-, and vpxd.
Parse the version and build string and compare the tuple to the CVE-2021-22005 floors in the graph (6.5 N/A, 6.7 build 18485166, 7.0.2 build 18356314).
Collect the per-host rows: product match, version, vulnerable flag, and any fetch error.
Emit the summary counts: hosts checked, product hits, vulnerable, and errors.
Inputs
Target scope. Hostnames, IP addresses, CIDR ranges, or URLs, 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
results.jsonl. One row per host: URL, whether vCenter was detected, the version read, the vulnerable flag, and detail text.
findings.jsonl. The same per-host verdict shaped for triage, with severity set from the vulnerable flag.
summary.json. Counts across the list: targets, product hits, vulnerable, and errors, plus the detection notes from the graph.
Integrations
HTTP. Unauthenticated GET of /sdk only. No analytics file upload and no SOAP POST.
Sample output
The records below are illustrative and do not come from a real run. They show one vCenter host below a CVE-2021-22005 floor, one at or above its branch floor, and one host that is not the product.
Hosts whose parsed version and build tuple fall below the floors in the graph: 6.5 is not affected, 6.7 U3o (build 18485166), and 7.0 U2c (build 18356314). The compare uses the string the /sdk response itself served.
Does an affected row mean the analytics upload worked?
No. The check only GETs /sdk and reads version and build. It does not hit an analytics upload endpoint and it does not confirm RCE.
Is this check safe on production?
Yes. It is a read-only unauthenticated GET of /sdk. It does not log in or upload a file.
Does the check need credentials?
No. It fingerprints the public /sdk surface the way an external scanner would.
What is CVE-2021-22005?
Remote code execution in VMware vCenter Server through an analytics file-upload path. This workflow maps hosts to that CVE by version and build exposure only.