| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Joomla Extension - themexpert.com - Authenticated stored XSS in JMedia Extension < 1.6.0 - The Joomla extension JMedia is vulnerable to a stored XSS vulnerability. Unsanitised SVG uploads served without nosniff, leading to stored/reflected XSS. |
| Joomla Extension - themexpert.com - Authenticated PHP code execution in Quix Page Builder < 6.2.1 - The Joomla extension Quix Page Builder Pro is vulnerable to an authenticated PHP code execution. Authenticated builder user (core.create/core.edit) could inject PHP tags in element content, that got executed via view-cache include(). Requires caching on (default). |
| Joomla Extension - themexpert.com - Authenticated stored XSS in Quix Page Builder < 6.2.1 - The Joomla extension Quix Page Builder Pro is vulnerable to an authenticated stored XSS vulnerability. Authenticated builder users could break out of id/class fields that render for public users. |
| Joomla Extension - themexpert.com - Information disclosure in Quix Page Builder < 6.2.1 - The Joomla extension Quix Page Builder Pro is vulnerable to an information disclosure. Raw exceptions reflected in AJAX handler responses. |
| Joomla Extension - themexpert.com - Unauthenticated path traversal / file read in Quix Page Builder < 6.2.1 - The Joomla extension Quix Page Builder Pro is vulnerable to a unauthenticated path traversal via form elements. Unauthenticated users frontend users are allowed traversal paths and read arbitrary files. Requires a published page with a Form element. |
| Joomla Extension - hikashop.com - Open redirect in Hikashop < 6.5.2 - The Joomla extension Hikashop is vulnerable to an open redirect. |
| Joomla Extension - dj-extensions.com - Unauthenticated arbitrary file upload in DJ-jDownloads < 4.1.6 - The Joomla extension JDownloads is vulnerable to an unauthenticated file upload, leading to full RCE. |
| Joomla Extension - dj-extensions.com - Unauthenticated arbitrary file upload in DJ-Classifieds < 3.11.2 - The Joomla extension DJ-Classifieds is vulnerable to an unauthenticated file upload, leading to full RCE. |
| HyperDX before 2.31.0 contains a server-side request forgery vulnerability that allows authenticated team members to direct the server to make requests to arbitrary internal network destinations by supplying a caller-controlled URL to the webhook test endpoint. Attackers can bypass the insufficient hostname blacklist validation in the webhook handler to enumerate internal services, interact with internal containers, or access cloud instance metadata services including provider metadata endpoints. |
| HyperDX before 2.31.0 contains a server-side request forgery vulnerability that allows authenticated team members to direct the server to arbitrary internal destinations by supplying a caller-controlled host parameter to the ClickHouse proxy test endpoint with no URL validation or allowlist enforcement. Attackers can exploit the reflected error responses from the endpoint to disclose internal service response bodies, enabling access to internal APIs, container services, and cloud provider metadata endpoints. |
| Joomla Extension - balbooa.com - Authentication bypass in Gridbox < 1.6.0 - The Joomla extension Gridbox is vulnerable an authenticated bypass, potentially leading to full admin access. |
| Glance through 0.8.5 contains an IP address spoofing vulnerability in the authentication handler that allows unauthenticated attackers to bypass brute-force lockout protections by supplying arbitrary values in the X-Forwarded-For request header when the server proxied option is enabled. Attackers can manipulate the leftmost value of the X-Forwarded-For header to make each login attempt appear to originate from a distinct IP address, preventing the per-IP failed-login counter from reaching the lockout threshold and enabling unlimited credential guessing against the authentication endpoint. |
| Huginn through 2022.08.18 contains a server-side request forgery vulnerability in the fetch_url method of ScenarioImport that allows authenticated users to make arbitrary HTTP requests by submitting crafted URLs. Attackers can probe internal network services, enumerate ports via error signatures, and access cloud metadata endpoints to retrieve sensitive credentials. |
| Paymenter is a free and open-source webshop solution for management of hosting services. In versions prior to 1.5.0, the email update functionality fails to invalidate the existing verification state when a user changes their email address, allowing a verified account to retain its verified status after switching to an unverified or unowned email address. When a user updated their email address, the system did not reset or revalidate the associated email verification status. As a result, the verification column remained set to “true” even after the email address was changed. Exploitation could potentially result in: misrepresentation of email ownership, bypass of verification-based trust assumptions, and abuse of features gated behind verified status. No direct unauthorized access to other users accounts or data is possible through this issue alone. This issue has been fixed in version 1.5.0. |
| Paymenter is a free and open-source webshop solution for management of hosting services. In versions prior to 1.5.0, the PayPal webhook endpoint /extensions/paypal/webhook processes the PAYPAL-CERT-URL HTTP header without validation, allowing attackers to control server-side HTTP request destinations. This value is passed directly into a server-side HTTP request via file_get_contents, allowing attackers to control the destination of the request. No allowlist, validation, or signature verification is applied to the header before usage. As a result, the application can be coerced into performing HTTP requests to attacker-controlled or internal network destinations. This vulnerability allows remote unauthenticated attackers to induce server-side HTTP GET requests to arbitrary external or internal endpoints. Depending on network configuration, this may lead to: blind SSRF to external attacker-controlled systems, and potential access to internal network services No direct response data is returned to the attacker (blind SSRF), but the issue may still enable sensitive network probing or data exfiltration via side channels. This issue has been fixed in version 1.5.0. |
| Paymenter is a free and open-source webshop solution for management of hosting services. In versions prior to 1.5.0, the ticket creation endpoint accepts a user-supplied service identifier without enforcing ownership validation, allowing authenticated users to create support tickets referencing services belonging to other accounts by modifying the service ID in the request. An attacker could modify the service ID value in the client-side request and successfully create a ticket associated with another user's service.
The vulnerability requires authentication and does not provide direct access to service contents or customer data. However, referenced service information could become visible to support personnel handling the ticket. Successful exploitation could allow an authenticated user to: create support tickets referencing services belonging to other users, potentially cause support staff to interact with or review unrelated customer services. The vulnerability did not allow direct access to another user's service, modification of another user's service or retrieval of confidential service data through the vulnerable endpoint itself. This issue has been fixed in version 1.5.0. |
| VSee Clinic 7.1.26 and VSee Clinic API 1.3.0 exposes cleartext SFTP credentials in the HTTP responses of three unauthenticated endpoints. The credentials are present in these responses only when SFTP connections have been configured within the application. No authentication is required to retrieve these credentials. An unauthenticated remote attacker who observes any of these HTTP responses on an instance where SFTP is configured can obtain the credentials and use them to access the associated SFTP server. |
| VSee Clinic 7.1.26 and API 1.3.0 contain an Insecure Direct Object Reference (IDOR) vulnerability in the /v1.3.0/api/files endpoint. An authenticated attacker can manipulate the 'remark' request parameter to enumerate, retrieve, and delete files belonging to other users on the application server. |
| Paymenter is a free and open-source webshop solution for management of hosting services. In versions prior to 1.5.1, the checkout component improperly filters URL-writable properties, allowing authenticated users to inject arbitrary key-value pairs into server provisioning parameters. Because bundled server extensions prioritize these user-supplied properties over administrator-defined configurations, a regular user can override hosting plans and resource limits at checkout without special privileges. The Checkout Livewire component's $checkoutConfig property exposed via URL query parameters, only validating keys explicitly defined by an extension's configuration method, allowing any undefined injected keys to bypass validation entirely. These unsanitized keys are then stored directly in the database by the cart component and later passed to server extensions during provisioning, enabling user-injected data to override intended administrator settings. Depending on the active extension, this leads to unauthorized overrides of core resource limits (such as CPU, RAM, storage, or package tiers). No administrative privileges are required to exploit this vulnerability. This issue has been fixed in version 1.5.1. |
| Paymenter is a free and open-source webshop solution for management of hosting services. In versions prior to 1.5.5, the credit payment implementation in app/Livewire/Invoices/Show.php executes a pessimistic row lock (lockForUpdate()) outside of an active database transaction. Because MySQL/MariaDB requires an enclosing transaction to enforce row-level locks, the guard is ineffective. Concurrent payment requests can exploit this race condition to read the same credit balance simultaneously, allowing users to pay multiple invoices using the same credit balance. In database systems like MySQL, a row lock only works inside a formal transaction; without one, the lock is completely ignored. Because there is no active lock, two payment requests sent at the exact same millisecond can look at the database at the same time. Both requests see the original credit balance, decide it is sufficient, and approve the payment. Because the payment processes successfully through ExtensionHelper::addPayment(), the application provisions the corresponding services or digital goods, resulting in direct financial or resource loss to the platform. This issue has been fixed in version 1.5.5. |
