PwnEscape: How rogue cloud VMs could hack their hosts

Another BWAIN for the books

This one is a brand new BWAIN, or Bug With An Impressive Name, which also has the memorable bug identifier CVE-2026-99999.

The media friendly name is PwnEscape, where “escape” denotes both privileged data leaking out of a host server into one or more virtual machines that it controls (VMs, or guests), and malicious code being injected into the host from one of those guests.

According to the researchers who uncovered this bug, it was introduced into the Linux kernel almost exactly 17 years ago, but lay (as far as we know) entirely unnoticed until just over a month ago.

The reseachers have already published what they call Part 01 of their exploit, covering a description and an explanation of the data leakage part of this vulnerability.

In contrast, they have briefly described, but not explained or provided any code or even pseudocode for, Part 02.

That’s where a guest VM could inject unauthorized code directly into the kernel of the host server, even though the host OS is supposed to keep each VM strictly separate from every other, and all the VMs strictly separate from the host.

We assume that the reason for delaying Part 2 was to prevent every Tom, Dick, and Harriet from jumping on the bandwagon of breaking out of guest VMs across the online Linux universe, and blithely hacking our cloud ecosystem for money, influence, or lulz.

A holy grail

So-called guest escapes of this sort are a kind-of holy grail for security researchers and cybercriminals alike.

That’s because guest-to-host remote code execution holes (RCEs) are a class of threat that analysts, auditors and risk managers often put into the “let’s assume this will never happen” basket, given how much of our current infrastruture is predicated upon that assumption being true, and given that the assumption does indeed hold most of the time.

If you’re a LinkedIn user and you’re not yet following @SolCyber, do so now to keep up with the delightfully useful Amos The Armadillo’s Almanac series. SolCyber’s lovable mascot Amos provides regular, amusing, and easy-to-digest explanations of cybersecurity jargon, from MiTMs and IDSes to DDoSes and RCEs.

Even if you know all the jargon yourself, Amos will help you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.

Loosely speaking, almost the entire security premise and promise of cloud-based VMs is that a single physical host split by software into, say, 128 virtual servers․․․

․․․should be considered operationally equivalent to having 128 physically separate physical servers, on separate networks, in separate server rooms, in a flashback of simplification in which we pretend it’s still 1999.

For context, the top hit in 1999 was Cher’s Believe, which can be considered the agentic AI surprise of its era, exposing and popularizing as it did the love-it-and-hate-it-at-the-same-time musical “cheat engine” known as Auto-Tune.

The first exploit is worrying enough on its own, because it is surprisingly similar in side-effect and risk to the notorious Heartbleed vulnerability of 2014, where unpatched web servers could be tricked into repeatedly leaking small chunks of other users’ browsing data, or even cryptographic keys held by the server itself, in fragments of up to 64,000 bytes of RAM at a time.

In PwnEscape, only 32 bytes at a time can be leeched by an untrusted guest OS from the affected host, but the stolen data comes not from a single application on the server, as in Heartbleed, but right from from the innards of the host OS kernel.

Of course, while data leakage from a host server is bad enough, virtual guests implanting malware in the host OS kernel is a modern-day security nightmare, not least because:

• Many, if not most, cloud service instances run as VMs, where host servers inside super-sized data centers each pretend to be anywhere from 2 to 200 or more separate servers or desktops, each running code and processing data for different users.
• Many, if not most, data center host servers support not only numerous different services, such as multiple web servers for different departments in the same global company, but also multiple different customers at the same time, such as virtual desktop computers for many unrelated businesses, perhaps in several different state or national jurisdictions.

Check now, do the work later

The CVE-2026-99999 bug comprises two different types of software abuse, as described above, enabled by a low-level Linux IPv4 networking code feature in the kernel that we’ll refer to as CHECKSUM_PARTIAL.

This “feature” was introduced back in kernel 2.6.27, released in October 2008, when even new kernel point releases (where only the last of the three dot-separated numbers changes) were sufficiently unusual and infrequent as to get their own news writeups.

IPv4 network packets consist of a header, in practice usually 20 bytes long but in theory up to 60 bytes long, and this header includes a trivial checksum to help the network stack discard packets that were corrupted in transit.

The checksum is literally that, a 16-bit “check sum” based simply on adding all the 16-bit words in the header together, so it has limited safety value and no security value at all.

Checksums got their name from the simple repeated addition that made them practicable even on the earliest processors. But add-up-in-strict-sequence checksums miss common errors, such as swapped bytes, because B+A = A+B, or bytes where one is incremented and another decremented, because (A+1)+(B-1) = A+B, and many similar corruptions. When IPv6 came along, it got rid of the header checksum as an unnecessary complication.

