CVE-2026-75419 in go-wind-cms
Summary
by MITRE • 08/28/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in GoWind CMS prior to version 1.0.0 represents a critical failure in access control mechanisms, specifically categorized under CWE-285 Improper Authorization. This flaw stems from the implementation of the authorization middleware within the application's core service layers. Specifically, the NewAuthorizer function located in both app/admin/service/internal/data/data.go and app/app/service/internal/data/data.go is configured to return a no-op state object, denoted as noop.State{}. In security architecture terms, a no-op or null object pattern that bypasses checks effectively disables the intended security control rather than enforcing it. Consequently, the authentication middleware fails to validate whether the requesting user possesses the necessary privileges for the specific action being attempted.
From an operational perspective, this misconfiguration results in a complete breakdown of role-based access control and multi-tenancy isolation. Although users must authenticate to interact with the system, the authorization layer does not differentiate between administrative roles and standard user roles. This means that any authenticated individual, regardless of their assigned permissions or tenant affiliation, can execute privileged operations intended exclusively for administrators. The attacker does not need to exploit a separate flaw such as SQL injection or cross-site scripting; they simply need valid credentials for any low-privilege account to escalate their capabilities significantly.
The impact of this vulnerability is severe due to the nature of the exposed administrative APIs. An adversary can leverage these unrestricted endpoints to delete other users, which disrupts service availability and integrity by removing legitimate accounts from the system. Furthermore, the ability to reset passwords allows an attacker to hijack existing user sessions or lock out administrators by changing their credentials. Most critically, the capability to create new tenants indicates a failure in multi-tenancy isolation. This could allow an attacker to establish isolated environments within the same instance that may be used for further malicious activities, data exfiltration from other contexts if shared resources are misconfigured, or simply as a foothold for persistent access without detection by standard monitoring tools focused on tenant-specific anomalies.
This vulnerability aligns with MITRE ATT&CK technique T1078 Valid Accounts, where attackers use legitimate credentials to gain initial access and maintain persistence. It also relates to T1068 Exploitation for Privilege Escalation, as the lack of authorization checks allows a low-privileged user to perform high-level administrative tasks effectively escalating their privileges without exploiting software bugs in other components. The root cause is not necessarily complex code logic but rather an architectural oversight where security controls are disabled or bypassed by design during development or configuration phases.
To mitigate this vulnerability, immediate action must be taken to upgrade the GoWind CMS installation to version 1.0.0 or later, as these versions presumably correct the authorization engine implementation. In environments where upgrading is not immediately feasible, temporary mitigations should focus on network-level controls. Implementing strict firewall rules or Web Application Firewall policies can restrict access to administrative endpoints only from trusted IP addresses associated with known administrator workstations. Additionally, enabling comprehensive logging and monitoring for all administrative API calls can help detect unauthorized attempts by standard users attempting to invoke admin functions, allowing security teams to respond rapidly to potential exploitation events until the software patch is applied.