Description

go-wind-cms (GoWind) before 1.0.0 has a missing authorization vulnerability. The NewAuthorizer() function in app/admin/service/internal/data/data.go and app/app/service/internal/data/data.go returns a no-op authorization engine (noop.State{}), so the authz middleware always allows requests. Any authenticated user (regardless of role or tenant) can invoke administrative APIs such as deleting users, resetting passwords, and creating tenants.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-28T00:18:12.677Z",
  "pubdate": "2026-08-28T00:18:12.677Z",
  "executiveSummary": "The GoWind CMS (go-wind-cms) prior to version 1.0.0 contains a critical missing authorization vulnerability resulting from a failure to implement proper access control logic.\nThe vulnerability stems from the use of a no-op authorization engine, which defaults to an 'allow-all' state for requests processed by the application's administrative service middleware.\nThis flaw allows any authenticated user, regardless of their assigned role or tenant membership, to execute sensitive administrative operations.\nThe impact includes full unauthorized management of the system, such as user account deletion, password resets, and arbitrary tenant creation, effectively leading to a total compromise of the application's integrity and confidentiality.\nExploitation requires the attacker to possess a valid, low-privileged user account, as the middleware fails to perform authorization checks once authentication is successfully verified.\nRisk implications are high, as the vulnerability circumvents intended RBAC (Role-Based Access Control) policies, granting administrative privileges to standard users.",
  "technicalDetails": "The root cause of this vulnerability is located within the initialization logic of the authorization subsystem in go-wind-cms versions prior to 1.0.0. Specifically, the functions NewAuthorizer() defined in 'app/admin/service/internal/data/data.go' and 'app/app/service/internal/data/data.go' return an instance of 'noop.State{}'.\nIn the context of the application's authorization framework, 'noop.State' acts as a placeholder that provides no actual enforcement of authorization policies. When the application's middleware invokes the authorization engine to validate a request against a protected resource or API endpoint, the no-op implementation returns a success signal by design.\nBecause the authorization middleware relies on this faulty implementation, it fails to evaluate the identity of the requester or their associated permissions against the requested administrative action. Consequently, the middleware effectively grants universal access to all API routes, including those reserved for administrative functions.\nThe attack flow proceeds as follows: 1) An attacker authenticates to the application using a standard, low-privileged user account. 2) The attacker intercepts or crafts HTTP requests targeted at administrative endpoints, such as those used for creating new tenants, modifying user configurations, or deleting system entities. 3) Upon receiving the request, the authorization middleware triggers the flawed NewAuthorizer() logic. 4) The 'noop.State{}' engine immediately validates the request as authorized. 5) The backend processes the administrative action, granting the attacker the ability to perform operations they are not entitled to execute.\nThis vulnerability is restricted to environments where the application has been deployed using the affected code paths. Since the flaw resides in the core authorization initialization, it does not depend on specific configuration settings beyond the default codebase. The technical impact is a total bypass of RBAC, rendering the administrative interface reachable by any authenticated identity on the platform. Post-exploitation, an attacker can escalate privileges, sabotage system data, or exfiltrate sensitive information by manipulating the underlying tenant and user management structures."
}