CTEM exposes why point-in-time scans fail against active Zimbra exploits

At a glance

What this is: This is SafeBreach’s analysis of CVE-2026-73570 in Zimbra Collaboration Suite and the case for continuous exposure validation over periodic scanning.

Why it matters: It matters because teams running internet-facing collaboration systems need to know which assets are actually exploitable today, not just which ones appeared vulnerable at the last scan.

By the numbers:

• CVE-2026-73570 can be weaponised without credentials, which makes exposure validation more urgent than scheduled patch review.

👉 Read SafeBreach's analysis of the actively exploited Zimbra CVE and CTEM

Context

Point-in-time scanning tells security teams what was visible when the scan ran, but it does not prove what an attacker can reach or use between assessments. That gap becomes critical for internet-facing collaboration systems, where unauthenticated remote code execution can move from disclosure to active exploitation in days. In Zimbra’s case, the issue is not only the flaw itself, but the assumption that periodic review is enough for exposed services.

For IAM and NHI practitioners, the governance lesson is broader than patching one CVE. Collaboration platforms often sit close to identity, email, and administrative workflows, which means exposure can quickly become credential compromise, lateral movement, or privilege abuse if controls are not continuously validated. That makes CTEM relevant wherever attack paths depend on current reachability, not just theoretical vulnerability status.

Key questions

Q: What fails when teams rely on point-in-time vulnerability scans for internet-facing systems?

A: They get a snapshot of historical exposure, not proof of current exploitability. Attackers use the gap between scans to target systems that have already changed, especially exposed collaboration and edge services. Continuous validation is needed when risk depends on whether a flaw is reachable right now, not whether it appeared in last week’s report.

Q: When should organisations prioritise CTEM over faster patch cycles?

A: CTEM should move up the list whenever exposed assets can be targeted faster than your assessment cadence, especially on internet-facing services with unauthenticated attack paths. Faster patching still matters, but it does not answer whether a given asset is exploitable today. Validation must come before confidence.

Q: What do security teams get wrong about false positives in exposure management?

A: They often treat false positives as a scanning problem instead of a decision problem. The real issue is that unvalidated findings consume analyst time, reduce trust in scoring, and delay the highest-value fixes. Validation should be used to separate potentially exploitable exposure from theoretical issues before remediation effort is committed.

Q: Who is accountable when exposure remains open after a vulnerability is disclosed?

A: Accountability should sit with the asset or service owner, but only if ownership records are current and tied to privileged access paths. In practice, that means IAM, infrastructure and security teams need a shared operating model for assigning remediation, approving exceptions and proving closure. Otherwise, gaps linger because no one can act decisively.

Technical breakdown

Why point-in-time scans miss exploitable exposure

A vulnerability scan is a snapshot. It identifies known weaknesses at the moment of collection, but it cannot keep pace with changes in routing, configuration, internet exposure, patch state, or attacker tooling. In practice, that means the report can already be stale by the time teams review it. CTEM is different because it treats exposure as a continuously changing condition and revalidates whether an asset is reachable and exploitable in the current environment. The value is not broader coverage for its own sake, but evidence of what matters operationally right now.

Practical implication: replace scan-driven urgency with continuous validation for externally reachable systems that can change between review cycles.

How unauthenticated RCE changes exposure management

Unauthenticated remote code execution is one of the highest-risk vulnerability classes because it removes the attacker’s dependence on stolen credentials or prior access. Once an internet-facing service accepts malicious input that results in command execution, the defender is no longer only managing patch state. They are managing whether the service should be reachable at all, how quickly exposure can be validated, and whether compensating controls reduce the blast radius. For collaboration platforms, this often intersects with identity because the same systems can expose mailboxes, sessions, admin functions, or adjacent trust relationships.

Practical implication: treat unauthenticated RCE on exposed infrastructure as a reachability and trust problem, not only a patching problem.

What CTEM changes in the validation loop

CTEM closes the gap between detection and decision by adding evidence-based validation to the security workflow. Instead of assuming that a CVE or misconfiguration is equally urgent everywhere, it asks whether the specific asset is exposed, whether exploit conditions are present, and whether an attacker can actually succeed in your environment. That matters because the same flaw may be unreachable in one deployment and fully exploitable in another. The operational shift is from inventory plus scanning to scoped, repeated proof of exploitability.

Practical implication: prioritize validation workflows that confirm exploitability before escalating remediation workstreams.

Threat narrative

Attacker objective: The attacker wants reliable remote command execution on exposed collaboration infrastructure so they can pivot into higher-value internal data and identities.

1. Entry occurs when an attacker targets an internet-facing Zimbra server that accepts unauthenticated SNMP command injection.
2. Escalation follows when malicious input executes arbitrary system commands on the affected host without needing valid credentials.
3. Impact is achieved through server compromise, which can expose mail, collaboration data, or adjacent trust relationships used for further intrusion.

Breaches seen in the wild

• Gravity SMTP CVE-2026-4020 API Keys Exposure — CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Point-in-time vulnerability management is now a governance liability: when exploitation windows are measured in days, periodic scanning cannot provide credible assurance. Security teams are left reporting historical exposure rather than current exploitability, which is a weaker control statement for boards and auditors. The practical conclusion is that assurance must be tied to present tense evidence.

