CVE Vulnerability Catalog

Wazuh from 4.0.0 to 4.14.6 and 5.0.0-beta2 has a vulnerability in AffectedItemsWazuhResult.merge() in framework/wazuh/core/results.py that trusts the sort_casting field in a cluster worker's JSON response. During distributed API merge, attacker-controlled type names are resolved through Python builtins without an allowlist. A compromised worker can set sort_casting to exec and place Python source in affected_items, causing the master to execute the payload as root when responses from multiple nodes are merged. This issue is fixed in versions 4.14.6 and 5.0.0-beta2.

Wazuh from 4.9.0 to 4.10.4 and 4.14.6 has a vulnerability in PUT /security/users/{user_id} in api/api/controllers/security_controller.py that passes request.get("user") instead of request.context['token_info']['sub'] as current_user. remove_nones_to_dict() removes the resulting None value, so the reserved-account protection in framework/wazuh/security.py cannot verify who is making the request. An authenticated user with the users_admin role can overwrite the password of protected administrator accounts with user IDs at or below 99, including the wazuh superuser, and gain full administrative control. This issue is fixed in versions 4.10.4 and 4.14.6.

A vulnerability in the Open Client Interface (OCI) XML Parser of Cisco BroadWorks could allow an unauthenticated, remote attacker to read sensitive configuration information on an affected system. This vulnerability exists because XML entries are improperly parsed due to external entity resolution being allowed by default. An attacker could exploit this vulnerability by sending a crafted XML message to the Open Client Interface – Provisioning (OCI-P) service, allowing the attacker to view sensitive files from the filesystem with the privileges of the Cisco BroadWorks user.

Cisco Secure Workload contains multiple vulnerabilities related to buffer management issues, grouped under CWE-119. They were discovered during an internal security review and addressed in a software hardening release.

Secure BootROM of RK3588s SoC is vulnerable to a time-of-check to time-of-use attack when booting from external media (SPI NOR or NAND, EMMC or SD). The code reads the header of the next-stage loader twice; the first read is partial and contains only hashes of executable modules, the second is complete including signature. Authenticity of modules is checked against partial data from the first read, allowing an attacker with physical access to modify data and execute arbitrary code with highest privileges (EL3).

Grav API Plugin prior to 1.0.8 intercepts the apiKeyGenerate and apiKeyRevoke admin tasks in user/plugins/api/api.php and authorizes the caller with only admin.login. A basic panel user can select another account from the route, create a persistent ApiKeyManager credential bound to that target, and inherit the target's API permissions, including api.super or administrative write access when present. This issue is fixed in version 1.0.8.

Grav Shortcode Core Plugin prior to 6.2.2 passes shortcode syntax through Security::detectXss() because it contains no literal less-than character, then ColorShortcode.php and related attribute handlers concatenate an attacker-controlled parameter into HTML without encoding. An account with admin.pages permission can close the generated attribute and add an event handler, creating stored cross-site scripting that executes for visitors or administrators who view the page. This issue is fixed in version 6.2.2.

Grav prior to 2.0.7 has a vulnerability in Blueprint::dynamicData() in system/src/Grav/Common/Data/Blueprint.php that sends an editor-controlled Class::method provider and arguments to call_user_func_array() without rejecting dangerous callback parameters. An account with admin.pages or api.pages.write can use Grav\Common\Utils::arrayFilterRecursive() as a trampoline with system as the callback, place a command in page frontmatter, and execute that command as the web server user when the page is viewed. This issue is fixed in version 2.0.7.

Grav API Plugin prior to 1.0.0-rc.16 accepts a JWT from the token URL query parameter on every /api/v1 route, including state-changing endpoints. Request URLs consequently expose valid access tokens through Apache, proxy, and CDN logs, browser history, and Referer headers, allowing a party with access to those records to reuse the token with the owner's API privileges. This issue is fixed in version 1.0.0-rc.16.

