- CVE-2026-104445 affects YesWiki before 4.6.7: its ActivityPub inbox verifies a message signature but does not check the signer is the actor named in the message.
- Per the NVD record, an unauthenticated attacker with any ActivityPub keypair can delete or overwrite other actors' federated entries.
- Teams running YesWiki should check their version against 4.6.7. Any system that accepts signed partner messages should confirm the signer matches the claimed identity.
A signature proves who sent a message. It does not prove who the message speaks for. That gap sits at the centre of CVE-2026-104445, a flaw in the open-source wiki platform YesWiki.
The NIST National Vulnerability Database (NVD) published the record on October 2, 2026. It says YesWiki versions before 4.6.7 have an authentication bypass in the ActivityPub inbox. ActivityPub is the protocol that lets separate servers exchange posts and updates with each other, which is called federation.
What the flaw is
When a federated message arrives, the inbox checks its HTTP signature. That is a cryptographic stamp made with the sender's private key. The check passes if the signature is valid.
The record says YesWiki then fails to bind the verified signer to the activity actor. The actor is the identity named inside the message as the one performing the action.
Think of a notary who confirms a signature is real but never checks that the signer is the person named in the letter. The stamp is genuine. The claim is not.
What an attacker can do
According to the NVD record, an unauthenticated attacker needs only an ActivityPub keypair. The attacker sends a signed Delete or Update activity that points to a mirrored entry's sourceUrl. YesWiki then deletes or overwrites entries that belong to other actors.
The record does not define "mirrored entry" or "sourceUrl". As the field names suggest, a mirrored entry appears to be a copy of content from another federated source, and the sourceUrl appears to link that copy to its origin. That is this article's reading, not a statement from the record. On that reading, the flaw lets a stranger name the origin and act on it.
Reading the score
The CVSS 3.1 vector describes an attack over the network with low complexity. It needs no privileges and no user action. Confidentiality impact is none, integrity impact is high, and availability impact is low.
In plain terms, the record describes damage to data rather than theft of data. Entries can be erased or rewritten, which means a wiki could show content its owners never approved.
The record does not say whether anyone has exploited the flaw. It also does not say how many YesWiki sites are exposed. This story makes no claim on either point.
The wider lesson
This is one flaw in one product, so it is not evidence of a trend. It does show a mistake that is easy to make wherever machines talk to machines. Verifying a credential is one step. Checking that the credential matches the identity being claimed is a second step, and a system can pass the first and skip the second.
Federated systems, partner feeds and automated integrations all accept signed messages from parties the owner does not control. The signature answers who is calling. The system must still ask whether that caller may act on this record.
What to ask your team
First, do we run YesWiki, and on which version? The NVD record says versions before 4.6.7 are affected. The advisory is listed as GHSA-rm6r-grfg-4v78 on the YesWiki GitHub repository, and VulnCheck has published its own advisory.
Second, is ActivityPub federation switched on for any instance? Teams should confirm whether the inbox is reachable from outside.
Third, for any system that accepts signed inbound messages, does the code compare the signer with the actor or owner named in the message? Ask for the answer to be shown in code or tests, not assumed.
Fourth, can we restore federated content from backup if entries are deleted or overwritten?
A valid signature settles who knocked on the door. It does not settle whose house they are allowed to change.
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.
