YesWiki versions prior to 4.5.3 contain multiple reflected cross-site scripting (XSS) vulnerabilities. These flaws allow remote attackers to inject malicious JavaScript code via unsanitized parameters such as incomingurl, id, file, tags, and template. Exploitation can occur when users, authenticated or not, open crafted links, potentially leading to session hijacking and unauthorized authenticated requests. The vulnerabilities have a medium severity rating with a CVSS score of 6.1.
YesWiki versions prior to 4.6.7 have a server-side request forgery (SSRF) vulnerability. This flaw allows unauthenticated attackers to send signed Follow activities to a public actor inbox route, causing the server to make unauthorized internal requests. Attackers can use their own keyId to sign these requests while specifying internal actor URLs, potentially accessing internal hosts or cloud metadata services. The vulnerability has a high severity rating with a CVSS score of 7. No explicit patch information is provided in the input data.
YesWiki versions before 4.6.7 have a session fixation vulnerability where the login process does not regenerate the PHP session ID. This flaw allows attackers who can set or obtain a victim's pre-authentication session cookie to hijack the victim's authenticated session and access private content with their privileges.
YesWiki versions before 4.6.7 have an unrestricted file upload vulnerability that allows authenticated administrators to upload and execute remote PHP files via the CSV import preview feature. This occurs because the application does not properly validate file extensions when importing CSV files referencing remote .php URLs, leading to server-side code execution.
YesWiki versions prior to 4.6.7 contain a server-side request forgery (SSRF) vulnerability. This flaw allows unauthenticated attackers to make server-side GET requests by providing an unvalidated actor URL to the Bazar abonnements sync action. Exploitation can target internal hosts or cloud metadata endpoints, with attacker-controlled outbox links enabling response data to be stored as readable Bazar entries. The vulnerability has a high severity rating with a CVSS score of 8.6.
YesWiki versions before 4.6.7 contain a stored cross-site scripting (XSS) vulnerability in the formatters/wakka.php component. This flaw allows users with permissions to edit pages or post comments to inject malicious event handlers via crafted markdown image URLs. The vulnerability enables attackers to execute arbitrary JavaScript in the browsers of users who view the affected pages, including administrators.
YesWiki versions before 4.6.7 have a reflected cross-site scripting (XSS) vulnerability in the mail handler's field parameter. This flaw allows unauthenticated attackers to inject malicious scripts by crafting links that manipulate the ajax-mail-form action attribute, potentially executing JavaScript in the browsers of users who click these links.
YesWiki versions prior to 4.6.7 have a missing authorization vulnerability in the attachment download handler. This flaw allows unauthenticated attackers to bypass page read access controls and download confidential attachments from pages that are supposed to be restricted. The vulnerability is identified as CVE-2026-104472 and has a high severity rating with a CVSS score of 7.5.
YesWiki versions before 4.6.7 have an SQL injection vulnerability in the Bazar nuagetag action. This flaw allows attackers with page-write access, which is unauthenticated on default installs, to inject SQL code by exploiting unescaped input in the tags attribute. The vulnerability can be used to exfiltrate password hashes and arbitrary table data. The vulnerability has a high severity score of 7.5 CVSS 3.1.
YesWiki versions before 4.6.7 have a blind SQL injection vulnerability in the {{newtextsearch}} action. This occurs because Bazar list option IDs are concatenated into SQL REGEXP/LIKE clauses without proper escaping. An anonymous attacker can exploit this by planting a malicious option ID in an anonymously editable Bazar list and use search requests to read arbitrary database data, including admin password hashes.
YesWiki versions prior to 4.6.7 have a cross-site request forgery (CSRF) vulnerability in the filemanager page handler. This flaw allows attackers to delete page attachments via crafted GET requests without CSRF token validation. The vulnerability affects logged-in users with page ownership or administrative privileges, enabling attackers to trigger deletion or permanent purging of attachments by inducing navigation with specific parameters.
YesWiki versions prior to 4.6.7 have a cross-site request forgery (CSRF) vulnerability in the ajaxdeletepage handler. This flaw allows an attacker to trick a logged-in administrator or page owner into sending a crafted GET request with a jsonp_callback parameter, which deletes arbitrary pages permanently without verifying a CSRF token. The deletion affects pages along with their associated access control lists, links, triples, comments, and referrers.
YesWiki versions before 4.6.7 have a stored cross-site scripting (XSS) vulnerability in the Bazar FileField. This vulnerability arises because the system only validates the file extension of uploads and does not sanitize SVG files using HtmlPurifierService::cleanFile. As a result, malicious SVG files containing scripts can be stored and served inline, allowing authenticated users to execute scripts in the context of the wiki origin. This can lead to compromise of administrator sessions or accounts.
YesWiki versions prior to 4.6.7 contain an SQL injection vulnerability in the Bazar filtertags action. This flaw allows unauthenticated attackers to inject SQL code by exploiting improper handling of filterN attribute tokens, potentially exposing sensitive data such as password hashes. The vulnerability arises from unescaped tokens concatenated into a raw SQL IN clause, enabling a UNION-based SQL injection attack. The vulnerability has a high severity rating with a CVSS score of 8.6.
YesWiki versions before 4.6.7 contain a server-side request forgery (SSRF) vulnerability in the validateKeyIdUrl() function. This flaw allows unauthenticated attackers to bypass SSRF protections by exploiting 6to4, NAT64, or IPv4-compatible IPv6 addresses. By sending a crafted Signature keyId to the public actor inbox route, attackers can potentially access cloud metadata services, loopback interfaces, or internal network hosts.
YesWiki versions prior to 4.6.7 have an access control vulnerability that allows unauthenticated attackers to overwrite any existing wiki page, including those with restricted write access controls. This occurs via the Bazar entry-creation flow by submitting a crafted entry with an attacker-controlled id_fiche matching an existing page, enabling mass defacement or content destruction.
YesWiki versions prior to 4.6.7 have a denial of service vulnerability caused by an inefficient O(n^2) regular expression in the wakka.php markdown-link formatter. This flaw allows unauthenticated attackers to submit crafted bracket characters to the page-edit preview endpoint, which can exhaust PHP-FPM worker processes and cause service disruption.
YesWiki versions prior to 4.6.7 contain a second-order SQL injection vulnerability in the AclService::updateRequestWithACL function. This vulnerability arises because a stored username is concatenated without proper escaping into a read-ACL LIKE clause. An attacker can exploit this by self-registering an account with a specially crafted username containing a double-quote payload, enabling them to bypass read ACLs and access restricted database contents.
YesWiki versions prior to 4.6.7 have a missing authorization vulnerability in the pointimage action, allowing unauthenticated attackers to bypass write access controls. This flaw enables attackers to append arbitrary HTML or JavaScript to any wiki page that renders the {{pointimage}} macro, resulting in stored cross-site scripting (XSS) affecting viewers and administrators.
YesWiki versions prior to 4.6.7 contain a server-side request forgery (SSRF) vulnerability in the WebfingerService. This flaw allows unauthenticated attackers to send crafted HTTPS requests to internal hosts by posting a specially crafted actor_handle with numeric host and port values to the abonnements view. The vulnerability can be used to probe internal HTTPS services and ports.