Grav API Plugin prior to 1.0.0-rc.16 in CorsMiddleware returns Access-Control-Allow-Origin: * and permissive OPTIONS responses for authenticated /api/v1 endpoints. JavaScript from any origin can submit an attacker-obtained JWT through the Authorization or X-API-Token header, read the authenticated response, and perform write operations with the token owner's privileges, enabling data exfiltration and account modification. This issue is fixed in version 1.0.0-rc.16.

Grav before version 2.0.4 contains .htaccess security rules that compare directory and file-extension patterns case-sensitively, without the [NC] flag. On case-insensitive filesystems, an unauthenticated attacker can use uppercase variants to bypass the rules and retrieve files under user/accounts or user/config, including password hashes and security configuration. This issue is fixed in version 2.0.4.

The Grav Login plugin before version 3.8.11 contains a vulnerability in the login.regenerate2FASecret task that only checks that the pending-session user exists rather than requiring $user->authorized. After submitting a victim's correct password, an attacker can invoke taskRegenerate2FASecret() during the pending TOTP challenge, overwrite twofa_secret, read the replacement secret from the response, calculate a valid code, and complete authentication without the victim's second factor. This issue is fixed in version 3.8.11.

The Grav API plugin before version 1.0.6 contains a vulnerability where ApiKeyManager::generateKey() stores a declared scopes array, but ApiKeyAuthenticator::authenticate() does not read keyData[scopes] and returns the owning user's complete identity. Consequently, AbstractApiController::requirePermission() evaluates the full user ACL, so a key issued for a read-only scope can perform every write, delete, and administrative operation available to the owner. This issue is fixed in version 1.0.6.

The Grav API plugin before version 1.0.6 contains a vulnerability where UsersController::createApiKey(), generate2fa(), and disable2fa() omit the accessGrantsSuper() target check used by sibling user mutation endpoints. A non-super account with api.users.write can mint an API key bound to an access.api.super target, obtain the target's full privileges because key scopes are not enforced, and create persistent super-administrator access; the same missing check also permits rotating or disabling the target's two-factor authentication. This issue is fixed in version 1.0.6.

Wazuh from version 4.0.0 until 4.14.6 and 5.0.0-beta2 contains a vulnerability in WazuhCommon.end_receiving_file() in framework/wazuh/core/cluster/common.py that allows a cluster-authenticated node to delete files outside WAZUH_PATH. A syn_i_w_m_e request with an unknown task_id reaches the cleanup branch, where an attacker-controlled filename is passed to os.path.join without canonicalization or confinement. Absolute paths and traversal sequences can therefore target files such as ossec.conf, jwt_secret.json, TLS certificates, and ruleset files that are accessible to the Wazuh manager process. Deletion can disable the manager, invalidate API tokens, or disrupt cluster and API connectivity. This issue is fixed in versions 4.14.6 and 5.0.0-beta2.

Wazuh Manager from version 4.0.0 until 4.14.5 allows a low-privilege read-only API user with manager:read permission to retrieve the cluster key from the element in ossec.conf through GET /manager/configuration?raw=true. An attacker with network access to TCP port 1516 can use the disclosed Fernet key to impersonate a cluster worker and submit distributed API requests containing attacker-controlled rbac_permissions with rbac_mode set to black. Because the master trusts the worker-supplied authorization context, the attacker can create users, assign administrator roles, access credentials and API tokens, modify configuration, and execute actions across agents. This issue is fixed in version 4.14.5.

HumHub 1.18.4 contains a stored cross-site scripting (XSS) vulnerability in the comment-deletion notification flow. A Space administrator can delete another user's comment, choose to notify the original author, and place HTML/JavaScript in the deletion reason.

IBM AIX 7.2 and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to cause a denial of service and compromise data integrity due to a time-of-check time-of-use race condition.

The Joomla extension J-BusinessDirectory before version 6.2.3 contains a DoS vulnerability in pagination parameter handling. Pagination values were not strictly typed. Array/non-numeric values (for example limitstart[]) could trigger PHP type errors in arithmetic, and limit was not validated before use in list queries.

The Joomla extension J-BusinessDirectory versions below 6.2.3 contain an open mail relay. The recipient address is taken from the request (contact_id_offer / contact_id_event parameters) instead of the server-side offer/event record, allowing mail to be sent to an arbitrary address.