Here is the story of how we traced a cryptographic vulnerability through a major software supply-chain to uncover a flaw in its identity verification process.
Exploring your cryptographic inventory is hard. Not only do cryptographic assets and Non-Human Identities (NHIs) hide anywhere and everywhere, but without help, their sheer quantity will overwhelm any security team. This lack of complete visibility creates a vast, unknown attack surface where your weakest link—a single forgotten asset—can trigger a cascading breach. This is precisely the scenario AQtive Guard was engineered to prevent: (1) our platform, using existing third party data (e.g. Crowdstrike, Qualys, etc.) and our own sensors, discovers your cryptographic assets and (2) our analysis engine connects the different pieces of your inventory, identifies issues, and helps you focus your remediation efforts.
In this blogpost, we show that the proof of the pudding is in the tasting: while working on improving our analysis engine and without actively looking, we found an insecure and non-compliant code signing key (1024-bit DSA) for a widespread Linux driver published by HP. We also uncovered that the official installation procedure is vulnerable to a key spoofing attack which can lead to the successful verification of malicious code for software running with ROOT privileges. This vulnerability has now been assigned CVE-2025-43023. Additionally, we noticed that a deceptive key that makes use of this vulnerability has been published by an unknown developer.
If a major, security-conscious technology company can have an insecure and non-compliant identity key actively signing new releases, it can happen to anyone. It underscores the critical need for automated, continuous visibility that goes beyond simple inventory to uncover true risk.
We want to acknowledge the diligence of the HP product security team. Once notified, they engaged with us immediately and addressed our findings.
How we found it
We’re constantly improving our analysis engine to make sense of the multitude of cryptographic assets that are found on our customers systems. To do so, we’ve created IT assets (like VMs or Docker images) which mimic typical cryptographic inventory and behaviours. On a single VM filesystem, it is common to find thousands of keys and certificates raising hundreds of security and / or compliance issues.
Our analysis engine enriches inventoried cryptographic assets and highlights particularly suspicious items. During a work session, we are analysing a single docker image containing tens of thousands of keys and certificates and raising nearly a thousand issues. After enriching and filtering the data, the engine highlighted 8 potentially problematic issues, and one immediately stands out:
At first glance, we notice that a signing key for the hplip software is making use of DSA, the Digital Signature Algorithm, a long-standing U.S. Federal Government Standard for digital signatures. This is suspicious, and checking the rule description provided right next to the alert clarified the reason: NIST has disallowed the use of DSA for signature generation since 2023 in its Digital Signature Standard, FIPS 186-5.. Another click tells us that this DSA key is 1024-bit long, a key size which NIST disallowed for digital signature generation after 2013 under its Special Publication (SP) 800-131A, Revision 1 guidance. The tool also informs the user that1024-bit DSA only offers 80-bit of security which makes it possible for a big corporation or nation state actor to break.
This finding warranted our immediate attention, prompting us to begin a deep-dive into its origins and usage.
To understand the potential impact of this finding, our first step was to identify the software in question: hplip. This acronym stands for HP Linux Imaging and Printing, and it’s more than just a driver; it is the official, comprehensive software suite from HP for their printers and scanners on Linux systems. Its importance in the open-source ecosystem is significant, as it is the de facto standard, and it’s included by default in most major distributions, such as Ubuntu, Fedora, and Debian. This means it is likely deployed on millions of devices globally, from individual workstations to enterprise servers. Furthermore, because printer drivers need to interact directly with system hardware, they often require elevated permissions to function—making the integrity of the software and its signing key absolutely critical.
Our analysis then shifted to another question: was this key a dormant, legacy artifact, or was it still in active use? A deprecated key, while poor hygiene, is a much lower risk than one actively signing new software releases. To determine this, we downloaded the latest HPLIP release (version 3.25.2, dated March 2025) and successfully verified the package's signature using the problematic 1024-bit DSA key. This confirmed the key is not only present but is an active component of HP's software supply chain.
kiwi@host:~$ /t/blogpost> wget https://sourceforge.net/projects/hplip/files/hplip/3.25.2/hplip-3.25.2.tar.gz.asc/download -O hplip-3.25.2.tar.gz.asc
kiwi@host:~$ /t/blogpost> wget https://sourceforge.net/projects/hplip/files/hplip/3.25.2/hplip-3.25.2.tar.gz/download -Ohplip-3.25.2.tar.gz
kiwi@host:~$ gpg --keyserver keyserver.ubuntu.com --recv-keys 0x4ABA2F66DBD5A95894910E0673D770CDA59047B9
kiwi@host:~$ /t/blogpost> gpg --verify ./hplip-3.25.2.tar.gz.asc
gpg: assuming signed data in './hplip-3.25.2.tar.gz'
gpg: Signature made Thu 27 Feb 12:21:42 2025 GMT
gpg: using DSA key 4ABA2F66DBD5A95894910E0673D770CDA59047B9
gpg: Good signature from "HPLIP (HP Linux Imaging and Printing) <hplip@hp.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 4ABA 2F66 DBD5 A958 9491 0E06 73D7 70CD A590 47B9
Some notes on the above. The verify command will not work anymore since HP has updated their key and signature. You can try to reproduce it with earlier versions though, such as 3.24.4. The gpg: WARNING message above, and also shown later on, is normal and expected here. It relates to GPG's "Web of Trust," not a signature failure, and simply means the user hasn't personally vouched for the key's authenticity. The Good signature line confirms the verification was successful.
The key's active use for signing immediately raised the question of its trust and blast radius: was anyone actually relying on this weak signature for verification? We confirmed the key is deeply embedded in the Linux ecosystem. Both Debian and Ubuntu distribute it for package verification, and, most critically, HP’s own official documentation explicitly instructs users on how to use this specific key to verify the software package:
Let’s follow the official guidance to download the key and verify the package:
kiwi@host:~$ ~ > gpg --keyserver pgp.mit.edu --recv-keys 0xA59047B9
gpg: key 73D770CDA59047B9: "HPLIP (HP Linux Imaging and Printing) <hplip@hp.com>" imported
gpg: key 214736AFA59047B9: public key "Totally Legit Signing Key <mallory@example.org>" imported
gpg: Total number processed: 2
gpg: imported: 2
kiwi@host:~$ ~/w/hplip> gpg --verify ./hplip-3.25.2.tar.gz.asc
gpg: assuming signed data in './hplip-3.25.2.tar.gz'
gpg: Signature made Thu 27 Feb 12:21:42 2025 GMT
gpg: using DSA key 4ABA2F66DBD5A95894910E0673D770CDA59047B9
gpg: Good signature from "HPLIP (HP Linux Imaging and Printing) <hplip@hp.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 4ABA 2F66 DBD5 A958 9491 0E06 73D7 70CD A590 47B9
The output from following the official instructions immediately reveals a critical vulnerability (CVE-2025-43023)—and it has nothing to do with the weak DSA algorithm. It’s a classic identity verification failure. But that’s a common pattern in security. When there is a cryptographic issue, it means something has not been kept to recent standards, and many other issues may hide behind.
The problem lies with the short key ID specified in the command: A59047B9. It is too short, and as we saw, it matches not one but two different keys on the pgp.mit.edu keyserver. In practice, the gpg command requests PGP keys from a keyserver that match the provided fingerprint (a hash of the public key). For convenience’s sake, however, the keyserver also returns a key if the user requests one using a short key identifier, which is a truncated, 32-bit version of the full fingerprint. This convenience comes at a cost: the 32-bit identifier is susceptible to collisions. If the identifier matches two different keys, the keyserver returns both, and gpg gladly installs both into the user's keyring.
This is exactly what happened here, with both of these keys matching the A59047B9 short key ID::
- key 73D770CDA59047B9: "HPLIP (HP Linux Imaging and Printing) <hplip@hp.com>"
- key 214736AFA59047B9: public key "Totally Legit Signing Key <mallory@example.org>" imported
It looks like somebody else already noticed the potential confusion and purposefully published a key that collides with hplip’s key to demonstrate or exploit the vulnerable command.
The security impact here is severe. By polluting the user's keyring with a spoofed key, an attacker can get a maliciously crafted software package to pass signature verification. This completely defeats the purpose of code authentication and could be used to trick a user into executing malicious code, potentially with ROOT privileges.
Demonstration of the attack
In this demonstration, the goal of the attacker is to execute malicious code on the target device by bypassing code authentication. The attacker manipulates the user into believing they are executing trustworthy code because the code authentication succeeded.
The scenario assumes that the user has been tricked into downloading malicious software, but still intends to verify its authenticity using PGP signature. The attack exploits the usage of short Key ID and the reliance on PGP for verification.
Once the malicious key is installed on the system, the attacker can potentially spoof any signature on any software package. For the purpose of this demonstration, we assume that the target software package is hplip.
The attacker's process is as follows:
- Generate a Spoofed Identity: The first step is to create a malicious PGP key pair that has the same short Key ID as hplip’s key. This is really straightforward as the search space is small (232): we generate DSA keys until we find the one whose short key ID matches hplip’s short key ID. On MacOS, this takes about 15 minutes on a single core.
- Publish the Malicious Key: The attacker then uploads the public part of the spoofed PGP key to a public key server. Here, we publish it to a private keyserver to avoid polluting public resources.
The user then copy-pastes and runs the command from HP’s documentation. Note how our spoofed key (“kiwi@sandboxaq.com”) is also imported in the user keyring.
kiwi@host:~$ ~ > gpg --keyserver pgp.mit.edu --recv-keys 0xA59047B9
gpg: key 73D770CDA59047B9: "HPLIP (HP Linux Imaging and Printing) <hplip@hp.com>" imported
gpg: key 0B761983A59047B9: public key "kiwi@sandboxaq.com" imported
gpg: Total number processed: 2
gpg: imported: 2
Next, the user is convinced to download a malicious hplip package signed with the spoofed key. To verify the code’s authenticity, the user verifies the package’s signature. The verification succeeds with the same message as with the hplip key. Note that the identity linked to the key (below kiwi@sandboxaq.com) is chosen by the attacker, so the message could have been strictly identical (except for the long key ID).
kiwi@host:~$ ~ > gpg --verify ./hplip-3.25.2.tar.gz.ascgpg: assuming signed data in './hplip-3.25.2.tar.gz'
gpg: Signature made Tue 13 May 15:27:56 2025 BST
gpg: using DSA key 9482E2898E853E55A4D439ED0B761983A59047B9
gpg: Good signature from "kiwi@sandboxaq.com" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9482 E289 8E85 3E55 A4D4 39ED 0B76 1983 A590 47B9
Since verification succeeded, the user believes the code is genuine and executes malicious code:
kiwi@host:~$ ~ > tar xvf hplip-3.25.2.tar.gz && cd hplip-3.25.2
kiwi@host:~$ ~/hplip-3.25.2 > ./configure
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▄▄▄▄▄ YOU'VE BEEN HACKED ▄▄▄▄▄▄▄
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
Limitations and mitigations
It is important to note that this key-spoofing vulnerability specifically affects the manual installation process described in HP's official documentation. Users who install or update hplip through their system's native package manager are already protected by the authentication system of the package manager.
- System-Level Mitigation: Some major Linux distributions have already addressed this issue. The Debian project, for example, patched their hplip package back in 2019 to use the full key fingerprint for verification, effectively mitigating this specific attack vector for their users.
- User-Level Mitigation: For users performing a manual installation, the mitigation is straightforward: always use the full PGP key fingerprint, not the short key ID. The full fingerprint is cryptographically unique and not susceptible to the collision attack demonstrated here. The correct, secure command would use the full fingerprint, which for the legitimate HPLIP key is 4ABA2F66DBD5A95894910E0673D770CDA59047B9.
Outcomes
Following this discovery, we took two immediate actions:
- Responsible Disclosure: We followed standard responsible disclosure procedures and privately shared our complete findings with the HP product security team, which led to the assignment of CVE-2025-43023. We want to acknowledge the diligence and rigor of their response; once notified, they engaged with us immediately and collaborated on a swift and effective plan to address the findings, demonstrating a clear commitment to ecosystem security.
- Platform Enhancement: We have integrated the details of this vulnerability directly into the AQtive Guard platform. The malicious colliding key, "Totally Legit Signing Key <mallory@example.org>", is now flagged as a known threat. Any AQtive Guard customer whose systems encounter this fraudulent key will now be immediately alerted to the risk, showcasing how our platform's intelligence is continuously updated to protect against emerging threats. This process of constantly enriching our platform's intelligence with new findings is a core part of the protection we provide to all our customers.
Conclusion
This entire discovery process, from a single weak key to a critical identity verification flaw, was made possible by AQtive Guard. We first identified the high-risk cryptographic asset among thousands of others, cutting through the noise to find the signal that mattered. This initial finding then allowed us to perform a deeper Root Cause Analysis (RCA), revealing that besides the compliance and security issue, another danger existed: a flaw in how the hplip software's Non-Human Identity is verified.
This incident showcases that modern security requires a unified view of both cryptographic posture and identity management. Managing one without the other leaves a critical security gap that attackers can, and do, exploit. AQtive Guard is the only platform built to address this converged risk, providing unified, AI-driven management for both Cryptography and Non-Human Identities to secure the entire machine-to-machine ecosystem.
We would like to thank the HP Security Team for their partnership in addressing this vulnerability and protecting the open-source ecosystem. Their swift work on the remediation and their transparency throughout the coordinated disclosure process were commendable.
For more information, check out the disclosure that HP made in their Security Bulletins dated July 24, 2025.
Request a demo or start a free trial to see how AQtive Guard can help you surface and stop hidden cryptographic risks in your environment.
