CVE-2026-112338 in Wazuh
Summary
by MITRE • 11/06/2026
Wazuh from 4.3.0 before 4.14.9 contains a server-side request forgery vulnerability in the GitHub module (wm_github.c) that trusts unvalidated Link rel="next" pagination URLs. Attackers controlling the next-page URL can make the manager send requests with the GitHub API token to attacker hosts, exposing organization repositories and settings.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/06/2026
The identified security flaw resides within the Wazuh server-side components, specifically affecting versions ranging from 4.3.0 up to but not including version 4.14.9. This vulnerability is located in the GitHub module implementation file named wm_github.c and represents a classic Server-Side Request Forgery scenario driven by insufficient validation of external data sources. The core technical deficiency lies in how the application handles pagination metadata returned by the GitHub API, particularly focusing on the Link header field which contains rel="next" URLs used to retrieve subsequent pages of results during repository or issue enumeration processes.
When Wazuh queries the GitHub API for information such as organization repositories, pull requests, or issues, it relies on standard HTTP response headers to navigate through paginated data sets. The application incorrectly assumes that all Link header values provided by the remote server are safe and legitimate endpoints belonging to github.com. By trusting these unvalidated URLs without performing strict domain verification or schema validation, the software creates a vector for exploitation where an attacker can manipulate the pagination mechanism to redirect internal requests to arbitrary external destinations controlled by the adversary.
The operational impact of this vulnerability is significant due to the privileged nature of the Wazuh manager and its integration with sensitive organizational data sources. An attacker who controls or influences the next-page URL, potentially through a compromised GitHub repository they own or have write access to, can force the vulnerable Wazuh instance to initiate HTTP requests using its stored authentication credentials. Since the module utilizes valid API tokens for these operations, any request sent by the manager will carry legitimate authorization headers. This allows the attacker to exfiltrate sensitive data indirectly through side-channel mechanisms such as DNS queries or HTTP POST bodies directed at their own servers, effectively bypassing standard network security controls that might otherwise restrict outbound traffic from internal management systems.
This exploitation technique aligns with CWE-918, which defines Server-Side Request Forgery (SSRF), specifically highlighting the failure to validate user-supplied input before using it in server-side requests. Furthermore, the attack vector corresponds to MITRE ATT&CK techniques related to Data Exfiltration over C2 Channels and potentially Command and Control if the exfiltrated data is used for further reconnaissance or lateral movement within the organization's infrastructure. The vulnerability underscores a critical gap in secure coding practices regarding the handling of metadata from third-party APIs, where implicit trust in external responses leads to credential exposure and potential compromise of organizational assets hosted on GitHub.
To mitigate this risk, organizations running Wazuh versions prior to 4.14.9 must immediately upgrade to version 4.14.9 or later, which includes the necessary code corrections to validate pagination URLs against expected domains before processing them. In environments where immediate patching is not feasible, administrators should implement strict egress filtering rules at the network perimeter to restrict outbound connections from Wazuh managers to only known and trusted GitHub endpoints. Additionally, rotating any API tokens associated with affected instances is recommended as a precautionary measure to invalidate potentially exposed credentials, ensuring that even if an attack was attempted using stolen tokens, they cannot be reused for unauthorized access.