CVE Vulnerability Catalog

Kibana Agent Builder is affected by a Confused Deputy vulnerability (CWE-441) that can lead to privilege escalation. A non-administrative user able to edit a shared agent could cause privileged operations to be performed under the identity of a higher-privileged user. If the same user can also author workflows, this can extend to full administrative control of Kibana and the Elasticsearch cluster.

The Groups – Memberships and Access Control plugin for WordPress in versions up to and including 4.6.0 is vulnerable to privilege escalation. The groups_join() function derives group-join eligibility from the ambient post's author capabilities via the global $post->post_author rather than the authenticated user's own capabilities, while also minting a valid groups-join-data hash and nonce. An authenticated attacker with Subscriber-level access can enroll into any group, including privileged ones, and ultimately escalate to Administrator.

The Joomla UP plugin extension (lomart.fr) in versions 5.0.0-5.2.0 and 6.0.0-6.0.29 contains various path traversal and file access vectors. An attacker can access files outside the intended directory.

The Joomla UP plugin extension (lomart.fr) in versions 5.0.0-5.2.0 and 6.0.0-6.0.29 contains an authenticated, privileged PHP command injection vulnerability. An attacker with appropriate privileges can execute arbitrary PHP commands.

The Joomla AcyMailing Enterprise extension in versions below 11.1.0 contains a remote code execution vulnerability in the mailbox action feature. MIME parts of incoming emails were saved to media/com_acym/upload/ with no extension check, so anyone who could email the monitored mailbox could write a PHP file into the web root.

Joomla Extension - acymailing.com - Unauthenticated arbitrary file deletion in AcyMailing Enterprise extension < 11.1.0 - A subscriber could store a path in a file-type custom field and have AcyMailing delete that file when the field was cleared, including files outside the upload folder such as configuration.php.

Froxlor 2.0.0 through 2.3.10 is vulnerable to stored cross-site scripting. When a customer (the lowest-privileged authenticated role) uploads an SSL certificate for one of their own domains, the Certificates API add()/update() methods parse it with openssl_x509_parse() and store the issuer organization (issuer['O']) value verbatim without sanitization. Froxlor's table-listing renderer then emits scalar cells through Twig's `raw` filter, disabling HTML auto-escaping, so when an administrator or reseller opens Domains > SSL certificates the attacker-supplied issuer value executes as script in the privileged user's session. This crosses a privilege boundary from customer to admin and can result in full administrator account takeover; because a Froxlor admin controls webserver, DNS, and PHP configuration applied by a cron job running as root, the issue can be further escalated to command execution as root on the managed server. The issue is fixed in Froxlor 2.3.12.

Froxlor through 2.3.10 does not enforce the mail.allow_external_domains policy in the EmailSender.add API command. When an administrator has enabled the allowed-sender feature but disabled external allowed-sender domains (mail.enable_allow_sender = 1, mail.allow_external_domains = 0), an authenticated customer with API access can still use EmailSender.add to register an arbitrary external sender address for their mailbox, which is stored despite the policy. This creates a bypass between the UI/administrator configuration and the API, and — where the generated mail configuration consumes the allowed-sender table — allows a customer to authorize sender identities outside their hosted domains, facilitating sender spoofing. Fixed in 2.3.12.

Froxlor 2.3.10 and earlier contain a TOCTOU race condition in the SSH key synchronization cron (lib/Froxlor/Cron/System/SshKeys.php, SshKeys::generateFiles). The containment/symlink validation is done only at check time; the live filesystem path is re-resolved as root at write time, with no path or file-descriptor pinning. On installations with system.allow_customer_shell=1, a customer can swap their ~/.ssh directory for a symlink after the check, causing the root-run cron to append the customer's public key to /root/.ssh/authorized_keys and chown /root/.ssh to the customer, resulting in full root compromise. Fixed in Froxlor 2.3.12.

froxlor versions before 2.3.12 fail to invalidate existing panel sessions, API keys, and 2FA trust cookies when a user password is changed. Attackers holding hijacked sessions, valid API keys, or 2FA trust tokens retain full account access after password rotation, bypassing incident response actions.

Froxlor through 2.3.10 stores only a numeric user ID in remembered-2FA tokens (panel_2fa_tokens) without recording the account namespace, and the remembered-token lookup during login is not constrained to the customer or administrator account type. Because customer and administrator IDs are allocated from separate namespaces, a token issued to a customer with a given ID also matches an administrator with the same ID, allowing bypass of the administrator's TOTP second factor when the password is known.

