Description

Hubzilla 11.2.1 contains a cross-site request forgery vulnerability in the OAuth2 /authorize endpoint handled by Zotlabs\Module\Authorize::post() that allows unauthenticated attackers to register arbitrary OAuth2 applications under an authenticated user's account by submitting a cross-origin POST request without CSRF token or Origin/Referer validation. Attackers can craft a malicious HTML form that autosubmits attacker-chosen OAuth2 parameters including client_id, client_secret, redirect_uri, and scope to silently register a persistent OAuth2 application, enabling interception of future OAuth2 authorization codes when the victim later authenticates against the attacker-controlled client.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-06T13:18:24.297Z",
  "pubdate": "2026-08-06T13:18:24.297Z",
  "executiveSummary": "Hubzilla version 11.2.1 suffers from a Cross-Site Request Forgery (CSRF) vulnerability residing within the OAuth2 authorization endpoint handled by the Zotlabs\\Module\\Authorize::post() function.\nThe vulnerability allows unauthenticated remote attackers to force an authenticated victim's browser to submit a cross-origin HTTP POST request to the application endpoint.\nBecause the endpoint fails to validate anti-CSRF tokens, Origin headers, or Referer headers, the application processes the untrusted request and registers an arbitrary OAuth2 application directly under the victim's authenticated account.\nThe primary impact is the unauthorized persistence of a malicious OAuth2 client application associated with the victim's profile.\nThis capability enables sophisticated post-exploitation attack vectors, specifically the silent interception of future OAuth2 authorization codes when the victim subsequently authenticates against the attacker-controlled client.\nExploitation requires the attacker to trick an authenticated user into visiting a malicious third-party web page containing an automated cross-origin form submission.\nThe risk implications are significant, as successful exploitation compromises the confidentiality and integrity of the victim's integrated OAuth2 ecosystem and connected services.",
  "technicalDetails": "The vulnerability exists within the Hubzilla OAuth2 authorization module, specifically handled by the Zotlabs\\Module\\Authorize::post() function across version 11.2.1.\nThe root cause of the vulnerability is the complete absence of robust CSRF protection mechanisms, such as anti-CSRF tokens (synchronizer tokens), combined with a failure to validate request context via Origin or Referer header inspection on state-changing HTTP POST requests.\nNetwork exposure is remote, as the vulnerable endpoint is accessible via standard web protocols over the network.\nAuthentication requirements dictate that the victim must possess an active, authenticated session on the target Hubzilla instance when the malicious request is processed, while the attacker executing the cross-origin attack requires no prior authentication.\nPrivilege requirements are minimal for the attacker, whereas the victim must hold standard user privileges sufficient to register OAuth2 applications within the platform.\nThe exploitation method relies on a crafted malicious HTML document hosted on an attacker-controlled domain. This payload features an automated HTML form configured to target the vulnerable /authorize endpoint on the target Hubzilla instance.\nThe attack flow proceeds as follows: First, the attacker crafts an HTML page containing a form with pre-populated, attacker-chosen OAuth2 parameters, including client_id, client_secret, redirect_uri, and scope. Second, the attacker lures a victim—who holds an active session on the Hubzilla instance—to the malicious web page. Third, the browser automatically or via trivial user interaction submits the POST request containing the malicious parameters across origins to the Zotlabs\\Module\\Authorize::post() endpoint. Fourth, lacking token validation or origin verification, the Hubzilla backend processes the request and provisions a persistent OAuth2 application bound to the victim's account.\nPost-exploitation impact includes the ability for the attacker to leverage the newly registered, persistent OAuth2 application to silently intercept subsequent OAuth2 authorization codes when the victim authenticates against the attacker-controlled client, leading to potential account compromise and unauthorized data access."
}