CTEM introduces a more defensible exposure model: continuous validation does not replace patching, but it changes the question from "what exists" to "what can an attacker use now". That matters for internet-facing collaboration systems, identity-adjacent platforms, and any service where reachability changes faster than scan cadence. Practitioners should treat continuous validation as a control layer, not a reporting layer.

Identity-adjacent infrastructure deserves the same scrutiny as identity systems: collaboration servers often sit close to mail, admin, and authentication flows, so compromise can quickly become credential theft or privilege abuse. That intersection is exactly where identity governance meets exposure management. The right conclusion is to map externally reachable services into identity and access risk reviews, not separate them into a pure infrastructure queue.

Exposure management needs a named concept for executive reporting: exploitation lag: the delay between patch availability, exploitable exposure, and defender awareness is now a measurable governance problem. When lag is long enough for active exploitation to land before remediation, the issue is not patch velocity alone. Teams should report exploitation lag alongside patch status to reflect real risk.

For NHI and IAM programmes, current reachability is part of trust governance: if a server can be commandeered without credentials, downstream access assumptions may collapse before any identity control is consulted. That makes validation of internet-facing systems a prerequisite to trustworthy access governance, especially where collaboration platforms intersect with identity stores or administrative sessions. The practical conclusion is to fold exposure evidence into access-risk decisions.

From our research:

• More than 12,000 internet-facing Zimbra servers were still exposed as of mid-August, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: Continuous validation matters because exposed credentials and services can be targeted before scheduled review cycles close the gap, which is why the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is relevant here.

What this signals

Exploitation lag is now a board-level exposure metric: when unauthenticated flaws move from disclosure to active abuse in days, patch status alone no longer describes risk. Security leaders should measure how long exposed services remain reachable after validation, and use that gap to prioritise remediation across collaboration, email, and identity-adjacent systems.

For programmes that touch IAM or NHI governance, the practical signal is that collaboration infrastructure can become an identity risk amplifier. A compromised exposed server may not be an identity system itself, but it can still create credential theft paths, session abuse, or trust-chain compromise. That means exposure evidence should feed directly into privileged access and identity assurance decisions.

Continuous validation also changes how teams prepare for the next KEV-listed flaw. The objective is not to eliminate all exposure, which is unrealistic, but to know which assets are exploitable before adversaries do. Practitioners who can answer that question consistently will spend less time in emergency mode and more time reducing attack paths.

For practitioners

• Build continuous exploitability validation for internet-facing assets Prioritise externally reachable systems that sit close to identity, email, collaboration, or administrative workflows, and validate them continuously rather than waiting for the next scheduled scan. Focus on whether exploitation is possible in the current configuration, not whether a finding exists in a report. Consider using adversarial exposure validation for the assets most likely to be targeted.
• Create a separate response path for unauthenticated RCE on exposed services Do not route these findings through ordinary backlog triage. Assign them to a fast containment and validation workflow that confirms reachability, internet exposure, and compensating controls while patching is underway. If the service handles identities or mail, include access and session review in the same response.
• Tie asset inventory to exploitability, not just ownership Tag collaboration and edge systems by exposure state, business function, and adjacency to identity services so prioritisation reflects attacker reach, not asset count. A complete inventory is not enough if it cannot answer which assets are reachable and exploitable right now.

Key takeaways

• Active exploitation of internet-facing collaboration software shows why historical scans are not a sufficient control statement.
• The scale of exposed Zimbra servers reinforces that exploitability, not just vulnerability presence, should drive remediation priority.
• CTEM is valuable because it turns exposure management into continuous proof of current reachability and attacker feasibility.

Key terms

• Continuous Threat Exposure Management: Continuous Threat Exposure Management is the ongoing process of finding which assets, identities, and paths are actually reachable from the current environment. It moves risk assessment away from static inventories and toward live exposure, so security teams can prioritise what an attacker or misuse path can reach now.
• Adversarial Validation: Adversarial validation is the practice of testing a model or system against realistic attack patterns before and after deployment. It checks whether hidden instructions, multi-turn pressure, and malicious context can change behaviour. For enterprise GenAI, it is more useful than synthetic benchmark confidence because it reflects live operational risk.
• Exploitation Lag: The delay between disclosure, available remediation, and an organisation’s ability to prove whether exposed assets are still exploitable. It is a useful governance concept because it captures the period when attackers can act before the defender has closed the decision gap.
• Unauthenticated Remote Code Execution: A flaw that lets an attacker run code on a target system without first proving who they are. In enterprise applications, this is especially dangerous because the code executes inside a trusted workload context, which can expose data, internal services, and downstream privileges.

What's in the full article

SafeBreach's full analysis covers the operational detail this post intentionally leaves for the source:

• The exploitation timeline and why the patch window still left exposed Zimbra servers at risk
• How SafeBreach frames adversarial exposure validation as evidence for board and remediation decisions
• The specific reasons point-in-time scans fail to distinguish theoretical vulnerability from current exploitability
• Implementation context for CTEM when collaboration platforms sit close to identity and mail workflows

👉 SafeBreach's full post covers the exploit pattern, exposure scale, and the CTEM case in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity assurance with broader security operations and risk decisions.