Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.6, go-jose parses attacker-controlled RSA modulus and prime values from JWKs without enforcing size and consistency bounds before passing them to crypto/rsa.PrivateKey.Validate. On Go 1.24 and later, crafted large or degenerate RSA parameters can make that validation consume cubic CPU time, allowing remote denial of service in applications that parse JWKs from untrusted sources. This issue is fixed in version 4.1.6.
Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.5, parsing attacker-controlled JSON through go-jose allows deeply nested arrays or objects to exceed Go's stack limit. The resulting stack overflow crashes the application and permits denial of service in applications that parse untrusted JSON through go-jose. This issue is fixed in version 4.1.5.
Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.5, decrypting untrusted JWE ciphertext with A128CBC-HS256, A192CBC-HS384, or A256CBC-HS512 can pass an empty ciphertext buffer to CBC-HMAC unpadding. Insufficient validation allows the empty buffer to be indexed, causing a panic and denial of service. Applications that decrypt attacker-controlled ciphertext with one of these content-encryption algorithms are affected. This issue is fixed in version 4.1.5.
Two vulnerabilities (CVE-2023-1017 and CVE-2023-1018) were discovered in the Trusted Platform Module (TPM) 2.0 implementation on certain Google Compute Engine VMs. These vulnerabilities involve a 2-byte out-of-bounds read/write in the vTPM parameter decryption routine. CVE-2023-1017 could allow a local attacker to cause denial-of-service or possibly execute arbitrary code within the vTPM context. CVE-2023-1018 could allow a local attacker to leak limited data from the vTPM context. Google has automatically applied patches to all vulnerable VMs, and no customer action is required.
Multiple vulnerabilities affecting AMD EPYC server CPUs based on Zen 2 (Rome), Zen 3 (Milan), and Zen 4 (Genoa) core generations were disclosed by AMD in November 2023. Google has applied fixes to its infrastructure, including Google Cloud and Compute Engine, to protect customers. No evidence of exploitation has been reported. Customers using Google Cloud services do not need to take any action as mitigations are already in place.
Several vulnerabilities were discovered in the TianoCore EDK II UEFI firmware used in Google Compute Engine VMs. These vulnerabilities could allow an attacker to bypass secure boot, resulting in false measurements during the secure boot process, including when used in Shielded VMs. Google has patched these vulnerabilities across Compute Engine, and all VMs are now protected. No customer action is required.
CVE-2024-3094 is a vulnerability affecting versions 5.6.0 and 5.6.1 of the xz-utils package in the liblzma library, which could lead to compromise of the OpenSSH utility. Google Cloud Compute Engine public images are not affected by this vulnerability. However, custom VM images built using affected versions of xz-utils, such as those based on Fedora 41, Fedora Rawhide, Debian testing/unstable, and openSUSE tumbleweed, could be at risk. Users with such custom images should stop affected VMs and verify with their OS vendors for patches or mitigations.
A critical vulnerability (CVE-2024-6387) in OpenSSH allows remote unauthenticated attackers to execute arbitrary code as root on affected machines. This affects Compute Engine VMs running glibc-based Linux distributions with OpenSSH exposed, as well as Google TPU and Container-Optimized OS versions. The vulnerability can be mitigated by applying patches from Linux distributions or Google-provided updated OS images. Runtime mitigation is also available by setting LoginGraceTime to 0 in sshd_config and restarting the sshd service. Additionally, restricting SSH access via firewall rules to trusted networks or disabling SSH until patched reduces exposure.
A speculative execution vulnerability (CVE-2024-28956) affecting Intel Cascade Lake and Ice Lake processors has been identified. Google has applied mitigations across its infrastructure, including Google Cloud, to protect customers. No evidence of exploitation has been reported. Additional mitigations from Intel OEMs and OS partners are forthcoming. Customers do not need to take action at this time. Some performance degradation may occur on long-running 3rd generation or later VMs after OS-level mitigations are applied.
A side channel vulnerability (CVE-2024-45332) affects multiple Intel Xeon processors including CascadeLake, Ice Lake XeonSP, Ice Lake XeonD, Sapphire Rapids, and Emerald Rapids. Google has applied fixes to its infrastructure, including Google Cloud, to protect customers. No evidence of exploitation has been reported. No customer action is required as the mitigation is already in place.
A vulnerability in the Trusted Platform Module (TPM) software affects Shielded VMs using virtual TPM (vTPM). An authenticated local attacker with access to the vTPM interface can send malicious commands exploiting an out-of-bounds memory read, potentially exposing sensitive vTPM data or impacting vTPM availability. Google will proactively update affected systems during standard maintenance windows, and no customer action is required. Limiting vTPM access to administrative users can help reduce risk.
Two new vulnerabilities affecting specific Intel processors have been identified. CVE-2025-21090 allows an unprivileged actor using the AMX and AVX CPU instructions to render the host machine inoperative. CVE-2025-22840 allows an unprivileged actor using the prefetchit CPU instruction to access memory contents without authorization, potentially leading to remote code execution. Google has stated no customer action is required as they will update systems during planned maintenance windows. No evidence of exploitation has been reported.
A vulnerability has been identified in the RDSEED instruction on AMD Zen 5 (Turin) processors. The 16- and 32-bit versions of the RDSEED instruction can silently fail under certain system load conditions, potentially compromising applications that rely on these instructions for cryptographic random number generation. The 64-bit version of RDSEED is not affected and remains safe. AMD is currently investigating this issue. The 64-bit Linux kernel uses the safe 64-bit RDSEED instruction for /dev/[u]random, so those random numbers are not impacted. Applications that synthesize random numbers using the 16- or 32-bit RDSEED instructions should be aware of this insecurity.
A vulnerability in the CPP RCTX instruction on select Arm processors used in Google Cloud Compute Engine Arm VMs (C4A, A4X) allows an attacker with privileged guest kernel access to inhibit TLB invalidations. This can potentially enable unauthorized reading of sensitive data. Google has already applied mitigations to the affected Arm server fleet, and no customer action is required.
A vulnerability identified as CVE-2026-23268, known as CrackArmor, exists in the Linux kernel's AppArmor component on Container-Optimized OS (COS) nodes. This flaw allows unprivileged users to bypass kernel protections, escalate privileges to root, and break local container isolation. The vulnerability is rated high severity. Google recommends upgrading COS nodes to version cos-125-19216-220-57, which contains the fix. For managed services using COS, users should follow the respective upgrade instructions. Fixes for earlier COS milestones 117 and 121 are in progress.
A vulnerability in AMD firmware could allow a malicious hypervisor to alter BIOS settings and Memory Mapped I/O (MMIO) routing configurations, compromising the confidentiality and integrity of Confidential VMs using AMD SEV-SNP guests. Google has implemented mitigations for this issue in Confidential VM instances with AMD SEV-SNP. No customer action is required. The vulnerability is documented as CVE-2025-54510 and is rated medium severity.
A vulnerability in AMD firmware allows a malicious hypervisor to execute arbitrary code on the AMD Secure Processor (ASP), escalating Memory Mapped I/O (MMIO) read and write permissions. This compromises the confidentiality and integrity of SEV-SNP guests. Google has applied mitigations to Confidential VM instances with AMD SEV-SNP, and no customer action is required.
A hardware-level vulnerability has been identified in AMD Zen 2 microarchitecture processors, including EPYC and Ryzen series, involving potential corruption within the micro-operation (OP) cache. Under specific conditions, this flaw (CVE-2025-54518) could allow security boundary bypasses or unauthorized data access. Google has deployed fixes across its infrastructure to mitigate this issue.
CVE-2025-10263 is an architectural vulnerability in certain Arm cores (Neoverse V1, V2, N1) used in Google Cloud Arm-based instances. It allows an attacker at a lower exception level to write to memory owned by a higher exception level, enabling privilege escalation. This flaw does not affect memory reads. Google has secured the infrastructure against VM-to-VM and VM-to-hypervisor attacks, but guest OS-level patches from OS vendors are required to mitigate threats within the guest environment. Mitigations for Container-Optimized OS are in progress.
A vulnerability (CVE-2026-6726, also known as TCGVRT0010) has been identified in the Trusted Computing Group's TPM 2.0 reference implementation code, affecting all published revisions of the code (v1.16, v1.38, v1.59, v1.83, v184). This flaw could allow a privileged local attacker to obtain credentials from a TPM-aware Certificate Authority for a falsified TPM key, enabling the creation of fraudulent TPM 2.0 attestations. Google will proactively update affected systems during standard maintenance windows, and no customer action is required.