SURIQ
The dangerous window on these two TrueConf Server flaws did not open on August 20. It opened in June, the day the fix shipped and every operator who deferred the update stayed reachable. What changed on August 20 is that CISA stopped treating the exposure as theoretical: it added both flaws to its Known Exploited Vulnerabilities catalog, confirmed they are being used in the wild, and put a federal clock on each. One of those clocks runs out in three days.
Two flaws, one chain: an open port to code on the host
The pair works as a sequence, not a menu. CVE-2026-72529 is a missing-authentication flaw: an unauthenticated attacker with network access to TrueConf Server on TCP port 4307 can call an undocumented function and run a script inside the server's isolated environment, according to SecurityWeek's reporting. No credentials, no user interaction.
CVE-2026-72530 is the escape hatch. A crafted script breaks out of that isolated environment and executes code on the host itself. Reach the port, run a script, break out to the box: the two flaws together turn a network connection into host code execution.
The exposure spans a wide range. Every 5.5, 5.4, and 5.3 branch below the June 2026 fix line is affected, and SecurityWeek reports the flaws reach every TrueConf Server release going back to 2022. The Canadian Centre for Cyber Security advisory lists the exact affected builds and points to the fixed releases named below.
Why one flaw gets three days and the other gets two weeks
CISA set two different deadlines for the same catalog entry, and the gap is worth reading. Federal agencies have until August 23 to remediate CVE-2026-72529, a three-day clock, but until September 3 for CVE-2026-72530. When CISA splits a chained pair like this, the tighter deadline lands on the flaw that opens the door from the outside.
That is CVE-2026-72529. It is the unauthenticated, network-reachable entry point, so it is the one an internet-exposed server is most likely to be hit through first. CVE-2026-72530 is the escalation that only matters once an attacker is already inside the sandbox. Both need patching, but if you are triaging exposed boxes by hand this week, the three-day clock tells you which flaw is doing the reaching.
The KEV listing is a lagging indicator, not an early warning
CISA adds a flaw to the KEV catalog once it has evidence of exploitation, which by design puts the listing after the fact. Here the lag is about two months: the fix landed in June, Kaspersky reported the flaws under active use over the summer, and the federal mandate arrived on August 20. The catalog is confirming a window that has been open, not flagging a fresh one.
The practical read: if you applied the June update, you closed this before it was ever on a government list. If you deferred it, you were exposed for the entire stretch that exploitation was running, and the KEV listing is the first official signal you may have missed something. We wrote up the same two flaws two weeks ago, when Kaspersky tied them to the Head Mare group's campaign that poisoned TrueConf client installers with a backdoor family it calls PhantomCore. What was a vendor advisory and a researcher writeup then is a must-patch order now. The facts did not change. The clock did.
Patch to 5.3.9, 5.4.9, or 5.5.5, then assume a reachable box was reached
Upgrade the server to 5.3.9, 5.4.9, or 5.5.5. Then move it off any public interface: the missing-authentication flaw means an exposed server answers unauthenticated connections on port 4307, so a TrueConf Server sitting on the internet is the exact shape this pair was built to hit.
Patching is necessary, and it is not the same as being safe. The upgrade closes the hole; it does nothing about an intrusion that already happened. Because the reported post-exploitation steps replaced a legitimate server file with a web shell and swapped the client installers the server hands out for trojanized ones, any box that was internet-reachable on port 4307 between June and the day you patched should be treated as already compromised, not merely fixed. That means hunting: look for an unexpected server-side script standing in for a normal file, and check endpoints that pulled a TrueConf update for client binaries that are not validly signed by the vendor. The signed-publisher check is the cheapest tell, because the malicious installers lack a valid signature.
This is the gap a patch cannot close on its own: knowing whether the window was used against you before you shut it. A managed detection service that watches for web-shell drops, unsigned-binary execution, and anomalous outbound traffic from a conferencing host is how you answer that question rather than assume the answer. Suriq runs that kind of managed detection against the hosts you already operate. Patch first, then hunt: on a server that was reachable, the second step is the one that tells you if you have an incident.