PatchDayAlert
Subscribe →
Daily Digest · 2 min read · 5 CVEs · Issue 46 By PatchDayAlert

Keycloak token forgery, KubeVirt auth bypass, and a 9.1 Perl heap read

Keycloak's JWT algorithm confusion lets attackers impersonate any federated user (CVE-2026-11800, CVSS 8.1). KubeVirt's disableTLS flag silently strips all migration auth, exposing raw libvirt RPC to the pod network (CVE-2026-13325, CVSS 8.5). Apicurio Registry has two SSRF bugs, and Perl's Socket module has a 9.1 heap read with near-zero exploit probability.

Patch now
0
Within 24h
3
This week
2
Exploited
0
PerlPerl SocketAzure LinuxLinuxApicurio RegistryRed HatCloudKeycloakKubeVirtKubernetes

Nothing's on fire, but the stack is tall. A CVSS 9.1 out-of-bounds heap read in Perl's Socket module (CVE-2026-12087) tops the list, though real-world exploitation looks unlikely right now: EPSS is just 0.004. Behind it sit an XXE in Apicurio Registry, a JWT bypass in Keycloak, and a nasty KubeVirt auth-stripping surprise. All 5 are unpatched-in-the-wild, so you've got breathing room, but a few of these deserve a closer look today.

Today's CVEs

Sorted by urgency

01

CVE-2026-12087

MSRC
9.1
CVSS EPSS 0.39%
Patch this week CRITICAL
PerlPerl SocketAzure LinuxLinux

The Perl Socket module (before 2.041) has an out-of-bounds heap read. An attacker could potentially use this to leak sensitive memory contents or crash a Perl process. CVSS is 9.1, but the EPSS score is very low (0.004, 31st percentile), so real-world exploitation isn't expected soon.

Affected estate
Anyone running Perl 5.38.2 on Azure Linux 3.0 (azl3), or any system with the Socket module below version 2.041.
How to check
Run: perl -MSocket -e 'print $Socket::VERSION' and confirm the version is below 2.041.
Included because
CVSS 9.1; common scripting runtime; Azure Linux specific advisory
Action
Update the perl package to the patched version via tdnf or your package manager.
Why it matters
A heap out-of-bounds read can leak memory or crash services that rely on Perl's Socket module.
Source
NVD

Evidence trail

02

CVE-2026-12975

NVD
8.5
CVSS
Patch within 24h HIGH
Apicurio RegistryRed HatLinuxCloud

Apicurio Registry's XML parsing doesn't disable external entity resolution. An attacker who can upload artifacts (which is anyone by default, since the registry ships with no auth) can submit a crafted XML document to trigger blind SSRF, hitting internal services from the registry's network position. They can also cause denial of service through entity expansion (a.k.a. "billion laughs").

Affected estate
Anyone running Apicurio Registry, especially with default (unauthenticated) configuration exposed to untrusted users.
How to check
Check your Apicurio Registry version. If you're running default configuration, confirm whether unauthenticated artifact uploads are allowed.
Included because
unauthenticated by default; SSRF to internal network; CVSS 8.5; denial of service risk
Action
Upgrade Apicurio Registry to the patched release. As a mitigation, enable authentication and restrict write permissions.
Why it matters
Unauthenticated SSRF lets attackers probe your internal network from the registry host, and entity expansion can take the service down.
Source
Red Hat advisory

Evidence trail

03

CVE-2026-11800

NVD
8.1
CVSS
Patch within 24h HIGH
KeycloakRed HatLinuxCloud

Keycloak has a JWT algorithm confusion bug in its JWT Authorization Grant flow. An attacker who holds valid client credentials can forge assertions that bypass signature verification, letting them mint access tokens for any federated user tied to the affected Identity Provider. That means full user impersonation and potential privilege escalation.

Affected estate
Anyone running Keycloak with federated Identity Providers using the JWT Authorization Grant flow.
How to check
Check your Keycloak version and review your realm configuration for Identity Providers using JWT grant flows.
Included because
authentication bypass; user impersonation; CVSS 8.1; common IAM product
Action
Upgrade Keycloak to the fixed version. Audit recent token grants for anomalies.
Why it matters
An attacker with only client credentials can impersonate any federated user, which is a full authentication bypass for those accounts.
Source
Red Hat advisory

Evidence trail

04

CVE-2026-13325

NVD
8.5
CVSS
Patch within 24h HIGH
KubeVirtKubernetesLinuxCloud

When you set disableTLS to true on a KubeVirt custom resource, the migration proxy binds a plain TCP listener on all interfaces with zero authentication. Any pod on the cluster network can connect and send raw libvirt RPC commands against another tenant's VM. That includes reading VM memory, changing VM state, or destroying VMs entirely. The setting's own docs only mention losing encryption, not that it also strips all authentication. Even if you configure a dedicated migration network, the listener still binds on 0.0.0.0, so it's reachable from the pod network regardless.

Affected estate
KubeVirt operators who have set spec.configuration.migrations.disableTLS to true on any cluster, including those with a dedicated migration network configured.
How to check
Run: kubectl get kubevirt -A -o jsonpath='{.items[*].spec.configuration.migrations.disableTLS}' and check for 'true'.
Included because
no authentication; cross-tenant VM compromise; cluster-network reachable; CVSS 8.5; misleading vendor documentation
Action
Set disableTLS to false (or remove the field) on your KubeVirt CR to restore mutual TLS authentication. Upgrade KubeVirt when the fix is released.
Why it matters
Any pod on the cluster network can take full control of another tenant's VM: read memory, modify state, or destroy it.
Source
KubeVirt advisory

Evidence trail

05

CVE-2026-12992

NVD
7.4
CVSS
Patch this week HIGH
Apicurio RegistryRed HatLinuxCloud

Apicurio Registry's WSDL parser doesn't disable document imports, so when the VALIDITY rule is set to FULL, an attacker with Developer-role access can upload a WSDL file with attacker-controlled import URLs. The registry then fetches those URLs server-side, giving the attacker SSRF access to your internal network.

Affected estate
Anyone running Apicurio Registry with the VALIDITY rule set to FULL and users who have Developer-role access.
How to check
Check your Apicurio Registry version and review global/artifact rule configuration for the VALIDITY rule setting.
Included because
SSRF; requires Developer role (not unauthenticated); CVSS 7.4; requires FULL validity config
Action
Upgrade Apicurio Registry. If you can't patch right away, change the VALIDITY rule away from FULL or tighten role assignments.
Why it matters
SSRF from the registry host lets an attacker with Developer access probe internal services that should never be externally reachable.
Source
Red Hat advisory

Evidence trail

One email, every Wednesday morning.

Subscribe

From the field notes

From this beat

Read the rest of the field notes →