CVE-2026-90679 in Forgejo
Summary
by MITRE • 09/13/2026
Forgejo 13.0.0 through 16.0.4, when "[federation] ENABLED = true" is set, has a spoofing issue that affects identity integrity but does not allow account takeover or content modification. It does not verify that the HTTP Signature on an incoming ActivityPub activity was produced by the key belonging to the actor named in the activity body. The signature verification in routers/api/v1/activitypub/reqsignature.go validates the request signature, but the inbox activity handlers subsequently read the acting identity from the attacker-controlled JSON body without binding it to the verified signing key. Additionally, the signed Digest header is not recomputed against the received request body. A remote attacker who hosts a single valid ActivityPub actor and keypair can therefore submit signature-valid activities attributed to any actor identity they name.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/13/2026
The vulnerability identified in Forgejo versions 13.0.0 through 16.0.4 represents a critical failure in the implementation of cryptographic binding within its federated social networking protocol, specifically ActivityPub. When federation is enabled via the configuration flag [federation] ENABLED = true, the system processes incoming activities from external instances. The core technical flaw lies in the separation between signature verification and identity validation logic. While the router layer at routers/api/v1/activitypub/reqsignature.go correctly validates that an HTTP Signature was produced by a specific public key associated with a known actor, this verified cryptographic proof is not subsequently bound to the actor identity declared within the JSON body of the activity itself. This architectural disconnect allows for a spoofing attack where the integrity of the sender's identity is compromised without affecting account takeover or content modification capabilities on the server side.
From an operational perspective, this flaw enables a remote attacker who controls a single valid ActivityPub actor and corresponding keypair to forge activities attributed to any arbitrary actor identity named in the request body. The verification process checks if the signature matches the public key of one entity but then blindly trusts the "actor" field inside the JSON payload as belonging to that same entity, even though no cryptographic proof links them together. Furthermore, the system fails to recompute and verify the signed Digest header against the received request body, which removes another layer of integrity checking that could have detected tampering or misattribution. Consequently, an attacker can inject activities into a Forgejo instance while making it appear as if they originated from any other user on the network, thereby undermining trust in federated interactions and potentially facilitating social engineering attacks or reputation manipulation within the community.
This vulnerability maps directly to CWE-345 Insufficient Verification of Data Authenticity, as the application fails to verify that data received matches expected cryptographic properties regarding its origin. It also aligns with MITRE ATT&CK technique T1608 Red Team Infrastructure: Domain Fronting or more broadly T1078 Valid Accounts if used for impersonation, though in this context it is primarily a spoofing issue rather than unauthorized access. The lack of binding between the signing key and the claimed identity creates an opportunity for identity forgery within the federated graph. To mitigate this risk, administrators should ensure that Forgejo instances are updated to versions where the activity handlers correctly bind the verified public key to the actor field in the JSON payload before processing. Additionally, implementing strict validation of Digest headers against the request body and enforcing canonicalization of actor identities can help prevent such spoofing attacks until a patch is applied. Organizations relying on federated features must treat this as a high-severity integrity issue that compromises the trust model of their social infrastructure.