#cloudsecurity

Read Time:4 Minute, 4 Second

A newly disclosed Linux kernel vulnerability, nicknamed PwnEscape, is a reminder that virtual machine isolation depends on far more than the hypervisor sitting on top of it. The flaw, tracked as CVE-2026-99999, lives deep in the kernel’s networking stack and can let an attacker-controlled guest peek into host memory — and, under the right conditions, push further toward code execution on the host itself.

A Timing Bug in a Routine Performance TrickThe root cause is surprisingly mundane. Linux often defers calculating a network packet’s checksum until later in processing, a common performance optimization. Packet metadata tells the kernel where that checksum calculation should start and where the result should be written.

Researcher Paulos Yibelo found that this metadata could be manipulated so that a deferred checksum write altered the contents of a packet’s IPv4 header — after the kernel had already made decisions based on the header’s original values. In his proof-of-concept, a packet that initially looked like a standard 20-byte IPv4 header could be reinterpreted as a 60-byte header following the delayed write, tricking the fragmentation code into treating bytes beyond the packet’s valid data as legitimate header content.

The practical result: roughly 32 bytes of host memory leaked into an outgoing packet. On its own, that’s an information disclosure bug. But in a controlled lab environment, researchers chained that leak with careful memory-allocation manipulation to achieve targeted kernel-memory writes and ultimately execute a host-level helper process with root privileges.

Important CaveatsIt’s worth being precise about what has and hasn’t been demonstrated. The escalation from memory leak to root execution was reproduced on systems the researchers controlled themselves — it has not been shown as a working exploit against a live cloud provider’s production environment. The report also doesn’t claim every Linux-based hypervisor configuration is equally exposed. Still, the underlying flaw sits in shared kernel networking code rather than any single hypervisor’s implementation, which is exactly what makes it concerning for cloud operators running untrusted workloads side by side.

Which Kernels Are AffectedThe bug spans a wide range of long-term kernel branches. Fixed versions have been published for each affected line:

5.10 branch — fixed in 5.10.272

5.15 branch — fixed in 5.15.223

6.1 branch — fixed in 6.1.190

6.6 branch — fixed in 6.6.159

6.12 branch — fixed in 6.12.113

6.18 branch — fixed in 6.18.57

7.2 branch — fixed in 7.2.11

7.3 development series — fixed ahead of 7.3-rc7

The upstream patch adds a validation step before certain checksum-completion operations, confirming that the checksum start offset doesn’t fall inside the IPv4 header before allowing the write to proceed. Developers describe it as a defense-in-depth measure rather than a complete overhaul of how packet metadata is validated on input, so further hardening work may follow.

How the Bug SurfacedPwnEscape wasn’t found through routine kernel auditing — it emerged from Vercel’s $1 million Sandbox security challenge, a bug bounty built specifically to stress-test the company’s workload isolation. Yibelo reported the kernel flaw on just the third day of the two-week event, working from a standard sandbox environment with no special access. Vercel has called it the program’s single most important finding; across the full challenge, researchers submitted 1,285 reports and collected a combined $242,000 in bounties, with PwnEscape standing as the only critical-rated submission.

It’s not an isolated data point either. The same research community has recently surfaced a separate KVM escape issue and a distinct Linux vhost flaw with its own public proof-of-concept — different bugs, different root causes, and defenders shouldn’t assume a fix for one covers the others.

What Defenders Should DoFor organizations running virtual machines on Linux hosts — especially cloud providers and anyone hosting untrusted or multi-tenant workloads — the priority is straightforward:

Check your Linux distribution’s security advisories rather than relying on a raw version number, since vendors frequently backport fixes to older kernel releases.

Confirm the running kernel includes the checksum-validation fix described in the upstream commit for your branch.

Prioritize patching on hosts that run guest workloads from external or lower-trust tenants.

Continue monitoring for related findings, since this class of networking-stack bug appears to be an active area of research right now.

