| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| The `@ai-sdk/harness-opencode` tool connects HarnessAgent to OpenCode through a sandboxed bridge. Prior to version 1.0.28, the tool relay authorizes requests from any process whose command line contains an allowed helper script path (`host-tool-mcp.mjs`). This allows untrusted code executing in the sandbox to invoke arbitrary host-exposed tools including secret lookups, deployment operations, and cloud API calls without a corresponding model-authorized tool-call event. Exploitation requires a Linux environment (the vulnerable fallback checks `process.platform === 'linux'` and reads `/proc`); an active harness session with one or more host-provided tools; and untrusted code executing in the sandbox (e.g. a malicious dependency, build script, or lifecycle hook) The fix in version 1.0.28 removes the process-path authorization fallback entirely. Relay requests are now only accepted after exact, short-lived, one-time authorization matching the tool name and input from a bridge-observed model event. Some workarounds are available. Do not run the OpenCode harness on untrusted repositories or with untrusted dependencies, and/or limit host-exposed tools to non-sensitive operations when working with untrusted code. |
| The `@ai-sdk/harness-opencode` tool is an HarnessV1 adapter backed by @openai/codex-sdk, which drives the codex command line interface. Prior to version 1.0.29, the tool relay authorizes requests from any process whose command line contains an allowed helper script path (the Codex CLI shim). This allows untrusted code executing in the sandbox to invoke arbitrary host-exposed tools, including secret lookups, deployment operations, and cloud API calls without a corresponding model-authorized tool-call event. Exploitation requires a Linux environment (the vulnerable fallback checks `process.platform === 'linux'` and reads `/proc`); an active harness session with one or more host-provided tools; and untrusted code executing in the sandbox (e.g. a malicious dependency, build script, or lifecycle hook) The fix in version 1.0.29 removes the process-path authorization fallback entirely. Relay requests are now only accepted after exact, short-lived, one-time authorization matching the tool name and input from a bridge-observed model event. Some workarounds are available. Do not run the Codex harness on untrusted repositories or with untrusted dependencies, and/or limit host-exposed tools to non-sensitive operations when working with untrusted code. |
| NextCRM is open-source customer relationship management (CRM) software. Versions prior to 0.12.0 have a Broken Access Control (BAC) vulnerability in the `activateUser` and `deactivateUser` Next.js Server Actions of NextCRM. The application fails to verify if the requesting user holds the `admin` role. Consequently, any authenticated user (even those with the lowest `member` or `viewer` roles) can arbitrarily activate or deactivate any user account in the system, including the main administrator. Version 0.12.0 fixes the issue. |
| Microweber CMS through 2.0.20 contains a path traversal vulnerability in the static file controller that allows unauthenticated remote attackers to read arbitrary files by supplying directory traversal sequences in the path query parameter. Attackers can send a single unauthenticated HTTP GET request exploiting the failure of normalize_path() to strip traversal sequences, disclosing sensitive files such as environment configuration files containing credentials and system files. |
| Skipper contains an incomplete fix for CVE-2026-50197 in which oversized request bodies bypass Open Policy Agent (OPA) deny-on-presence Rego policies. When a request body exceeds the configured maxBodyBytes limit, Skipper forwards the full payload to the upstream service while OPA evaluates against an empty parsed_body, so policies that deny requests based on body content are not enforced and forbidden actions proceed. No fixed version is available; v0.27.26 adds documentation guidance only. |
| 9router 0.4.59 (fixed in 0.4.60) contains a chain of vulnerabilities: a hardcoded default password (123456) that authenticates any fresh installation, a bypass of the LOCAL_ONLY network gate via a spoofed Host header, and unvalidated arguments passed to child_process.spawn() when registering MCP plugins. A remote, unauthenticated attacker can log in with the default credential, spoof the Host header to reach local-only routes, and register a malicious MCP plugin (e.g. node -e <payload>) to achieve arbitrary code execution on the host operating system when the plugin's SSE endpoint is triggered. |
| 9Router before 0.4.72 contains a server-side request forgery (SSRF) vulnerability in the /v1/web/fetch endpoint. The endpoint accepts a user-controlled url parameter and passes it to a configured external scraping provider (Firecrawl, Jina Reader, Tavily, or Exa) to fetch content. The URL is only validated as syntactically valid via new URL() with no blocklist for private IP ranges, cloud metadata endpoints (e.g., 169.254.169.254), link-local addresses, or internal hostnames. An authenticated or locally-connected user can cause the server to fetch arbitrary internal URLs and have the response content returned, enabling read-access SSRF that can expose cloud metadata credentials, reach internal services, and bypass authentication on localhost endpoints. |
| Cal.com (calcom/cal.diy) before 5.9.9 is vulnerable to unauthenticated remote code execution because it bundles a version of Next.js whose React Server Components (RSC) request handling deserializes attacker-controlled input. A remote attacker can send a crafted RSC request to the server and cause arbitrary code to be executed during server-side processing, without authentication or user interaction. The flaw derives from the upstream Next.js vulnerability CVE-2025-55182 and is resolved in 5.9.9 by updating the affected dependency. |
| Cal.com (calcom/cal.diy) versions through 4.7.15 contain a stored cross-site scripting vulnerability. The single booking view (e.g., https://app.cal.com/booking/<id>) renders booking-question field labels via React's dangerouslySetInnerHTML without sanitizing or escaping user input. An attacker who can create an event type with a malicious booking-question label can inject arbitrary HTML/JavaScript that executes when a victim opens the crafted booking URL. The issue is fixed in v4.7.16. |
| cal.com (calcom repository, later renamed cal.diy) is affected by a repository takeover vulnerability in its GitHub Actions workflows. The workflow pr.yml uses the pull_request_target trigger with the repository's default write permissions and passes them down to check-types.yml. check-types.yml then performs a 'dangerous' checkout of the attacker-submitted pull request code (via the dangerous-git-checkout action) and subsequently executes it (through yarn install and package.json scripts). An attacker can open a pull request whose code runs arbitrary commands with the repository's write-scoped GITHUB_TOKEN, allowing them to push commits, merge or mutate pull requests, add or delete comments, and delete or force-push branches, thereby compromising the repository. The main branch is affected; no patched version is available. |
| Cal.com (repository calcom/cal.diy) in versions <= 4.7.15 is vulnerable to cross-site scripting (XSS) on the publicly accessible single booking view (e.g., /booking/<id>). Booking question (form field) labels are rendered via React's dangerouslySetInnerHTML without proper input sanitization or CSP, so an attacker who can create an event type with a malicious booking question label can inject arbitrary HTML/JavaScript that executes when a victim visits the booking view URL. Self-hosted instances with open registration are particularly at risk. The issue is fixed in version 4.7.16. |
| A vulnerability was identified in localstack serverless-localstack up to 1.4.0. The affected element is an unknown function of the file src/index.js of the component Configuration Handler. The manipulation of the argument custom.localstack.docker.compose_file leads to os command injection. An attack has to be approached locally. The exploit is publicly available and might be used. The project was informed of the problem early through an issue report but has not responded yet. |
