KubeVirt live migration opens an unauth backdoor, plus plaintext OAuth tokens in OpenProject
A disabled-TLS footgun in KubeVirt (CVSS 8.5) lets any pod on the cluster network send raw libvirt commands to another tenant's VM. OpenProject stores SharePoint/OneDrive OAuth tokens in plaintext in Rails.cache (CVSS 8.2). Also: a GPU shader compiler OOB write, an Envoy zstd decompression bomb, and a Budibase account-linking CSRF.
Five patches today, nothing exploited in the wild, but the top one deserves your attention. KubeVirt's disableTLS migration flag doesn't just kill encryption: it kills all authentication too, opening a raw libvirt listener on a random port reachable by any pod on the cluster network. If you run KubeVirt with that flag set, fix it now.
Today's CVEs
Sorted by urgencyCVE-2026-13325
NVDWhen you disable TLS for live migrations in KubeVirt (spec.configuration.migrations.disableTLS = true), the target virt-handler opens a completely unauthenticated TCP listener on all interfaces on a random port. Any pod on the cluster network can connect to that listener and send raw libvirt commands against another tenant's VM, including reading memory, changing VM state, or killing it outright. The docs frame disableTLS as just removing encryption, but it actually removes all authentication too, and setting a dedicated migration network doesn't fix the bind address: the port stays reachable on the pod network regardless.
- Included because
- unauthenticated; pod-network reachable; multi-tenant VM workloads; CVSS 8.5
- Affected estate
- Any Kubernetes cluster running KubeVirt where the KubeVirt CR has spec.configuration.migrations.disableTLS set to true.
- How to check
- Run: kubectl get kubevirt -A -o jsonpath='{.items[*].spec.configuration.migrations.disableTLS}' and check for 'true'.
- Action
- Set disableTLS to false (or remove the field) to restore mutual TLS on migration proxy listeners. Monitor for a KubeVirt release that fixes the unauthenticated bind behavior.
- Urgency
- Patch within 24 hours
- Why it matters
- Any pod on the cluster network can issue unrestricted libvirt commands against other tenants' VMs, breaking tenant isolation completely.
- Source
- NVD
Evidence trail
- NVD: View source
CVE-2026-52783
NVDOpenProject's Storages module stores OneDrive/SharePoint OAuth access tokens in plaintext in Rails.cache under a predictable key. None of the supported cache backends (file_store, memcache, Redis) encrypt at rest. If an attacker can read your cache backend (even with a simple anonymous memcached get), they grab a valid Azure AD bearer token and get application-level access to your connected SharePoint/OneDrive.
- Included because
- plaintext credential storage; predictable cache key; unauthenticated cache access possible; CVSS 8.2
- Affected estate
- Self-hosted OpenProject instances prior to 17.3.3 or 17.4.1 with Storages module configured for OneDrive/SharePoint.
- How to check
- Check your OpenProject version in the admin panel or via 'openproject version' on the CLI. Verify whether the Storages module is enabled and connected to OneDrive/SharePoint.
- Action
- Upgrade to OpenProject 17.3.3 or 17.4.1. After upgrading, rotate the Azure AD application client secret and revoke any existing cached tokens. Restrict network access to your cache backend (memcached/Redis).
- Urgency
- Patch within 24 hours
- Why it matters
- An attacker who can reach your cache backend recovers a live Azure AD bearer token and gains full application-tier access to your connected SharePoint or OneDrive.
- Source
- NVD
Evidence trail
- NVD: View source
CVE-2026-21734
NVDA crafted GPU shader embedded in a web page can trigger an out-of-bounds write in the GPU shader compiler. On platforms where the compiler process runs with elevated system privileges, this could lead to further exploitation beyond just a crash. The trigger is a very small value in shader code that causes the compiler to write past its buffer.
- Included because
- remote trigger via web page; no user interaction beyond page visit; potential privilege escalation; CVSS 7.7
- Affected estate
- Systems running browsers or applications that process untrusted GPU shader code. Risk is higher on platforms where the shader compiler runs with system-level privileges.
- How to check
- Verify your browser version and GPU driver version against the vendor's advisory once published. Check whether WebGPU or shader compilation is enabled in browser flags.
- Action
- Apply the vendor's browser or driver update when available. Consider disabling WebGPU in browser settings on sensitive systems as a temporary mitigation.
- Urgency
- Patch this week
- Why it matters
- A malicious web page can crash the GPU compiler or, on certain platforms, escalate to system-level code execution with no user interaction beyond visiting the page.
- Source
- NVD
Evidence trail
- NVD: View source
CVE-2026-48044
NVDEnvoy's zstd decompressor doesn't limit how much memory a highly compressed zstd payload can expand into. An attacker can send a crafted, small zstd payload that decompresses into a massive memory allocation, OOM-killing the Envoy process and taking down your proxy.
- Included because
- unauthenticated; internet-facing proxy; denial of service; common infrastructure component; CVSS 7.5
- Affected estate
- Envoy proxies from version 1.23.0 through unpatched 1.38.0 with zstd decompression configured in the filter chain.
- How to check
- Run 'envoy --version' and check whether your listener or HTTP filter config includes a zstd decompressor filter. Review your Envoy config for 'envoy.filters.http.decompressor' with a zstd library reference.
- Action
- Upgrade to Envoy 1.35.11, 1.36.7, 1.37.3, or 1.38.1. As a temporary workaround, remove or disable the zstd decompressor filter from your config.
- Urgency
- Patch within 24 hours
- Why it matters
- A single crafted request can OOM-kill your Envoy proxy, causing a full denial of service for all traffic flowing through it.
- Source
- NVD
Evidence trail
- NVD: View source
CVE-2026-50132
NVDBudibase has a public, unauthenticated endpoint that permanently links an external chat identity (Slack, Discord, MS Teams) to a Budibase user account. An attacker creates a link token from their own Slack slash command, then tricks an authenticated Budibase user into clicking the URL. The victim's account silently binds to the attacker's chat identity with no consent prompt and no CSRF protection. The page just says "Authentication succeeded" with no indication of what happened.
- Included because
- unauthenticated endpoint; no CSRF protection; social engineering trigger; account takeover; CVSS 7.3
- Affected estate
- Self-hosted Budibase instances prior to 3.39.0 with chat integrations (Slack, Discord, or MS Teams) configured.
- How to check
- Check your Budibase version in the admin settings. Verify whether chat-link integrations are enabled by looking for active Slack/Discord/Teams configurations.
- Action
- Upgrade to Budibase 3.39.0. After upgrading, review chat-link bindings in the database for any unexpected external identity associations and remove suspicious entries.
- Urgency
- Patch this week
- Why it matters
- An attacker can silently hijack a user's account by linking their own chat identity to it, gaining persistent access through the chat integration.
- Source
- NVD
Evidence trail
- NVD: View source
One email, every Wednesday morning.
SubscribeFrom the field notes
From this beat
Read the rest of the field notes โ