The problem is that an IP header keeps changing as the packet proceeds through the network, both as it hops from computer to computer on its way, and inside the kernel’s own network stack during delivery.

For example, the header includes a “hops left until the packet should be discarded because it seems to have got lost” counter known rather quaintly as the TTL, or time to live, and every change in the TTL requires the checksum to be recalculated.

As the name suggests, CHECKSUM_PARTIAL is a flag that can be set on a packet passing through the kernel to denote, loosely speaking, “Don’t worry about updating the checksum yet, because it’s going to change in a moment anyway, so calculate it at the end, when it’s no longer still hopping around from pillar to post.”

The two-fold flaw that the researchers found turned out to be what’s known in the jargon as a TOCTOU bug, short for time-of-check/time-of-use.

Many a slip ‘twixt cup and lip

The kernel code for CHECKSUM_PARTIAL keeps a record of where in an unchecksummed packet the final checksum needs to be written, because IPv4 packets in transit may have additional data fields, known as metadata, prepended to them, which means that the header itself isn’t always at the same offset from the start of the buffer in every packet that arrives.

The code also checks up front, for safety and sencurity reasons, that the final checksum, when known, will indeed land in the IPv4 header, to prevent corrupted or deliberately malformed data from triggering out-of-bounds reads and writes, or buffer overflows (or underflows) in the jargon.

Unfortunately, however, both the check itself and the calculation of the memory addresses, which together denote “where and what to read in” later on, and “where to write the final checksum,” are based on the structure of the packet buffer at the start of its journey through the kernel.

By the time the packet has been processed through the kernel and the final checksum computed, both the raw IPv4 data in the kernel buffer, and the size of the header denoted in the IPv4 data itself, may have changed.

Those changes are affected, and indeed can be manipulated by, the network-handling code inside the guest VM server, which an attacker can control.

When the host server itself comes to finalize that CHECKSUM_PARTIAL, it might already have been lured into making either or both of the aforementioned memory mismanagement blunders by using the following tricks:

• Mislead the host into copying 40 extra bytes of raw IPv4 data into the final network packet to be delivered. An attacker starts out by creating an IPv4 packet with a 20-byte header, but sneakily changes it to a 60-byte header along the way. Because of how the kernel’s network buffers are implemented, both in the guest VM and the host, the first 8 of those now-misaligned bytes just happen to be data that originated in the guest VM, so the new packet is incorrectly formed but doesn’t contain any data that wasn’t already present in the guest VM. But the next 32 bytes are a more-or-less random chunk of bytes from some other part of the host server’s kernel memory. Those 32 bytes therefore bleed out of the host’s kernel and end up in a guest VM’s memory.
• Misalign the host’s view of its data so its saved memory offsets are incorrect.. Altering the prepended metadata in the network packet as it progresses means that the memory addresses recorded in the host kernel for writing out the new network data and its final checksum will now be wrong. Choose that “wrong location” as carefully as you can, in the hope that the network driver in the host kernel doesn’t merely crash (which would cause a DoS, or denial of service), but jumps into program code that you deliberately implanted into the injected data, thereby poking malware directly into the host server from a guest VM and executing it.

RCE guest escape achieved; holy grail found!

Of course, the second part is more easily described in theory than achieved in real life, and the practical implementation of the RCE phase of the attack is the section that the researchers have deferred until they decide to publish Part 02, by which time we should all have had plenty of time to patch.

Unless, as the report wrly notes, things don’t pan out that way:

Part 2 of pwnescape will deal with what it took to move from the [data-stealing] primitive [of part 1] to host control, rather than pretending that a 32-byte disclosure trivially becomes code execution, if the security community doesn’t beat us to it.

What to do?

If you’re a programmer, and you are about to process untrusted data, you really do need to verify your input up front before you accept it.

But if there is any chance that the data might change while you’re still waiting to work on it, don’t forget to verify it again at the end.

Don’t leave a potentially exploitable gap between the TOC (time of check) and the TOU (time of use).

If you’re a Linux sysadmin, update to a patched kernel as soon as you can.

And if you’re struggling to keep up with threats, to find and apply all needed patches, and to fight attacks on your own, or you simply want to free yourself up to focus on your core business, which probably isn’t cybersecurity, why not sign up with SolCyber to take care of things for you?

The CVE-2026-99999 hole arrived in kernel 2.6.27 back in 2008, as mentioned above, and was patched this in the following kernel versions released earlier this week: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, 7.2.11, and even the not-yet-released 7.3-rc7.

Ask how SolCyber can help you do cybersecurity in the most human-friendly way. Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit you or your business!

More About Duck

Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!