PwnEscape is a useful case study in how virtualization security really works in practice: isolation guarantees rest not just on the hypervisor, but on every piece of host operating system code a guest’s traffic touches along the way. When a check made early in packet processing no longer matches what a later stage of the kernel actually sees, that gap is exactly what attackers go looking for.

Read Time:3 Minute, 33 Second

A prompt sent to a public-facing artificial-intelligence agent could once have become a route into other Amazon Bedrock AgentCore resources in the same AWS account and region, according to research from Zenity Labs. The attack chain, called AgentCorruption, illustrates how ordinary agent capabilities can combine into a serious cloud-security failure even when the chat interface itself contains no traditional software vulnerability.

The researchers said the chain exposed private conversations, source code, persistent memory, API keys, OAuth tokens, and values stored in AWS Secrets Manager. AWS has since changed relevant defaults and removed broad permissions identified during disclosure. The episode nevertheless offers an important design lesson: an AI agent is both an application that interprets untrusted language and a cloud workload that may hold powerful credentials.

From an untrusted prompt to workload credentialsAgentCore provides managed infrastructure for creating and operating AI agents. Zenity found that an agent equipped with a web-request or shell tool could be instructed to contact the link-local metadata address at 169.254.169.254. Because the request originated inside the agent’s Firecracker microVM, the metadata service returned temporary credentials associated with the runtime’s execution role.

This amounted to a prompt-driven server-side request forgery path. The model followed an instruction using a capability developers had intentionally provided; the danger came from the destination it could reach and the authority attached to the resulting credentials. Untrusted input, unrestricted network access, and an overpowered role turned a useful tool into a cloud-control channel.

Zenity reported the metadata behavior in December 2025 and raised the wider role-permission issue in January 2026. AWS moved new deployments to the more defensive IMDSv2 flow in February and subsequently required it. By late September, the researchers confirmed that AWS had removed permissions enabling broad agent invocation, conversation access, and Secrets Manager access.

Shared permissions widened the blast radiusThe stolen role was especially consequential because, according to the researchers, its default permissions were not confined to a single agent. They used log-discovery capabilities to identify agent IDs, retrieved container images from Amazon Elastic Container Registry, invoked internal agents, and inspected session events.

Permissions related to AgentCore runtimes and events could expose chats or allow fabricated memories to be inserted. Persistent memory creates a particularly subtle risk: malicious instructions stored today may influence an agent during later conversations, after the original prompt and attacker are no longer visible. Access to resource API keys and Secrets Manager could also turn one compromised agent into a bridge toward connected business services.

AWS disputed describing the behavior as a vulnerability. The company noted that software running within a microVM can access the execution role credentials by design and that cross-account access still requires permissions on both the role and the target. That distinction matters, but it does not remove the customer-side risk created by excessive privilege or by tools that let untrusted prompts reach sensitive network locations.

Controls for production AI agentsCreate a custom IAM role for every production agent and restrict actions to named resources instead of using wildcards.

Block unnecessary outbound destinations, especially metadata and internal management endpoints.

Separate internet-facing agents from internal agents that can reach sensitive data or actions.

Validate tool inputs and route access through controlled gateways that callers cannot bypass.

Monitor CloudTrail and CloudWatch for unusual runtime invocations, secret retrieval, event creation, and image access.

Prompt filtering alone is not a sufficient boundary because models can be manipulated in ways that are difficult to predict exhaustively. The stronger approach assumes that an agent will eventually receive a hostile instruction and limits what its identity, tools, and network position can do when that happens.

Treat agents as privileged workloadsOrganizations should inventory each agent’s tools, credentials, data stores, network routes, and persistent memory. Reviews should occur before deployment and whenever a tool or integration is added, because a seemingly modest capability may compose with existing permissions in unexpected ways.

AgentCorruption demonstrates a recurring pattern in AI security: the model need not “break out” through a novel exploit if developers already gave it access to the pieces needed for an attack chain. Least privilege, isolation, observable tool use, and explicit trust boundaries remain the most dependable defenses.