No public CVE tracks CloudLeak as of April 26, 2026, but the IAM trust failure is real: role drift plus metadata exposure inside AWS. Full breakdown.
What “CloudLeak” Actually Describes
As of April 26, 2026, no public CVE tracks CloudLeak as a named vulnerability. That does not make the underlying failure imaginary. CloudLeak is a useful label for a class of IAM trust breakdowns inside AWS: permissions that no longer match intent, combined with paths that let role credentials or role-usable identity material leave the place they were meant to stay. The failure is not a single patched bug. It is the predictable result of how roles are granted, how they age, and how instance and service metadata can be reached if network and identity boundaries slip.
Treat it as an operational risk pattern, not a one-time exploit. The trust relationship between a principal and a role is only as sound as the policy that grants assume-role rights, the conditions on that trust policy, and the runtime environment that can call the metadata service or other credential sources. When any of those drift, an attacker or a misconfigured workload can obtain a role session that looks legitimate to AWS APIs.
Role Drift: How Legitimate Grants Become Unintended Access
Role drift is the gap between what a role was designed to do and what it can still do months later. Teams attach broad managed policies “to get the service running,” leave temporary admin-like sidecars in place, or accumulate trust statements for old CI systems, partner accounts, and forgotten Lambdas. Nothing looks broken in the console until someone assumes that role from a place you never intended.
Drift also shows up in trust policies. A role that once required a specific service principal, external ID, or source account condition may later accept a wider set of callers. Resource policies and identity policies evolve independently; without continuous review, the intersection of those policies becomes more permissive over time. The practical fix is not a single audit. It is treating roles as living contracts: least privilege at creation, time-bounded elevation, automated diffing of policy versions, and removal of principals that no longer need assume-role.
Metadata Exposure Inside AWS
Metadata exposure is the second half of the CloudLeak pattern. Workloads often obtain temporary credentials from the instance metadata service, container credential endpoints, or similar local identity channels. Those channels are convenient by design. They become dangerous when application code, a compromised process, or a server-side request path can force the host to fetch role credentials and forward them outward.
Defense here is layered. Prefer IMDSv2-style hop limits and token requirements where available so simple SSRF cannot casually mint sessions. Segment networks so untrusted input paths cannot reach metadata endpoints. Run applications with roles scoped to the minimum actions and resources they need, so a stolen session is a contained incident rather than account-wide access. Log and alert on unusual AssumeRole, GetSessionToken, and long-lived API activity from unexpected source IPs or regions. Temporary credentials still need short lifetimes, rotation discipline, and clear ownership of which role each service is allowed to use.
- Inventory every role that can be assumed, who may assume it, and from which services or accounts.
- Diff identity and trust policies regularly; reject unbounded wildcards unless justified and reviewed.
- Harden metadata access, restrict network paths to credential endpoints, and prefer short-lived, task-scoped roles.
- Monitor CloudTrail-style identity events for unexpected role assumption and credential use.
Practical Hardening Without Waiting for a CVE
Because CloudLeak is not pinned to a single public CVE, waiting for a vendor advisory is the wrong posture. Reduce blast radius first: split duties across roles, avoid shared “platform admin” roles on internet-facing hosts, and require MFA or strong conditions for human elevation paths. Second, close the feedback loop: every new service ships with an explicit role design, a documented trust boundary, and a scheduled review date. Third, practice recovery: if a role session is believed exposed, revoke active sessions where the platform allows it, rotate any long-lived material that might have been confused with temporary credentials, and re-issue least-privilege policies rather than restoring the old broad grant.
The IAM trust failure behind CloudLeak is real even without a CVE entry. Role drift creates excess power; metadata exposure delivers that power to the wrong caller. Close both sides and the pattern loses its leverage.