CVE Vulnerability Catalog

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.

Grav prior to 2.0.4 allowlists the regex_replace filter and function, and GravExtension::regexReplace() passes an editor-controlled pattern directly to preg_replace(). When security.twig_content.process_enabled is enabled, an authenticated page editor can publish a catastrophically backtracking pattern that consumes PHP worker CPU and denies service to site visitors.

The Grav Login plugin prior to 3.8.11 accepts the login.regenerate2FASecret task via a top-level GET request without requiring a nonce, Origin check, or Referer check. Under default SameSite=Lax policy, an off-site navigation can invoke taskRegenerate2FASecret() in a logged-in victim's session, overwrite the TOTP secret, and force two-factor re-enrollment.

The Grav Flex Objects plugin prior to 1.4.3 has requireFlexPermission() that returns without denying access when a directory blueprint omits config.admin.permissions. An authenticated account with only api.access can use index, show, create, update, delete, export, and media handlers for a permission-less directory even though the core admin.flex-object authorization fallback would deny the same actions.

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.

Vulnerability in Grav API Plugin (plugin for Grav CMS) before version 1.0.6. WebhookController.php accepts webhook URLs after only FILTER_VALIDATE_URL syntax validation, and WebhookDispatcher.php initializes cURL without CURLOPT_PROTOCOLS or CURLOPT_REDIR_PROTOCOLS restrictions. An account with api.webhooks.write can submit file, dict, gopher, private-network, or link-local targets, retrieve local files and delivery response bodies, and pivot requests to internal services or cloud metadata endpoints. Fixed in version 1.0.6.

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.

Grav prior to 2.0.2 permits grav.offsetGet('config') to return the raw configuration object and allows json_encode, print_r, yaml_encode, and string filters to serialize that object without passing through GravSecurityPolicy::checkMethodAllowed. A user with page-author permissions can render sandboxed content that exposes plugins.* configuration secrets, including SMTP credentials, API keys, and plugin database credentials.

Grav prior to 2.0.1 in ZipArchiver::extract() passes archives to ZipArchive::extractTo() without enforcing the system.gpm.archive uncompressed-size, file-count, or nesting-depth limits. Code using Archiver::create('zip') to extract an attacker-controlled archive can exhaust disk space or inodes and make the site unavailable.

The Grav API plugin prior to 1.0.2 in the POST /api/v1/media pipeline validates an SVG filename extension but does not invoke Security::sanitizeSVG(). An attacker with api.media.write permission can store an SVG containing JavaScript, and the server returns the file as Content-Type: image/svg+xml so the script executes when a victim opens it, allowing session data theft and authenticated actions.

Grav prior to 3.8.5 in the Login plugin twofa_cancel task accepts a client-controlled _redirect field without a nonce and allows an unauthenticated request to set an external http, https, or protocol-relative Location target. Controller::execute() applies the field when taskTwofa_cancel() sets no redirect, and Grav::getRedirectResponse() accepts the target through Uri::isExternal(), enabling phishing redirects from a trusted Grav host.

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.

In Wazuh from version 1.0.0 to 4.14.6 and 5.0.0-beta2, there is a stack out-of-bounds write vulnerability in HandleSecureMessage(). When processing an encrypted agent message on TCP port 1514, decompression can write a null byte beyond the end of the destination buffer, causing the remoted daemon to crash and disrupting agent communications.

In Wazuh from version 3.9.0 to 4.14.5 and 5.0.0-beta2, the cluster protocol allows an authenticated cluster node to exhaust memory on the master. The receive_str() method accepts an attacker-controlled total without a maximum, and the divided-message path retains fragments without limits, potentially causing excessive memory consumption.

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.

The tarfile module in Python has a vulnerability in its extraction filters that allows creating directories outside the destination for members whose name leaves the destination and returns to it (e.g., ../evil/../dest/sub/file). The issue affects only POSIX platforms and creates only empty directories outside the destination.

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.

OpenEMR before version 8.3.0 contains a path traversal vulnerability in the EDI archive restore function. The archrestore_sel parameter is passed without sanitization, and differing response messages leak whether the target path exists. An authenticated user with EOB Data Entry permissions can probe arbitrary filesystem paths.