An integer overflow vulnerability exists in llama.cpp versions from 0.1.0 up to but not including 0.6.0. The flaw occurs in the gguf_init_from_reader function, where attackers can supply tensor shapes whose product wraps to zero, bypassing tensor element-count validation. This allows crafting GGUF files with extremely large tensor extents that overflow internal byte count calculations, leading to out-of-bounds memory access.
A heap out-of-bounds write vulnerability exists in llama.cpp before commit b10261 in the function llm_tokenizer_plamo2::build. This flaw allows attackers to corrupt heap memory by supplying crafted GGUF models with BYTE-typed token text containing negative parsed values. The vulnerability can cause crashes or potentially enable code execution during model loading.
CVE-2025-71439 is a heap out-of-bounds read vulnerability in llama.cpp before commit b5649. The flaw exists in the function llama_vocab::impl::print_info(), where supplying a crafted GGUF model with an undersized tokenizer.ggml.tokens array and oversized special token IDs can cause the software to read beyond allocated memory and crash during model loading. This affects llama-cli and llama-server components.
llama.cpp before b3701 contains an out-of-bounds read vulnerability in llama_decode_internal and llama_encode_internal that allows remote unauthenticated attackers to read memory by supplying unvalidated token IDs. Attackers can send integer-array prompts to the llama-server /completion endpoint with IDs outside 0 to n_vocab to read embedding memory out of bounds or crash the process.
An out-of-bounds read vulnerability exists in llama.cpp versions from b1046 up to but not including b2731. The flaw occurs in the llama_model_loader component when processing crafted GGUF model files with arbitrary 64-bit tensor offsets. This can cause the process to crash or read adjacent memory as model weights.
YesWiki versions prior to 4.7.0 have a stored cross-site scripting (XSS) vulnerability in the handlers/page/referrers_sites.php component. This flaw allows unauthenticated attackers to inject malicious scripts via specially crafted Referer headers. When a victim visits the referrer-sites page, the injected JavaScript executes in their browser context, enabling same-origin authenticated actions.
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. Specifically, the method does not validate the Date header nor track previously seen signatures. This allows an attacker who captures 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 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.