Patching Vertex AI Workbench for CVE-2026-99999

Short version

CVE-2026-99999, nicknamed PwnEscape, is a flaw in the Linux kernel IPv4 stack. Malformed checksum offload metadata can overwrite an IPv4 header the kernel has already processed. The researcher showed a host kernel memory leak, a crash and code execution as root in a lab. The upstream fix (commit 6785011f8b16) was merged on 14 October 2026. The Linux kernel CVE team rates it Critical and Red Hat rates it Important.

This note is about the kernel inside your own Workbench instances. It says nothing about Google’s infrastructure. Anyone who can run code in a notebook is a local user on that VM, and a local attacker can reach this bug. The risk is privilege escalation to root on the instance, and root on the instance can use whatever the instance service account can use.

Patch status. We checked the Workbench release notes on 31 October 2026 (entries up to 26 October). They do not mention CVE-2026-99999 or a kernel update, and we did not find a Google Cloud security bulletin for it. That means “not listed”, not “not fixed”. Check your own instances.

Check an instance

On the instance, look at the kernel and the OS release:

uname -r
cat /etc/os-release
apt-get update && apt list --upgradable 2>/dev/null | grep linux-image

Compare the kernel with your distribution’s tracker. For Debian, the fixed versions are:

Release	Fixed kernel package
bookworm (security)	linux 6.1.190-1
bookworm (security)	linux-6.12 6.12.113-1~deb12u1
trixie (security)	linux 6.12.113-1

Two ways to patch, and where each one fails

A. Upgrade the Workbench instance. This replaces the boot disk with the newest image and keeps /home/jupyter. It only helps once the newest image contains a fixed kernel, and Google’s notes do not confirm that yet. It also needs a dual disk instance, it needs the instance to be running, and it removes OS packages you installed on the boot disk. Take a backup first.

gcloud workbench instances check-instance-upgradability INSTANCE --location=ZONE
gcloud workbench instances upgrade INSTANCE --location=ZONE

B. Patch the OS inside the instance. Update the packages and reboot. It works today, and it is the only option when the image does not have the fix yet.

sudo apt-get update && sudo apt-get dist-upgrade -y
sudo reboot

The gap: stopped instances are never patched

Workbench can upgrade an instance on a schedule. The schedule is the notebook-upgrade-schedule metadata key in unix cron format, in GMT. Google’s documentation says scheduled upgrades do not run on stopped instances, and that an instance can only be upgraded while it is running.

Most teams stop notebooks at night or after idle shutdown to save money. Those instances can sit on an old kernel for weeks, then someone starts one and works on it with production data.

Automation for stopped instances

The idea is simple. Once a week, start every stopped instance, check it, upgrade it if there is something to upgrade, and stop it again. The script below is a starting point. It has not been run against your project, so test it on a non-production instance first.

#!/usr/bin/env bash
# Draft. Test on one non-production instance first.
set -euo pipefail

PROJECT="${PROJECT:?set PROJECT}"
LOCATIONS="${LOCATIONS:?set LOCATIONS, for example 'europe-west4-a us-central1-a'}"

for LOC in $LOCATIONS; do
  gcloud workbench instances list --project "$PROJECT" --location "$LOC" \
    --format="value(name.basename(),state)" | while read -r NAME STATE; do

    WAS_STOPPED=false
    if [ "$STATE" = "STOPPED" ]; then
      WAS_STOPPED=true
      gcloud workbench instances start "$NAME" --project "$PROJECT" --location "$LOC"
    fi

    # Only upgrade when Google offers a newer image for this instance.
    if gcloud workbench instances check-instance-upgradability "$NAME" \
         --project "$PROJECT" --location "$LOC" --format="value(upgradeable)" | grep -qi true; then
      gcloud workbench instances upgrade "$NAME" --project "$PROJECT" --location "$LOC"
    fi

    # Put the instance back the way we found it.
    if [ "$WAS_STOPPED" = true ]; then
      gcloud workbench instances stop "$NAME" --project "$PROJECT" --location "$LOC"
    fi
  done
done

To run it every week without a machine of your own, package it as a Cloud Run job and trigger it with Cloud Scheduler:

1. Create a service account for the job and give it only what it needs to list, start, stop and upgrade Workbench instances.
2. Build the script into a container image based on the Google Cloud CLI image and create the job with gcloud run jobs create.
3. Create a Cloud Scheduler job, for example 0 3 * * 0, that calls the Cloud Run job’s :run endpoint with that service account.

A few things to decide before you roll it out:

• Order of operations. Upgrade replaces the boot disk, so do not run it against an instance that someone is using. Run it at night and skip instances that were active in the last hours.
• Data. Anything outside /home/jupyter and anything you installed on the boot disk is not kept. Make --user pip installs and a bootstrap script the standard.
• Visibility. Send the job’s result to Cloud Logging and alert on failures. A patch job nobody watches is the next forgotten server.

How we can help

We build this kind of fleet hygiene for AI platform teams: patching, idle shutdown, cost labels and guardrails for notebooks on Google Cloud. If you want it running in your project, book a call from the button below.