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.
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 urgencyCVE-2026-12087
MSRCThe 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.
- Included because
- CVSS 9.1; common scripting runtime; Azure Linux specific advisory
- Affected estate
- Azure Linux 3.0 hosts running perl 5.38.2-509 or any system with the Perl Socket module below 2.041.
- How to check
- Run: perl -MSocket -e 'print $Socket::VERSION' and confirm the version is below 2.041.
- Action
- Update the perl package to the patched version via tdnf or your package manager.
- Urgency
- Patch this week
- 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
- NVD: View source
CVE-2026-12975
NVDApicurio 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").
- Included because
- unauthenticated by default; SSRF to internal network; CVSS 8.5; denial of service risk
- Affected estate
- Apicurio Registry instances, all versions prior to the fix. Default installs are unauthenticated.
- How to check
- Check your Apicurio Registry version. If you're running default configuration, confirm whether unauthenticated artifact uploads are allowed.
- Action
- Upgrade Apicurio Registry to the patched release. As a mitigation, enable authentication and restrict write permissions.
- Urgency
- Patch within 24 hours
- 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
- NVD: View source
CVE-2026-11800
NVDKeycloak 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.
- Included because
- authentication bypass; user impersonation; CVSS 8.1; common IAM product
- Affected estate
- Keycloak instances configured with federated Identity Providers that use JWT Authorization Grants.
- How to check
- Check your Keycloak version and review your realm configuration for Identity Providers using JWT grant flows.
- Action
- Upgrade Keycloak to the fixed version. Audit recent token grants for anomalies.
- Urgency
- Patch within 24 hours
- 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
- NVD: View source
CVE-2026-13325
NVDWhen 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.
- Included because
- no authentication; cross-tenant VM compromise; cluster-network reachable; CVSS 8.5; misleading vendor documentation
- Affected estate
- KubeVirt clusters 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) on your KubeVirt CR to restore mutual TLS authentication. Upgrade KubeVirt when the fix is released.
- Urgency
- Patch within 24 hours
- 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
- NVD: View source
CVE-2026-12992
NVDApicurio 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.
- Included because
- SSRF; requires Developer role (not unauthenticated); CVSS 7.4; requires FULL validity config
- Affected estate
- Apicurio Registry instances with the VALIDITY rule configured to FULL.
- How to check
- Check your Apicurio Registry version and review global/artifact rule configuration for the VALIDITY rule setting.
- Action
- Upgrade Apicurio Registry. If you can't patch right away, change the VALIDITY rule away from FULL or tighten role assignments.
- Urgency
- Patch this week
- 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
- NVD: View source
One email, every Wednesday morning.
SubscribeFrom the field notes
From this beat
Read the rest of the field notes โ