References: NVD · VMSA-2021-0014 (Broadcom) · SentinelOne DB

Because no PoC exists, this kit is a find-it-yourself harness: sfcb_probe.py validates an oracle (check) then throws a targeted mutation dictionary at /cimom (fuzz) and flags any 200-with-CIM-body obtained without valid credentials.

Use only against your own lab VM or targets explicitly inside an authorized engagement scope.

1. Lab setup (match the target: ESXi 6.5)

1. Get an ESXi 6.5 ISO (any pre-July-2021 build works; ideally the same 6.5.0 build class as the target):
   • Broadcom support portal (free account) → VMware vSphere Hypervisor 6.5 downloads
   • HPE / Dell "custom ESXi 6.5 image" downloads are public on their support sites
2. Nested VM in VMware Workstation/Fusion (or KVM):
   • Enable "Virtualize Intel VT-x/EPT" on the VM
   • 2 vCPU, 6 GB RAM, thin disk; E1000 NIC for the installer
   • Install in evaluation mode — no license key needed for a lab
3. Enable the CIM broker and its firewall ruleset (DCUI → Troubleshooting → enable ESXi Shell/SSH, then over SSH):
   root@kitploit:~

   /etc/init.d/sfcbd-watchdog status || /etc/init.d/sfcbd-watchdog start
   esxcli network firewall ruleset set --ruleset-id=CIMHttpsServer --enabled=true
   esxcli network firewall ruleset list | grep -i cim
   esxcli network ip connection list | grep 5989   # must LISTEN
   

4. Snapshot the VM (clean state to re-test against).

2. Run the harness

2b. FINDINGS (lab + target ESXi 6.5, confirmed 2026-08-15)

The bypass was found. Root cause: sfcbd fails OPEN when the Basic auth token does not decode into a user:password pair containing a :.

Minimal PoC header (base64 of root, no colon):

Evidence matrix from the fuzz run:

A 200 response carries a CIM-XML envelope dispatched inside the CIMOM (e.g. ERROR CODE="5" Class not found), proving the HTTP auth layer was passed — the identical request without the malformed header returns 401.

Exploit usage:

curl one-liner for report screenshots:

Impact: unauthenticated read access to the CIM broker:

• Account enumeration: VMware_Identity instances leak all ESXi local accounts (observed on lab 6.5: root, dcui, vpxuser — vCenter-managed host — plus custom users), enabling targeted password attacks.
• Full host/hardware inventory via the 436 exposed classes (computer system, processors, memory, storage/datastores, network endpoints, firmware/BIOS versions, sensors, installed software identity).
• No write path: the RBAC services (VMware_RoleBasedAuthorizationService, CIM_PrivilegeManagementService) declare DMTF profile methods (AssignRoles, AssignAccess, ...) but expose no instances — the methods are schema-only. Account creation/modification via CIM is not possible with this CVE; impact ceiling is unauthenticated information disclosure.

Verdicts:

• BYPASS-STRONG — HTTP 200 + CIM-XML body with no valid credentials → you found the bypass; the dumped request is your exploit primitive.
• bypass-weak(200-no-cim-body) — 200 but no CIM body; inspect the dump.
• blocked / info(400) — rejected. Note: a 400 usually means the request died before auth was evaluated — still interesting, just not a bypass.

Note on hand-made CIM bodies: per DSP0200, EnumerateInstanceNames requires the ClassName IPARAMVALUE. A body without it can be rejected for reasons unrelated to auth and poison the oracle — the harness always sends the spec-correct body.

3. Roadmap if the dictionary finds nothing

The fuzzer covers the classic HTTP auth-parser confusion shapes. If none hit, the remaining (and definitive) path is binary diffing:

1. Pull the esx-base VIB for a vulnerable build (e.g. 6.5.0 GA-class) and a VMSA-2021-0014-patched 6.5/6.7/7.0 build from VMware's public depot index: https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
2. Extract both VIBs (they are ar archives → vib payload → cpio), diff sfcbd* binaries with Ghidra + BinDiff.
3. Focus on HTTP header parsing / Basic-auth decode / auth-provider dispatch. Upstream open-source SFCB (SBLIM sfcb on SourceForge) is a useful structural reference for the HTTP+auth code path even though ESXi's fork is modified.
4. Turn the fixed code path into the exact crafted request, add it to the harness, verify on the lab VM — that's the real exploit.

4. Operational notes for the report

• The oracle alone (unauth → 401) is already a useful finding for hardening: 5989 should never be internet-reachable.
• If confirmed, remediation: apply VMSA-2021-0014+ patches (ESXi 6.5 is EOL — recommend migration) or firewall 5989.