YesWiki versions prior to 4.7.0 have a SQL injection vulnerability in the despam.php script. The flaw arises because the 'from' POST parameter is escaped but used in an unquoted INTERVAL context, allowing authenticated administrators to perform blind SQL injection. This can lead to unauthorized reading of database contents, including user password hashes.
YesWiki versions prior to 4.7.0 have a vulnerability in the AclService::updateRequestWithACL function where usernames are interpolated into SQL LIKE patterns without escaping wildcard characters. This allows self-registered attackers to bypass read access controls by using specially crafted usernames containing wildcards, enabling unauthorized reading of restricted pages and Bazar entries via the public Bazar listing API.
YesWiki versions prior to 4.7.0 have 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, allowing arbitrary outbound requests. The vulnerability enables bypassing extension checks via query-string suffixes or redirects, potentially exposing cloud metadata credentials, internal services, or local files. Responses are stored in a web-accessible directory, increasing exposure risk.
YesWiki versions from 4.6.0 up to but not including 4.7.0 contain an information disclosure vulnerability. This flaw allows unauthenticated attackers to view assembled SQL queries by appending the 'showreq' parameter to public Bazar listing API requests. The disclosed information includes database table names, JSON storage paths, ACL filter logic, and collation details, which could facilitate targeted SQL injection attacks.
YesWiki versions prior to 4.7.0 have a reflected cross-site scripting (XSS) vulnerability. This flaw allows unauthenticated attackers to inject malicious 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 attacker-controlled scripts in the context of authenticated users.
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 lead to page defacement by forcing unintended layouts on pages using the bazarliste action when visitors follow a crafted link.
YesWiki versions prior to 4.7.0 have a server-side request forgery (SSRF) vulnerability in the DuplicationManager::downloadFile() function. This flaw allows authenticated administrators to send arbitrary outbound requests by manipulating the files array. Exploitation can lead to attackers posting file:// or internal URLs to the /api/pages/{tag}/duplicate endpoint, resulting in local files, cloud metadata, or database credentials being stored in a publicly accessible directory.
OpenPanel versions before 3.0.0 have an information disclosure vulnerability that allows users with read-level project access to retrieve sensitive integration secrets. This occurs because the notification.rules query does not properly redact integration credentials. Exploiting this flaw, attackers can obtain Slack bot tokens, webhook URLs, and authorization headers, potentially enabling unauthorized actions against external systems.
OpenPanel versions prior to 3.0.0 have an unauthenticated SQL injection vulnerability in the ClickHouse database via the projectId parameter on the /live/visitors/:projectId WebSocket endpoint. This endpoint lacks session and project-access checks, allowing remote attackers to inject SQL commands. Exploitation enables attackers to read data belonging to other tenants by leveraging UNION queries or boolean count oracles. Additionally, project members can exploit a similar injection through the cohort.preview timeframe values.
OpenPanel versions prior to 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 within the worker process. The vulnerability has a high severity score of 8.8 CVSS v3.1.
OpenPanel versions prior to 3.0.0 have an improper escaping vulnerability in the sankey.service.ts component. Authenticated project members can supply backslashes in event names to break ClickHouse string literals. This causes parse errors in the chart.sankey procedure, disabling the Sankey chart endpoint for the project.
OpenPanel versions prior to 3.0.0 contain an SQL injection vulnerability that allows authenticated users to read data across tenant boundaries. By supplying a crafted property parameter to profile.values, attackers can inject SQL SELECT expressions with custom FROM/WHERE clauses, bypassing project_id scoping to access other projects' profiles, events, and sessions.
OpenPanel versions prior to 3.0.0 contain 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 submit specially crafted cohort.preview filters that include subqueries within argMax, cityHash64, or comparison clauses, potentially exposing data from other tenants in the ClickHouse database.
OpenPanel versions before 3.0.0 have a missing authentication vulnerability that allows unauthenticated attackers to access the Bull Board dashboard on the worker HTTP port. Attackers can query queue data and invoke APIs to add, retry, or clean jobs without authentication.
OpenPanel versions before 3.0.0 have a missing authorization vulnerability in the onboarding.project tRPC mutation. This flaw allows non-admin organization members to create projects and mint write-type ingestion credentials, bypassing intended admin-only restrictions. Exploitation enables attackers to obtain plaintext secrets, inject fake analytics events, poison business metrics, and consume the organization's usage budget.
OpenPanel versions prior to 3.0.0 have a missing authorization vulnerability that permits unauthenticated attackers to read annotations from any project. This occurs via the public reference.getChartReferences tRPC procedure, which can be invoked with guessable slug-based project IDs to access cross-tenant annotation data such as titles, descriptions, and dates.
DOMPurify versions from 3.4.4 up to but not including 3.4.17 contain a vulnerability where the SAFE_FOR_TEMPLATES feature can be bypassed. This allows attackers to preserve template expressions in attached shadow roots when using certain DOMPurify return modes. By splitting expressions across text nodes separated by disallowed elements, attackers can cause these expressions to merge after sanitization and be evaluated by downstream template engines, leading to cross-site scripting (XSS).
OpenPanel versions prior to 3.0.0 have a missing authorization vulnerability in the event.bots tRPC procedure. This flaw allows unauthenticated attackers to send anonymous requests with a projectId and retrieve bot-event details such as names, types, and paths. The vulnerability exposes information for private or password-protected projects by only verifying the existence of a shareOverview row, thereby revealing internal routes.
OpenPanel versions prior to 3.0.0 have an information disclosure vulnerability that allows users with read-level access to a project to retrieve argon2id hashes of ingestion credentials. This occurs via the client.list tRPC query, which returns full Client rows including the secret column. This exposure enables offline verification of leaked secrets without generating audit trails.
OpenPanel versions prior to 3.0.0 have an SQL injection vulnerability in the ConversionService.getConversion function. This flaw allows project-read members and share-link holders to inject arbitrary ClickHouse SQL via unescaped event names and dates. Exploitation can bypass project_id scoping by injecting conditions like OR 1=1, enabling unauthorized access to other tenants' analytics data.