CVE Vulnerability Catalog

A vulnerability in Kibana allows authorization bypass through a user-controlled key (CWE-639). An authenticated user with the Timeline feature privilege in a Kibana space could enumerate, read, modify, and delete draft Timeline objects belonging to other users in the same space. Read access is sufficient for enumeration and disclosure; the Timeline write privilege is required for modification and deletion.

The Ultra Addons for Contact Form 7 plugin for WordPress is vulnerable to Arbitrary File Upload due to insufficient file type validation in the 'uacf7_wpcf7_mail_components' function in all versions up to, and including, 3.5.50. This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible. Note: This is only exploitable when the plugin's PDF Generator module is enabled, which is disabled by default.

The miniOrange OTP Login, Verification and SMS Notifications plugin for WordPress is vulnerable to Authentication Bypass via the mo_wp_login_intent parameter in all versions up to, and including, 5.5.5. This is due to a missing password-intent guard in the skip_pass_fallback-enabled configuration branch of the mo_by_pass_login() function, which treats administrator role membership alone as sufficient authentication whenever the unauthenticated, unverified POST parameter mo_wp_login_intent is submitted with the value otp, causing mo_get_user() to skip wp_authenticate_username_password() and resolve a WP_User purely from a username lookup. This makes it possible for unauthenticated attackers to log in as any existing administrator account by supplying only a known username and an empty password alongside mo_wp_login_intent=otp, with no password or OTP verification required. Exploitation is conditional on a site administrator having simultaneously enabled the following plugin options: WP Login OTP, Login with Only OTP, Allow Users to Login with Username and Password, and Admin OTP Bypass.

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 an unauthenticated remote code installation vulnerability. An attacker without authentication can cause malicious code to be installed in the application.

Joomla Extension - lomart.fr - Various SQL injection vectors in UP plugin extension 5.0.0-5.2.0, 6.0.0-6.0.29.

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.

The Joomla YouTube Gallery extension (joomlaboat.com) in versions below 5.7.3 contains an unauthenticated SQL injection vulnerability in the video search and sorting functionality. An attacker can inject SQL commands into read queries.

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.

Credential disclosure vulnerability in Froxlor before version 2.3.12 in the DirProtections.listing API command that returns htpasswd password hashes. Authenticated API users can retrieve bcrypt password hashes for protected-directory users, enabling offline cracking attempts and exposure of reused credentials.

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 in versions 2.3.10 and earlier contains an incomplete fix for GHSA-c3p2 — Validate::validateUrl rejects CR/LF characters only in the path, query, and fragment components and never inspects the userinfo (user:pass@) components. An authenticated low-privilege customer with subdomain-create rights can supply a subdomain redirect URL carrying a CR/LF payload in the userinfo portion, which passes validation and is written verbatim into the generated nginx or Apache vhost configuration. Froxlor regenerates and reloads the web-server configuration as root, so injected directives take effect server-wide.

Froxlor in versions 2.3.10 and earlier contains an incomplete fix for GHSA-75h4-... — the customer data-export (DataDump) cron fails to validate intermediate path components of the export destination. Froxlor\FileDir::makeCorrectDir() contains an off-by-one in its path-component walk that skips the first segment below the customer home directory, and the guard in ExportCron.php checks only the final component with is_link(). An authenticated customer with the export feature enabled can schedule an export into a genuine subdirectory of their own webspace, then replace an intermediate path component with a symlink before the root-owned cron runs. The cron's 'chown -R' then recursively changes ownership of the linked directory tree (e.g. /etc) to the customer's UID, yielding host root and cross-tenant compromise.

Froxlor through 2.3.10 is vulnerable to arbitrary file deletion via symlink following in the FTP data deletion cron task. Cron task 8 (deleteFtpData), queued when an FTP account is deleted, calls FileDir::makeCorrectDir() without the $fixed_homedir argument, so the symlink component walk is skipped, and then executes 'rm -rf' as root on the resulting path with string-level guards only. Because makeCorrectDir() appends a trailing slash, GNU rm dereferences a symlink used either as an intermediate or final path component. An authenticated customer who can write to the FTP home directory can plant a symlink between task insertion and cron execution, causing the root cron job to recursively delete arbitrary directory trees.

Froxlor before 2.3.12 does not restrict or escape the system.letsencryptchallengepath setting — unlike sibling settings hardened in GHSA-33mp, the field has no string_regexp or required_otp guard, and its value is concatenated unescaped into the acme.sh command line built in lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php and executed by the root cron via FileDir::safe_exec. Because safe_exec only blacklists shell metacharacters such as ; | & > < \ $ ~ ?, spaces and quotes survive and the value is word-split into additional acme.sh arguments. An administrator, or any actor able to write settings (e.g. through the settings-import API), can inject acme.sh options such as --renew-hook, --pre-hook or --post-hook to obtain arbitrary command execution as root at the next Let's Encrypt cron run, or use --config-home/--cert-home for arbitrary file writes.

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 through 2.3.10 disables a user's two-factor authentication immediately upon an unauthenticated-triggerable GET request to the 2FA management page (e.g. /customer_index.php?page=2fa&action=delete), with no confirmation, re-authentication, or CSRF token. The global CSRF middleware only covers POST/PUT/PATCH/DELETE requests, and the session cookie is set to SameSite=Lax, so a cross-site top-level navigation (link click or redirect) carries the victim's session and silently clears type_2fa/data_2fa. Both the customer and admin 2FA handlers are affected. An attacker who lures a logged-in panel user into following a crafted link reduces that account to password-only authentication, which can be chained with a compromised password for account takeover. Fixed in 2.3.12.