CVE-2026-72530

APPLIANCE FINGERPRINT

NewScan fingerprints the TrueConf Server appliance and reports this CVE when the detected version falls inside the affected range below.

Added 2026-08-21, in CISA KEV the same day: exploited by Head Mare against TrueConf Server to stage PhantomCore (Securelist, https://securelist.com/tr/head-mare-targets-trueconf-server-with-phantomcore/120988/). No EPSS yet - FIRST has not scored a same-day CVE, so a missing score here means UNRATED, not safe. Affected per the advisory: 5.3.X-5.3.9, 5.4.X-5.4.9, 5.5.X-5.5.5 `and earlier`, i.e. every build up to and including 5.5.5 with no lower bound - which is exactly `lt 5.5.6` and NOT `le 5.5.5`: TrueConf ships four-component builds, so `le 5.5.5` would have excluded 5.5.5.10009, the very build measured as vulnerable (version_in_range compares numerically, verified across 5.3.9.10015 / 5.4.9.10019 / 5.5.5.10009 / 5.5.6). NO `fixed_in`, deliberately: the vendor's fixed build is not identified anywhere we can read, and it is NOT 5.5.6-by-assumption - trueconf/trueconf-server:stable was pulled 2026-08-21 for the patched arm and reports the SAME 5.5.5.10009 off /admin/ (a different digest, so a rebuild of the same release), meaning no patched image exists on that channel yet. Omitting the field makes build_known_vuln_finding say `the latest patched release`, which is the true statement; `lt` is derived from the advisory's affected range, not from a guessed fix, so the gate is sound either way. The negative case therefore could not be measured against a container and is pinned as a version CASE in tests/integration/appliance_fingerprint_checks.py instead - the 2026-08-13 Flowise precedent. NEEDS NO PROBE and must not get one: the vector is a proprietary protocol on 4307/TCP, not HTTP, and the finding rides entirely on the anonymous build number the appliances row reads off GET /admin/. That is the whole reason this pair is gated rather than advisory - see the appliances.json note for the measurement.