Froxlor before 2.3.13 returns the ssl_key_file column — which stores the raw PEM TLS private-key content — verbatim in the JSON responses of the Certificates.get and Certificates.listing API commands, because the results of the underlying domain_ssl_settings queries are passed through ApiCommand::response() without any field stripping or allowlist. A low-privileged authenticated customer API caller can retrieve the private keys of their own domains' certificates, including Let's Encrypt keys that Froxlor generates server-side and stores root-only (0600) and to which the customer otherwise has no filesystem access; reseller and customers_see_all admin accounts can dump the private keys of other principals through the same sink. Disclosed keys enable domain impersonation, passive decryption of captured TLS traffic, and active machine-in-the-middle attacks.

Kyverno before 1.19.1 contains a namespace isolation bypass in the apiCall context entry of namespaced Policy resources due to inconsistent path interpretation between validation and execution. A low-privilege tenant can use percent-encoded dot-segments in urlPath to bypass namespace checks and read resources from other namespaces using the Kyverno admission controller's ServiceAccount credentials.

Kyverno before 1.19.1 is vulnerable to SSRF. The default egress blocklist and scoped-token control were only wired into the new CEL http.Get/Post library, not into the legacy apiCall service executor or the GlobalContextEntry external-API path. These paths use a plain net/http client with no egress filtering and no validation of the configured service URL, allowing a ClusterPolicy or GlobalContextEntry author to cause Kyverno to issue GET/POST requests to arbitrary hosts, including cloud metadata endpoints and internal services. The executor also attaches Kyverno's projected ServiceAccount token to the attacker-chosen destination. Fixed in 1.19.1.

Kyverno is a policy engine for Kubernetes. In versions 1.14.0 through 1.19.0, the ImageValidatingPolicy (policies.kyverno.io/v1beta1) evaluator never reads the spec.images and spec.allowedValues fields of a PolicyException. Any PolicyException whose policyRefs and matchConditions match a resource causes image signature verification to be skipped for the entire resource rather than only for the listed images or values, so an exception intended to exempt a single trusted image exempts every image on the matched resource(s). As a result, unsigned or untrusted images can be admitted to the cluster without signature verification. This differs from ValidatingPolicy, GeneratingPolicy, and MutatingPolicy, which treat the same field as a partial exemption. The issue is fixed in version 1.19.1.

Kyverno 1.16.0 through 1.19.0 registers the globalcontext.Lib CEL library in its policy environment without confining it to the policy's namespace, unlike the sibling libraries (resource.Lib, http.Lib, configMap loader) which are handed the policy namespace. A tenant who can create a namespaced policy (e.g. NamespacedValidatingPolicy, and likewise the namespaced mutating, deleting, generating, and image-validating policy kinds) in their own namespace can call globalContext.get("<entry>", "") and receive the full cached contents of a cluster-scoped GlobalContextEntry, including data cached from namespaces the tenant has no RBAC permission to read. No admission validation rejects such calls. Fixed in 1.19.1.

nodemailer before 10.0.6 contains a denial of service vulnerability in the addressparser free-text fallback regex pattern that exhibits quadratic backtracking behavior. Attackers can supply crafted email header values with long whitespace-free runs to block the Node.js event loop for tens of seconds, causing service unavailability.

Adminer 6.0.0 through 6.0.1, when the official ClickHouse driver plugin (plugins/drivers/clickhouse.php, rewritten in 6.0.0) is loaded, is vulnerable to pre-authentication server-side request forgery. An unauthenticated attacker can submit auth[driver]=clickhouse with auth[server] set to an arbitrary URL (for example http://127.0.0.1:18089), causing the Adminer server to issue an HTTP POST containing 'SELECT version()' to that host. In rootQuery(), if the target returns a status outside 200-299 (other than 401/403), the raw HTTP response body is assigned to the connection error and rendered on the login page, so the attacker receives the full response body of the internal service. This enables internal network/port reconnaissance and disclosure of sensitive information contained in internal error pages (stack traces, internal hostnames, file paths, configuration identifiers). Fixed in Adminer 6.0.2.

Hugo versions from v0.162.0 before v0.166.0 contain a case-sensitive validation flaw in the security.http.urls IP-literal deny rule that allows attackers to bypass restrictions. Attackers can use mixed-case URL schemes in resources.GetRemote calls to fetch from restricted IP addresses like localhost.

Hugo, a static site generator, in versions after v0.123.0 and before v0.166.0, has a flaw in its symlink confinement checks. A theme or module in themes/ (or a vendored module) can contain a symlink at a mount root, allowing files behind such a symlink to be read during a site build and published to public/, bypassing the rule that theme and module mount sources must be local paths.