There Is a 9.8 Unauthenticated RCE in TrueConf Server, Exploited Since September. It Has No CVE, So Your Scanner Cannot Say Its Name.
- Patrick Duggan
- 3 hours ago
- 5 min read
We have a standing beat here about vulnerabilities with no CVE: remote code execution quietly fixed in a release note, never filed, invisible to every scanner keyed on identifiers. The label failure is the story, because a bug your tooling cannot name is a bug your tooling cannot find.
TrueConf is that beat escalated one level, and it is worse in an instructive way. The identifiers exist. They are in a registry your tooling does not speak.
Two attacks, one product, opposite directions
Most coverage will conflate these because both sentences begin "TrueConf." They should not be conflated — they are different actors, different components, different trust relationships, different everything.
Operation TrueChaos is Chinese-nexus, assessed at moderate confidence, reported by Check Point. It went after a government's on-premises TrueConf deployment and reached connected agencies from there. The mechanism was the Windows client update path — replacing installers with malicious versions to deliver a backdoor, Havoc via DLL sideloading, with tooling overlapping ShadowPad. It carries [CVE-2026-3502](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-3502), CVSS 7.8, fixed in client 8.5.3 in March 2026.
Head Mare is a pro-Ukraine hacktivist cluster, reported by Kaspersky and Kaspersky ICS CERT, hitting Russian public sector, logistics, finance, industry and energy. It went after TrueConf Server admin endpoints, deploying the PhantomDL/PhantomCore family, web shells and tunnels.
Its three vulnerabilities carry BDU:2025-10114, BDU:2025-10115 and BDU:2025-10116.
That is all they carry. No CVEs. BDU is the vulnerability database run by Russia's FSTEC.
The 9.8 that cannot enter KEV
BDU:2025-10116 is a command injection, CVSS 9.8, an unauthenticated path to remote code execution. Patched 2025-08-27. Exploited in the wild from mid-September 2025.
Every property in that sentence is KEV-class. Internet-facing, unauthenticated, maximum-tier severity, confirmed exploitation, patch available. It is exactly the profile CISA catalogues within days — we published a piece this morning showing the median KEV remediation deadline is now three days precisely because of bugs shaped like this one.
It will never be in KEV. KEV requires a CVE. No CVE, no entry, no deadline, no dashboard row, no ticket.
And this is not a Russian problem that Western organisations get to file under geopolitics. TrueConf is deployed outside Russia. A Western organisation running TrueConf Server today has three critical, actively-exploited vulnerabilities that its commercial scanner cannot express — not "did not detect," cannot express, because the scanner's data model is keyed on CVE identifiers and does not carry BDU.
The asymmetry is not about the bugs. It is about who reported them and through which process. Check Point is a Western vendor and filed through the Western process, so TrueChaos got a CVE. Kaspersky reported through FSTEC, so Head Mare's three got BDU numbers. Same product, same year, same class of severity — and one set is visible to your tooling while the other is, functionally, classified.
Vulnerability identity is fragmenting along geopolitical lines, and the fragmentation is now a defensive gap rather than a bureaucratic curiosity.
We checked whether we have the same blind spot. We do.
It would be cheap to write that paragraph about scanner vendors and stop. So we ran the same test against ourselves, on the live index rather than from memory.
Our `cisa_kev` index cannot hold a BDU identifier. The field list is addedDaysAgo, cveID, cwes, dateAdded, daysUntilDue, description, dueDate, id, isOverdue, name, notes, product, ransomwareUse, requiredAction, timestamp, vendor. The identifier field is literally named `cveID`. There is no vendor-neutral vulnerabilityId, no alternateIds, no registry field. A BDU number has nowhere to live in our schema.
Genuine BDU identifiers in our entire 17.9-million-document corpus: zero. We searched cisa_kev, blog, adversaries and iocs. The first three returned nothing. iocs returned seven hits which we checked individually against the pattern /BDU:\d{4}-\d+/ — every one is substring noise from domain names like bduwih8.pro and bduddqal.icu. Not one real identifier.
So we built a threat-intelligence platform on the same assumption every scanner vendor made: that a vulnerability's identity is a CVE. It was a reasonable assumption for twenty years. It stopped being true while nobody was looking, and we did not notice until we went looking for a specific number and found we had nowhere to put it.
That is the honest version, and it is more useful to you than a clean one. If your stack has a field called cve_id, you have this problem too, and you can confirm it in about a minute.
What to actually do
If you run TrueConf Server, patch to the 2025-08-27 release or later, today. Do not wait for a CVE to appear in your dashboard, because it is not coming. Verify by version number, not by scanner output — the scanner will tell you that you are clean, and it will be telling the truth about the only thing it can see.
If you run the TrueConf Windows client, get to 8.5.3 or later for CVE-2026-3502, and treat the client update channel itself as a trust boundary. That was the delivery mechanism, not the payload.
More generally: stop treating "no CVE" as "no vulnerability." We have now seen three distinct versions of this failure — the vendor who silently patches and never files, the CVSS 10.0 shipped with no identifier at all, and now the bug that has an identifier in a registry your tools do not read. All three produce the same outcome at your perimeter.
And go and look at your own identifier field. Whatever your vulnerability data lives in — a scanner, a SIEM, a spreadsheet, a threat-intel platform you built yourself — check whether it can represent a vulnerability identifier that is not a CVE. If the column is called cve_id, the answer is no, and you have inherited a blind spot the same shape as ours.
We are going to fix ours. The schema change is small; noticing it was the hard part, and we only noticed because an actor we were profiling had bugs we could not write down.
TrueChaos analysis is Check Point's; Head Mare / PhantomCore analysis is Kaspersky's and Kaspersky ICS CERT's. Credit to both — we did not find either campaign, and the two should not be merged into a single "TrueConf" story. CVSS scores and patch dates are as published by those vendors and by FSTEC's BDU. Our schema audit and corpus search were run against live indexes on 2026-08-08 and re-confirmed 2026-08-11. The Head Mare cluster circulates under at least five names — PhantomCore, Head Mare, Fairy Trickster, Rainbow Hyena and others — which is its own reason coverage of it fragments.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=trueconf-bdu-only-vulnerabilities-scanner-cannot-express
Comments