ghsa-hcrc-79hj-m3qh
Vulnerability from github
Published
2025-04-22 16:53
Modified
2025-04-22 16:53
Severity ?
Summary
Wazuh server vulnerable to remote code execution
Details

Summary

An unsafe deserialization vulnerability allows for remote code execution on Wazuh servers.
The vulnerability can be triggered by anybody with API access (compromised dashboard or Wazuh servers in the cluster) or, in certain configurations, even by a compromised agent.

Details

DistributedAPI parameters are a serialized as JSON and deserialized using as_wazuh_object (in framework/wazuh/core/cluster/common.py). If an attacker manages to inject an unsanitized dictionary in DAPI request/response, they can forge an unhandled exception (__unhandled_exc__) to evaluate arbitrary python code.

Using the server API, it quite easy to trigger. For example, using the run_as endpoint (implemented by run_as_login in api/api/controllers/security_controller.py): the auth_context argument is completely controlled by the attacker, and is forwarded to the master server to handle. By sending a malicious run_as request to a worker server, it is possible to execute code on the master server.

It is also possible to exploit the bug as a compromised agent, in certain configurations.
A compromised agent can respond to a getconfig request with a malicious JSON object (containing a serialized unhandled exception). If the getconfig request was caused because of a server API request to /agents/{agent_id}/config/{component}/{configuration} (api.controllers.agent_controller.get_agent_config), and the agent is managed by a server other than the one that received the server API request, the unsafe deserialization will occur on the server that received the original server API request.

user server A server B agent | | | | | -get-config-> | | | | | --get-config-dapi-> | | | | | --getconf-> | | | | <-payload-- | | X <-----payload------ | | | | | |

It is likely that there are more ways to reach the unsafe deserialization function (as_wazuh_object), some of them might even be accessible from different contexts (without credentials, or initiated by a compromised agent). I suggest fixing the root cause instead of attempting to sanitize inputs that reach it. Note that there are multiple other ways to execute arbitrary code in as_wazuh_object, easier by using a __callable__, or potentially abusing callable gadgets in exception, wresults or Wazuh.

PoC

To trigger using the server API (assuming default credentials):
bash curl -X POST -k -u "wazuh-wui:MyS3cr37P450r.*-" -H "Content-Type: application/json" --data '{"__unhandled_exc__":{"__class__": "exit", "__args__": []}}' https://<worker-server>:55000/security/user/authenticate/run_as this will shut down the master server.

Impact

This is a remote code execution on Wazuh server, affecting the latest version (v4.9.0 at this time)

Show details on source website


{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/wazuh/wazuh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.4.0"
            },
            {
              "fixed": "4.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-502"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-22T16:53:39Z",
    "nvd_published_at": "2025-02-10T20:15:42Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nAn unsafe deserialization vulnerability allows for remote code execution on Wazuh servers.  \nThe vulnerability can be triggered by anybody with API access (compromised dashboard or Wazuh servers in the cluster) or, in certain configurations, even by a compromised agent.\n\n### Details\nDistributedAPI parameters are a serialized as JSON and deserialized using `as_wazuh_object` (in `framework/wazuh/core/cluster/common.py`). If an attacker manages to inject an unsanitized dictionary in DAPI request/response, they can forge an unhandled exception (`__unhandled_exc__`) to evaluate arbitrary python code.  \n\nUsing the server API, it quite easy to trigger. For example, using the `run_as` endpoint (implemented by `run_as_login` in `api/api/controllers/security_controller.py`): the `auth_context` argument is completely controlled by the attacker, and is forwarded to the master server to handle. By sending a malicious `run_as` request to a worker server, it is possible to execute code on the master server.\n\nIt is also possible to exploit the bug as a compromised agent, in certain configurations.  \nA compromised agent can respond to a `getconfig` request with a malicious JSON object (containing a serialized unhandled exception). If the `getconfig` request was caused because of a server API request to `/agents/{agent_id}/config/{component}/{configuration}` (`api.controllers.agent_controller.get_agent_config`), and the agent is managed by a server other than the one that received the server API request, the unsafe deserialization will occur on the server that received the original server API request.\n\n```\nuser          server A              server B         agent\n  |               |                     |             |\n  | -get-config-\u003e |                     |             |\n  |               | --get-config-dapi-\u003e |             |\n  |               |                     | --getconf-\u003e |\n  |               |                     | \u003c-payload-- |\n  |               X \u003c-----payload------ |             |\n  |               |                     |             |\n```\n\nIt is likely that there are more ways to reach the unsafe deserialization function (`as_wazuh_object`), some of them might even be accessible from different contexts (without credentials, or initiated by a compromised agent). I suggest fixing the root cause instead of attempting to sanitize inputs that reach it. Note that there are multiple other ways to execute arbitrary code in `as_wazuh_object`, easier by using a  `__callable__`, or potentially abusing callable gadgets in `exception`, `wresults` or `Wazuh`.\n\n### PoC\nTo trigger using the server API (assuming default credentials):  \n```bash\ncurl -X POST -k -u \"wazuh-wui:MyS3cr37P450r.*-\" -H \"Content-Type: application/json\" --data \u0027{\"__unhandled_exc__\":{\"__class__\": \"exit\", \"__args__\": []}}\u0027 https://\u003cworker-server\u003e:55000/security/user/authenticate/run_as\n```\nthis will shut down the master server.\n\n### Impact\nThis is a remote code execution on Wazuh server, affecting the latest version (v4.9.0 at this time)",
  "id": "GHSA-hcrc-79hj-m3qh",
  "modified": "2025-04-22T16:53:39Z",
  "published": "2025-04-22T16:53:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wazuh/wazuh/security/advisories/GHSA-hcrc-79hj-m3qh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24016"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wazuh/wazuh"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Wazuh server vulnerable to remote code execution"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…