CVE-2026-91191 in G520
Summary
by MITRE • 09/30/2026
The device's update mechanism includes conditions that allow unauthorized software packages to be accepted as authentic. During the boot process, the stock done function disables signature verification in the OPKG configuration before restoring optional packages from a writable, unsigned feed. Separately, the publicly distributed SDK contains the production private key whose corresponding public key is trusted by both stable and beta firmware builds. Either issue undermines package authenticity, and together they allow an attacker to provide packages that appear valid to the system. Even if signature enforcement is restored, the exposed production key enables an attacker to generate signatures that the device will continue to trust. An attacker who can supply a malicious package may be able to execute arbitrary code with root privileges during installation.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability described represents a critical failure in the software update and boot integrity mechanisms of the affected device, fundamentally undermining the chain of trust required for secure system operation. The core technical flaw lies in two distinct but compounding issues within the package management infrastructure. First, during the boot process, the stock done function explicitly disables signature verification within the OPKG configuration before proceeding to restore optional packages from a writable feed that lacks digital signatures. This operational decision creates a window of opportunity where unsigned software is accepted as authentic without cryptographic validation. Second, and more severely, the publicly distributed Software Development Kit contains the production private key corresponding to the public keys trusted by both stable and beta firmware builds. The exposure of this private key allows any actor with access to the SDK to generate valid digital signatures for arbitrary software packages, effectively bypassing all integrity checks designed to prevent unauthorized code execution.
The operational impact of these flaws is severe, as they collectively allow an attacker to supply malicious packages that appear entirely legitimate to the device's verification system. Even if the signature enforcement mechanism were theoretically restored or patched in a future update, the compromise of the production private key renders such measures ineffective for existing devices. An adversary can continue to sign malware with the stolen key, ensuring that the device will trust and execute it without raising alarms. This situation effectively nullifies the security guarantees provided by the package signing infrastructure, as the root of trust has been compromised at its source rather than through a flaw in the verification logic itself.
From an attacker's perspective, this vulnerability facilitates arbitrary code execution with root privileges during the installation phase. By crafting a malicious package signed with the exposed production key and supplying it to the device, typically via network access or physical interaction depending on the attack vector, the adversary can achieve full control over the system. This level of privilege escalation allows for comprehensive data exfiltration, persistence mechanisms, lateral movement within connected networks, and complete manipulation of device functionality. The ability to execute code as root means that standard security boundaries are bypassed entirely, granting the attacker unrestricted access to sensitive configurations, user data, and hardware interfaces.
This vulnerability aligns with CWE-327, which describes the use of a broken or risky cryptographic algorithm, specifically in this case involving compromised key management practices where private keys are improperly exposed in public repositories. It also relates closely to CWE-862, as it involves missing authorization for critical security functions like signature verification during boot and package installation. In terms of offensive tactics, this scenario maps directly to MITRE ATT&CK technique T1059, Command and Scripting Interpreter, particularly when considering the execution phase following successful privilege escalation. Furthermore, the exploitation method resembles T1195, Supply Chain Compromise, as the trust is established through a compromised development artifact rather than direct intrusion of the production environment initially.
Mitigation strategies must address both immediate operational risks and long-term cryptographic integrity. Immediate remediation requires removing the exposed private key from all public SDK distributions and revoking any certificates associated with it if possible. The device firmware should be updated to enforce signature verification strictly during the boot process, ensuring that no optional packages are restored without valid cryptographic proof of authenticity. Additionally, implementing secure boot mechanisms that validate not only the kernel but also subsequent stages of the bootloader against known good hashes can prevent unauthorized modifications at lower levels. Long-term solutions involve adopting a hardware-backed key storage solution such as a Trusted Platform Module or Secure Element to protect private keys from extraction via software means. Regular audits of development artifacts and strict access controls for production credentials are essential to prevent recurrence, ensuring that cryptographic materials remain confidential throughout the entire product lifecycle.