Skraft9

**Name of the Vulnerable Software and Affected Versions** Wazuh versions 3.9.0 through 4.14.2 **Description** Wazuh is a platform used for threat prevention, detection, and response. A privilege escalation issue exists in the Wazuh Manager's cluster synchronization protocol. The `wazuh-clusterd` service allows authenticated nodes to write arbitrary files to the manager’s file system with the permissions of the `wazuh` system user. Due to insecure default permissions, the `wazuh` user has write access to the manager's main configuration file (`/var/ossec/etc/ossec.conf`). By leveraging the cluster protocol to overwrite `ossec.conf`, an attacker can inject a malicious `<localfile>` command block. The `wazuh-logcollector` service, which runs as root, parses this configuration and executes the injected command. This allows an attacker with cluster credentials to gain full Root Remote Code Execution. The `wazuh-clusterd` service and the `/var/ossec/etc/ossec.conf` file are key components in this issue. **Recommendations** Wazuh versions 3.9.0 through 4.14.2 should be upgraded to version 4.14.3.

**Name of the Vulnerable Software and Affected Versions** Wazuh versions 4.4.0 through 4.14.2 **Description** Wazuh is a free and open source platform used for threat prevention, detection, and response. A stack-based buffer overflow exists in the Wazuh Database synchronization module (`wdb delta event.c`). The SQL query construction logic allows for an integer underflow when calculating the remaining buffer size due to the incorrect aggregation of the return value of `snprintf`. If a database synchronization payload exceeds the query buffer size (2048 bytes), bounds checking is removed for subsequent writes, allowing an attacker to corrupt the stack, potentially leading to a Denial of Service (DoS) or Remote Code Execution (RCE). **Recommendations** Versions prior to 4.14.3 should be updated to version 4.14.3 or later.

**Name of the Vulnerable Software and Affected Versions** Wazuh versions 3.9.0 through 4.14.2 **Description** Wazuh is a platform used for threat prevention, detection, and response. Multiple stack-based buffer overflows exist in the Security Configuration Assessment (SCA) decoder (`wazuh-analysisd`). The use of `sprintf` with a floating-point (`%lf`) format specifier on a fixed-size 128-byte buffer allows a remote attacker to overflow the stack. A specially crafted JSON event can trigger this overflow, leading to a denial of service (crash) or potential remote code execution (RCE) on the Wazuh manager. The vulnerability is located in `/src/analysisd/decoders/security configuration assessment.c`, within the `FillScanInfo` and `FillCheckEventInfo` functions. The issue occurs when processing floating-point numbers with large exponents within JSON events, as the `sprintf` function attempts to write a string representation exceeding the allocated buffer size (`char value[OS SIZE 128];`). **Recommendations** Wazuh versions prior to 4.14.3 should be updated to version 4.14.3 or later.

**Name of the Vulnerable Software and Affected Versions** Wazuh versions 4.0.0 through 4.14.2 **Description** Wazuh is a free and open source platform used for threat prevention, detection, and response. A Remote Code Execution (RCE) issue exists due to the deserialization of untrusted data within the cluster synchronization protocol. This affects deployments using cluster mode (master/worker architecture). An attacker who gains access to a worker node—via initial access, insider threats, or supply chain attacks—can achieve full RCE on the master node with root privileges by sending a specially crafted DAPI request. The issue involves the `as wazuh object()` function, unsafe reflective object loading, and implicit cluster trust assumptions, allowing for Python runtime abuse and dynamic import exploitation. **Recommendations** Update to version 4.14.3.

**Name of the Vulnerable Software and Affected Versions** Wazuh versions 4.3.0 through 4.14.2 **Description** Wazuh is a platform used for threat prevention, detection, and response. A denial of service issue exists in the Wazuh API authentication middleware (`middlewares.py`). The application uses an asynchronous event loop (Starlette/Asyncio) to call a synchronous function (`generate keypair`) that performs blocking disk I/O on every request containing a Bearer token. A remote, unauthenticated attacker can exploit this by flooding the API with requests containing invalid Bearer tokens. This forces the single-threaded event loop to pause repeatedly for file read operations, potentially preventing the application from accepting or processing legitimate connections. The `generate keypair` function is involved in the issue. **Recommendations** Update to version 4.14.3 or later.

**Name of the Vulnerable Software and Affected Versions** LibreNMS versions 25.6.0 and below **Description** LibreNMS is an auto-discovering PHP/MySQL/SNMP based network monitoring system. Versions 25.6.0 and below contain an architectural vulnerability in the `/ajax form.php` endpoint that permits Remote File Inclusion based on user-controlled POST input. The application directly uses the `type` parameter to dynamically include `.inc.php` files from the `includes/html/forms/` path without validation or allowlisting. This introduces a potential Remote Code Execution (RCE) vector if an attacker can stage a file in this include path, for example, via symlink or development misconfiguration. **Recommendations** LibreNMS versions prior to 25.7.0 are affected. - Implement strict allow listing or hardcoded routing instead of dynamically including user-supplied filenames. - Avoid passing raw POST input into `include once`. - Ensure the inclusion path is immutable and outside of attacker control.

**Name of the Vulnerable Software and Affected Versions** Nagios Log Server versions prior to 2024R1.3.2 **Description** Nagios Log Server versions prior to 2024R1.3.2 allow authenticated users with read-only API access to stop the Elasticsearch service. This is achieved by sending a request to the `/nagioslogserver/index.php/api/system/stop` API endpoint with the `subsystem` parameter set to `elasticsearch`. Despite the API response indicating a failure to stop the service ("message": "Could not stop elasticsearch"), the Elasticsearch service is stopped. **Recommendations** Update Nagios Log Server to version 2024R1.3.2 or later.