CISA has added two TrueConf Server vulnerabilities to its Known Exploited Vulnerabilities catalog. That action confirms exploitation in the wild. It also turns an ordinary patch task into a wider incident-response question.
The two flaws—CVE-2026-72529 and CVE-2026-72530—can be chained by an unauthorized attacker who can reach the server on TCP port 4307. One exposes a critical function without authentication; the other allows code to escape an isolated environment and execute on the host.
CISA does not identify the actor, malware, or victim behind its decision. Those details come from Kaspersky ICS CERT, which says it observed the flaws used against Russian organizations in a chain that planted a web shell, reached the conferencing database, and replaced the server-hosted Windows client installer with a trojanized copy carrying PhantomCore.
The vulnerable server was the entry point. The trusted download path became the multiplier.
The fixes were already available. The fresh event is CISA's confirmation that both vulnerabilities meet the KEV standard for exploitation in the wild.
The patch date and the escalation date are different
TrueConf released fixed builds on June 18: versions 5.3.9, 5.4.9, and 5.5.5. The affected ranges are all releases before 5.3, plus 5.3.x before 5.3.9, 5.4.x before 5.4.9, and 5.5.x before 5.5.5.
Kaspersky published its campaign alert in August. CISA added both CVEs on August 20. Under the current KEV deadlines, federal civilian agencies must address CVE-2026-72529 by August 23 and CVE-2026-72530 by September 3.
That sequence matters. This is not a newly patched zero-day. It is a case where fixes existed before the government's exploitation signal. Organizations that treated the June release as a routine maintenance item now have a different risk classification—and potentially an exposure window to investigate.
A version check can prove the server is fixed now. It cannot prove what happened before the update.
The compromise crossed the server boundary
According to Kaspersky, the attackers used the paired weaknesses to gain code execution on an unpatched server, replace a server file with a web shell, collect information about the environment, and obtain privileged access to the TrueConf database.
The next step changed the blast radius. The attackers replaced the x64 Windows client distribution file stored on the server. Conference participants were then shown a prompt to download a new client version. The altered installer still deployed the conferencing client, but also unpacked the PhantomCore backdoor.
The download came from the collaboration server the participant intended to use, and the installer still produced expected software. Success could reassure the user while adding attacker-controlled code.
The observed chain turned one compromised server into a delivery point for endpoints that trusted its client download.
Kaspersky also describes backdoors on Unix-like TrueConf servers. Those findings belong to its investigation; CISA's KEV entries establish exploitation of the CVEs, not every element of that campaign.
A participant can inherit someone else's server incident
The server owner is not the only party at risk.
Kaspersky explicitly warns that an employee may connect to a compromised TrueConf server operated by a contractor or another organization, join a meeting, and download the altered client package. The employee's own organization may not operate TrueConf Server at all.
That breaks the usual asset-owner boundary. The infrastructure team responsible for the vulnerable server may sit in one company. The endpoint that receives the installer may belong to a customer, partner, supplier, or guest. Neither side's inventory is complete by itself.
The practical exposure question is therefore broader than “Do we run a vulnerable server?” It also includes:
Did employees connect to externally operated TrueConf meetings during the relevant period?
Did any endpoint download or execute a client installer from those servers?
Can the organization distinguish a known-good vendor package from one served by a compromised host?
Third-party meeting participation can become a software-distribution dependency even when no formal integration exists.
The downstream population may cross company boundaries, so server logs and endpoint evidence have to be reconciled together.
Patching closes entry. It does not clear execution.
Server owners should move to 5.3.9, 5.4.9, or 5.5.5 as applicable and verify the running build—not merely the package staged for installation. If port 4307 was reachable while a vulnerable version was present, that condition raises urgency; it is not proof of compromise by itself.
The response then needs two parallel tracks.
On the server, preserve available logs and volatile evidence without delaying containment. Review unexpected web files, changes to the client distribution package, privileged database access, new services, and other indicators in the Kaspersky alert. Compare the currently served installer with a clean, independently obtained release. Reduce network exposure to the service to the minimum required paths.
On endpoints, identify systems that downloaded or ran the client installer from an exposed or unverified server. Preserve the package and download timing, calculate hashes, and compare them with known-good material and published indicators. Hunt for the reported PhantomCore artifacts and contain positive detections. If compromise is found, rotate potentially exposed credentials and investigate what the endpoint could reach; do not treat reinstalling the conferencing client as eradication.
The order is important: contain the server, preserve the evidence needed to identify downstream recipients, and prevent a cleaned endpoint from retrieving the same poisoned package again.
Closure needs proof on both sides
A defensible closeout should show:
the affected server is on a fixed build and unnecessary access to TCP 4307 is removed;
server files, database activity, services, and the client distribution package have been checked for the reported compromise pattern;
historical installer downloads have been mapped to users and endpoints as far as available evidence allows;
suspected packages were preserved and compared with an independent known-good source;
positive endpoints were contained, investigated, and remediated; and
credentials, sessions, or other access exposed by confirmed malware were invalidated and verified unusable.
The patch closes the two named entry points. Closure requires separate evidence that the distribution path and its recipients are clean.
The trusted path is part of the attack surface
KEV prioritization tells defenders where exploitation is no longer hypothetical. In this case, the most consequential artifact may sit beyond the vulnerable process: a client installer delivered through infrastructure users already trusted.
Patch the affected server. Inspect what it served. Trace who received it. Follow the evidence across organizational boundaries.
A clean server today does not prove it served clean software yesterday.