Collibra Agent Unauthenticated RCE Chain Exposes Data Governance Deployments
CERT/CC disclosed two vulnerabilities in Collibra Agent that can be chained by a remote unauthenticated attacker to reach remote code execution. Public sourcing is limited at the time of writing, but the published issue is serious because it combines access to privileged REST functionality with a ZIP path traversal that can write attacker-controlled files outside the intended extraction path.
That combination makes this more than a minor product bug. Collibra is used in environments where data governance tooling often has broad visibility into metadata, data workflows, and integration paths. If the Agent is exposed carelessly, the attacker path described by CERT/CC could become a way to gain execution on an appliance or host that sits close to sensitive enterprise data processes.
Summary
The Collibra story matters because it hits a class of enterprise software that is frequently treated as operational infrastructure rather than as a high-value attack surface. According to CERT/CC, the problem is not a single isolated defect. It is a chain made up of improper authentication on privileged REST endpoints and a path traversal issue in the Agent restore handler. CERT/CC says an attacker can exploit the two issues together by uploading a crafted ZIP archive that writes files to arbitrary locations on the server once extracted, resulting in remote code execution.
Because reviewed public sourcing for this issue is currently limited to the CERT/CC publication, responsible analysis requires restraint. There is no basis yet, from the sources reviewed for this article, to claim active exploitation in the wild, broad internet scanning, victim counts, or a confirmed vendor patch. What is clear is that the published attack chain is severe enough that organizations should not wait for richer public reporting before reducing exposure.
What is confirmed right now
CERT/CC identifies two CVEs in Collibra Agent. CVE-2026-10622 covers improper authentication in REST API functionality that exposes privileged /rest/* endpoints. CVE-2026-10621 covers path traversal in the restore handler, where ZIP extraction does not properly validate and canonicalize file paths. That means files can be written outside the intended extraction directory.
On their own, these are already serious defects. Together, they create a much more operationally dangerous result. If an unauthenticated attacker can reach privileged Agent functionality and then use a crafted archive to place attacker-controlled files on disk, the system crosses from access control failure into server-side compromise territory. That is why CERT/CC characterizes the chain as remote code execution rather than merely unauthorized access or arbitrary file write.
The exposure condition that defenders should focus on immediately is reachability. Collibra Agent is described by CERT/CC as an independent service installed on the host system and listening on a different port than the main web interface. That architectural detail is important because teams sometimes harden the primary application tier while leaving auxiliary services less tightly controlled. Management or support interfaces that are "not the main app" are a recurring blind spot in enterprise environments.
Why this deserves urgent attention
Data governance platforms often sit near important internal systems even when they do not directly store production business data in the same way as a transactional application. They may connect to catalogs, pipelines, policy engines, lineage tooling, connectors, and authentication systems. That makes compromise of an adjacent service potentially useful for follow-on activity even before defenders determine the full blast radius.
The other reason to move quickly is attacker economics. A published unauthenticated chain involving an enterprise service is exactly the type of issue that can attract opportunistic testing if it is easy to fingerprint exposed endpoints. Even without evidence of current exploitation, the time between public disclosure and exploit experimentation is usually short for flaws that combine network reachability with high-impact outcomes.
This is also the kind of vulnerability that can remain hidden in environments that rely too heavily on perimeter assumptions. If an organization believes an internal-only interface is "safe enough," it may not monitor it as closely, may not inventory it accurately, and may not prioritize emergency change control for it. That is the mindset defenders should avoid here.
Practical defender actions
First, identify whether any Collibra Agent interfaces are reachable from untrusted networks, partner networks, remote administration segments, or shared internal zones. If the answer is yes, reduce exposure immediately. Restrict access at the network layer, not just the application layer.
Second, review any restore, backup, or administrative workflows tied to the Agent. If the service supports archive-based recovery or maintenance actions, those paths deserve immediate scrutiny because the public report specifically names the restore handler and crafted ZIP extraction as part of the exploit chain.
Third, look for unusual activity around /rest/ paths, unexpected archive uploads, abrupt service restarts, or file creation in directories that should not be touched by maintenance workflows. Even if you do not yet have detailed indicators, behavior-based review can still surface suspicious activity.
Finally, track vendor guidance closely but do not invent it. In the reviewed source, the vendor statement shown in the CERT/CC entry does not provide confirmed remediation steps. That means defenders should avoid filling gaps with assumptions and instead focus on exposure reduction, compensating controls, and direct confirmation of any future vendor advisory.
What remains unclear
Several important facts remain unknown in the reviewed public material. There is no confirmed public patch reference in the source reviewed for this article. There is also no public evidence in the reviewed source set that the issue is being actively exploited, no published detection guidance, and no detailed vendor-authored root-cause discussion.
Those gaps should make defenders precise, not passive. The confirmed claim is already strong enough: CERT/CC says the two flaws can be chained by a remote unauthenticated attacker to reach remote code execution. Until richer sourcing becomes available, that is the right foundation for defensive action.
