YesWiki versions prior to 4.7.0 contain a server-side request forgery (SSRF) vulnerability in the Bazar CSV import function copyUrlToLocalFile(). Authenticated administrators can exploit this by supplying crafted URLs in CSV or image fields, enabling arbitrary outbound requests. This includes bypassing extension checks via query strings or redirects to access cloud metadata credentials, internal services, or local files. The responses are stored in a web-accessible directory, increasing exposure risk. The vulnerability is fixed in version 4.7.0.
YesWiki versions prior to 4.7.0 contain a server-side request forgery (SSRF) vulnerability in the DuplicationManager::downloadFile() function. This flaw allows authenticated administrators to make arbitrary outbound requests by manipulating the files array during a POST request to the /api/pages/{tag}/duplicate endpoint. Exploitation can lead to unauthorized access to local files, cloud metadata, or database credentials, which are then stored in the publicly accessible files/ directory. The vulnerability is fixed in version 4.7.0.
YesWiki versions from 4.6.2 up to but not including 4.7.0 have a vulnerability in the HttpSignatureService::verifySignature() method where replay protection is missing. This allows attackers who capture a signed request to the /api/forms/{formId}/actor/inbox endpoint to replay that request later, potentially re-executing sensitive actions such as Delete, Update, Follow, or Undo.
YesWiki versions prior to 4.7.0 contain a stored cross-site scripting (XSS) vulnerability in the referrers_sites.php handler. This flaw allows unauthenticated attackers to inject malicious scripts via crafted Referer headers. The injected scripts execute in the context of any user visiting the referrer-sites page, potentially enabling same-origin authenticated actions. The vulnerability is fixed in version 4.7.0.
YesWiki versions before 4.7.0 have a reflected cross-site scripting (XSS) vulnerability. This flaw allows unauthenticated attackers to inject JavaScript by manipulating query parameters that correspond to missing Bazar field names. The vulnerability arises because the application falls back to unsanitized user input rendered with Twig |raw templates, enabling execution of malicious scripts in the context of authenticated users. The issue is fixed in version 4.7.0.
YesWiki versions prior to 4.7.0 have a path traversal vulnerability in the BazarListeAction component. This flaw allows unauthenticated attackers to manipulate the template GET parameter to select arbitrary templates within the @bazar Twig namespace. Exploitation can cause page defacement for visitors who access crafted links. The vulnerability is fixed in version 4.7.0.
YesWiki versions prior to 4.7.0 contain a vulnerability in the AclService::updateRequestWithACL function where usernames are interpolated into SQL LIKE patterns without properly escaping wildcard characters. This allows self-registered attackers to bypass read access controls by using usernames with wildcard characters such as _ or %, enabling unauthorized reading of restricted pages and Bazar entries via the public Bazar listing API. The issue is fixed in version 4.7.0.
YesWiki versions from 4.6.0 up to but not including 4.7.0 have an information disclosure vulnerability. Unauthenticated attackers can exploit this flaw by adding the 'showreq' parameter to public Bazar listing API requests. This allows them to view assembled SQL queries, revealing sensitive information such as table names, JSON storage paths, ACL filter logic, and collation details. This information can facilitate targeted SQL injection attacks. The vulnerability is fixed in version 4.7.0.
OpenPanel versions prior to 3.0.0 have an information disclosure vulnerability that allows read-level project members to access plaintext integration secrets. This occurs because the notification.rules query does not redact sensitive integration data, exposing Slack bot tokens, webhook URLs, and authorization headers. The vulnerability is fixed in version 3.0.0.
OpenPanel versions prior to 3.0.0 contain an unauthenticated SQL injection vulnerability in the ClickHouse database via the projectId parameter of the /live/visitors/:projectId WebSocket endpoint. This endpoint lacks session and project-access checks, allowing remote attackers to inject SQL commands. Exploitation can enable reading of other tenants' events and profiles. Project members can also inject SQL through cohort.preview timeframe values. The vulnerability is fixed in OpenPanel 3.0.0.
OpenPanel versions prior to 3.0.0 have a missing authentication vulnerability that allows unauthenticated attackers to access the Bull Board dashboard on the worker HTTP port. This access enables attackers to query queue data and invoke APIs to add, retry, or clean jobs, as well as read metrics and datastore health information.
OpenPanel versions prior to 3.0.0 have an improper escaping vulnerability in the sankey.service.ts component. Authenticated project members can exploit this by submitting crafted event names containing backslashes, which break ClickHouse string literals. This causes parse errors that disable the Sankey chart endpoint for the project.
OpenPanel versions before 3.0.0 have a vulnerability that exposes sensitive information by logging database connection URLs and email template data to standard output logs. This includes database credentials and password-reset tokens when certain environment variables are unset. The issue is fixed in version 3.0.0.
OpenPanel versions prior to 3.0.0 have an SQL injection vulnerability in the ConversionService.getConversion function. This flaw allows users with project-read permissions or share-link holders to inject malicious ClickHouse SQL via unescaped event names and date parameters. Exploitation can bypass project_id restrictions, enabling unauthorized access to other tenants' analytics data. The vulnerability is rated high severity with a CVSS score of 7.1 and was fixed in version 3.0.0.
OpenPanel versions before 3.0.0 have a SQL injection vulnerability in the profileColumnAccess function within cohort.service.ts. This flaw allows project-read members to inject SQL by providing unescaped profile filter column names. Exploitation can enable attackers to execute subqueries within cohort.preview filters, potentially reading data from other tenants' ClickHouse databases. The vulnerability is fixed in OpenPanel version 3.0.0.
OpenPanel versions before 3.0.0 have a sandbox escape vulnerability in the JavaScript runtime validator. This flaw allows a project member with write access to bypass the AST allowlist by aliasing the Function constructor, enabling arbitrary code execution in the worker process. The vulnerability is fixed in version 3.0.0.
OpenPanel versions before 3.0.0 have an authorization bypass vulnerability that allows unauthenticated attackers to access any project's annotations. This occurs via the public reference.getChartReferences tRPC procedure, where attackers can use guessable slug-based project IDs to retrieve annotation titles, descriptions, and dates across tenants.
OpenPanel versions prior to 3.0.0 have an improper access control vulnerability in the event.bots tRPC procedure. This flaw allows unauthenticated attackers to read bot event information by sending anonymous requests with a projectId, bypassing authorization checks. As a result, attackers can retrieve bot-event names, types, and paths for private or password-protected projects, exposing internal routes.
OpenPanel versions before 3.0.0 have an SQL injection vulnerability that allows authenticated users to read data across tenants. By manipulating the profile.values property parameter, attackers can inject custom SQL SELECT statements to bypass project_id restrictions and access other projects' profiles, events, and sessions. This vulnerability is fixed in version 3.0.0.
OpenPanel versions prior to 3.0.0 contain an SQL injection vulnerability that allows authenticated users to bypass tenant scoping. This occurs because unescaped profile filter names are injected into a JOIN subquery, enabling attackers to manipulate the query with a crafted filter name and trailing comment. This bypasses the project_id WHERE clause and allows reading events from all projects.