- NVD says SWUpdate through 2026.05.1 trusts certificates supplied inside an update's signature, letting a holder of a key from a neighbouring branch of the same root install malicious updates.
- The update path is the one door most controls trust by design, so the check on it must confirm who was allowed to sign, not only that a signature is valid.
- Find out whether any product or vendor you rely on uses SWUpdate, which version, and how many intermediates sit under your signing root.
A valid signature is not the same as an authorised signer
A software update is the one door that most security controls trust by design. Whatever arrives through it gets installed and run. So the check on that door must answer two questions. Is the signature genuine? And was this signer allowed to sign this?
CVE-2026-109399 is a case where the second question was answered too loosely. The lesson is that a chain of trust is only as narrow as the question the verifier asks of it.
What the record says
The U.S. National Vulnerability Database (NVD) published the record on October 12, 2026. It covers SWUpdate through version 2026.05.1. The flaw sits in one file, crypto/swupdate_cms_verify_openssl.c.
Scoring came from VulnCheck. It rated the flaw 8.1 (High) under CVSS 3.1 and 9.2 (Critical) under CVSS 4.0. Both are severity scales, and the two versions weigh conditions differently. Both vectors mark the attack as network-reachable, with high attack complexity.
How the check goes wrong
Update files are often signed using a standard container called CMS SignedData. The container can carry certificates along with the signature. A certificate chain links the signer's certificate, through intermediate certificates, up to a root the verifier trusts.
NVD says SWUpdate let certificates tucked inside that container help build the chain, even though nobody had vetted them. In other words, part of the evidence for trust came from the sender.
Picture a guard who checks visitor badges against the company's list. The guard also accepts a note from the visitor vouching for the badge. The badge may be real. The note should not decide whether it counts.
The neighbouring-branch problem
The record describes who can exploit this. Think of a trust tree with one trunk and several branches. The legitimate update signer sits on one branch. The attacker holds a key issued on a neighbouring branch of the same tree. That key can carry its own branch certificate inside the signature. Per the record, this lets the attacker install malicious updates.
That is a narrower threat than an anonymous outsider. The attacker starts with a legitimately issued key.
The record does not say why VulnCheck rated the attack complexity as high. The vectors also list no privileges required, which sits oddly beside the need for a signing key. The record leaves that gap unexplained.
The risk falls on whoever manages the other branches. Keys issued for one purpose, under the same root, can become keys that push updates. Teams that guard the update branch carefully may not guard the other branches the same way.
What the record does not say
The NVD entry does not name a fixed release. It does not say how many deployments use the affected code. It does not report any exploitation. It lists a GitHub commit, a project mailing-list thread and a VulnCheck advisory as references.
Questions to put to your team
Ask whether any product you build or buy uses SWUpdate, and which version. Check your software bills of materials and ask vendors directly.
Ask how many intermediate certificates sit under the root that signs your updates. Ask who holds the keys for each one.
Ask whether your update verifier accepts only the intended intermediate, or any certificate that chains to the root. Review the referenced commit and the VulnCheck advisory before deciding on a fix.
Finally, ask whether a key issued for another job could sign an update today. If the answer is yes, the root is trusting more than you meant it to.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
