The LeRobot library is vulnerable to arbitrary code execution via unsafe dynamic class instantiation in the from_pretrained() method and related paths. When loading a policy's processor configuration from a repository, the library uses the class field within the JSON configuration to dynamically resolve and instantiate Python classes using importlib.import_module() and getattr().
A security flaw has been discovered in TOTOLINK A950RG 4.1.2cu.5268_B20221104. Affected by this issue is the function sub_402340 of the file infostat.cgi of the component Device-Information CGI. Performing a manipulation of the argument CONTENT_LENGTH results in stack-based buffer overflow. Remote exploitation of the attack is possible. The exploit has been released to the public and may be used for attacks.
Datadog dd-trace-py is the Datadog Python APM client. From 3.13.0 until 4.15.5, the IAST string-processing instrumentation does not properly handle certain internal errors while old-style % string formatting processes attacker-controlled input. An unhandled error can terminate the Python process and interrupt the work it is handling. Exploitation requires IAST to be enabled, which is not the default, and application code to apply the affected formatting operation to attacker-controlled input. This issue is fixed in version 4.15.5.
Datadog dd-trace-py is the Datadog Python APM client. From 1.5.0 until 3.19.9 and 4.15.6, the default query-string obfuscation regular expression can exhibit excessive backtracking while synchronously processing attacker-controlled URL query strings for HTTP span metadata. A remote attacker can cause prolonged CPU consumption, request latency, and service unavailability in affected HTTP tracing integrations that include query strings in URL span tags. The vulnerable processing is enabled by default for those integrations. This issue is fixed in versions 3.19.9 and 4.15.6.
A vulnerability was identified in TOTOLINK A950RG 4.1.2cu.5268_B20221104. Affected by this vulnerability is the function getLanguageCfg of the file global.so. Such manipulation of the argument token leads to information disclosure. The attack may be launched remotely. The exploit is publicly available and might be used.
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.