CVE-2025-24019: Yeswiki/yeswiki Authenticated Arbitrary File Deletion Vulnerability
HIGH
Advisory Identifier:
GHSA-43c9-gw4x-pcx6
Advisory Summary
CVE-2025-24019 is a HIGH (CVSS 7.1) authenticated arbitrary file deletion vulnerability (CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')) affecting Yeswiki/yeswiki libraries in the Packagist ecosystem. The issue involves authenticated arbitrary file deletion in yeswiki. Remediation is available by upgrading affected packages to version 4.5.0.
CVE-2025-24019 at a Glance
CVE Identifier
CVE-2025-24019
GHSA Identifier
GHSA-43c9-gw4x-pcx6
Severity
HIGH
CVSS v3.1 Base Score
7.1
CWE Classification
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Affected Product
Yeswiki/yeswiki
Package Ecosystem
Packagist
Published Date
Last Updated
Security Impact
CVSS: 7.1
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:N/I:L/A:H).
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
None (C:N)
Integrity
Low (I:L)
Availability
High (A:H)
How to Fix CVE-2025-24019
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/yeswikiHow to Check if You Are Affected
To determine whether your application is affected by CVE-2025-24019, inspect your project dependencies for Yeswiki/yeswiki:
inspect dependencies for yeswiki/yeswikiAnalyze 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-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), where the product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. 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 arbitrary file deletion in YesWiki <= 4.4.5
### Summary
It is possible for any authenticated user, through the use of the filemanager to delete any file owned by the user running the FastCGI Process Manager (FPM) on the host without any limitation on the filesystem's scope.
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 `filemanager` that allows a user to manage files that are attached to a resource when they have owner permission on it. This part of the code is managed in `tools/attach/libs/attach.lib.php`
```php
public function doFileManager($isAction = false)
{
$do = (isset($_GET['do']) && $_GET['do']) ? $_GET['do'] : '';
switch ($do) {
case 'restore':
$this->fmRestore();
$this->fmShow(true, $isAction);
break;
case 'erase':
$this->fmErase();
$this->fmShow(true, $isAction);
break;
case 'del':
$this->fmDelete();
$this->fmShow(false, $isAction);
break;
case 'trash':
$this->fmShow(true, $isAction);
break;
case 'emptytrash':
$this->fmEmptyTrash(); //pas de break car apres un emptytrash => retour au gestionnaire
// no break
default:
$this->fmShow(false, $isAction);
}
}
```
The **[fmErase()](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/attach/libs/attach.lib.php#L999)** function doesn't sanitize or verify the path that has been provided by the user in any way. Thus allowing a malicious user to specify any arbitrary file on the filesystem and having it deleted through the use of `unlink()` (as long as the user that runs the process has permission to delete it).
```php
public function fmErase()
{
$path = $this->GetUploadPath();
$filename = $path . '/' . ($_GET['file'] ? $_GET['file'] : '');
if (file_exists($filename)) {
unlink($filename);
}
}
```
In addition to this deletion accross all the filesystem through `fmErase()`, it is also possible to delete any file attached to an existing wiki page, for instance, if user A creates a page and attaches images/documents to it, they always get uploaded to the files/ directory. If user B (malicious), knows the path of the files he can also arbitrarly delete them. (**[fmDelete()](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/attach/libs/attach.lib.php#L1011)** is also impacted by this case)
### PoC
#### 1. Environnement setup
> The following actions have been performed as a privileged user
First, let's create one user (in addition to the WikiAdmin user):
Restrict the edition of 'PagePrincipale' wiki page to administrators only:
#### 2. Upload of a file on a resource not owned by our user
> The following actions have been performed as a privileged user
Second, let's upload a media to this `PagePrincipale` wiki page:
Then view it in the page's filemanager:
We can confirm that our file has been uploaded to the `files/` directory by directly looking at the `yeswiki` container:
#### 3. Arbitrary deletion (in files/)
> The following actions have been performed using an unprivileged user
Now, get the full path/name of the media in the files directory by opening it in a new tab:
Afterwards, we need an instance of filemanager to be accessible to our user so we need to create a page that we own, here is used the agenda and the creation of a new event:
Call the `erase` method on the PagePrincipale's uploaded media:
The media is now deleted from PagePrincipale (the button is shown when the attached media doesn't exist, it's an intended behaviour):
It has also disappeared from the `files/` directory:
This behaviour can be applied to **any** file under the `files/` directory.
#### 4. Arbitrary deletion (in /tmp/)
> The following actions have been performed using a privileged access
Finally, using the same user as the process running the app, we create a file under the `/tmp` directory:
> The following actions have been performed using an unprivileged user
We can once again call the `erase` method using a relative path:
The file isn't here anymore:
### Impact
This vulnerability allows any authenticated user to arbitrarly remove content from the Wiki resulting in partial loss of data and defacement/deteroriation of the website. In the context of a container installation of YesWiki without any modification, the 'yeswiki' files (for example .php) are not owned by the same user (root) as the one running the FPM process (www-data). However in a standard installation, www-data may also be the owner of the PHP files, allowing a malicious user to completely cut the access to the wiki by deleting all important PHP files (like index.php or core files of YesWiki).
### Suggestion of possible corrective measures
- Restrict the possible paths of `fmErase()` to the `upload_path` directory.
- Restrict the use of `fmErase()` to trashed files only.
```php
public function fmErase()
{
$path = $this->GetUploadPath();
$filename = $this->GetUploadPath() . '/' . basename(realpath(($_GET['file'] ? $_GET['file'] : ''))); //Sanitize file path
if (file_exists($filename) && preg_match('/trash\d{14}$/', $filename)) { //Make sure that the filename ends with trash and a date
unlink($filename);
}
}
```
- Make sure that any request to `fmErase()` or `fmDelete()` originates from the owner of the resource to which the attachment is linked (asks a bit more than a few lines of code).
CVE-2025-24019 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
GitHub Advisory / Wiki
ADVISORY
https://github.com/YesWiki/yeswiki/security/advisories/GHSA-43c9-gw4x-pcx6
NVD — CVE-2025-24019
NVD
https://nvd.nist.gov/vuln/detail/CVE-2025-24019
Security Fix Commit
FIX COMMIT
https://github.com/YesWiki/yeswiki/commit/3ddd833d22703caf9025659eb174f7765df7147c
Yeswiki/yeswiki Source Repository
REPOSITORY
https://github.com/YesWiki/yeswiki
Frequently Asked Questions
What is CVE-2025-24019?
CVE-2025-24019 is a security vulnerability in Yeswiki/yeswiki involving Authenticated arbitrary file deletion in YesWiki under CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').
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-24019?
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-24019?
CVE-2025-24019 has a CVSS v3.1 base score of 7.1 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H.
What CWE is associated with CVE-2025-24019?
CVE-2025-24019 is classified under CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.).
How can I check Packagist dependencies for CVE-2025-24019?
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-43c9-gw4x-pcx6",
"modified" : "2025-01-21T20:11:37Z",
"published" : "2025-01-21T20:11:37Z",
"aliases" : [ "CVE-2025-24019" ],
"summary" : "Authenticated arbitrary file deletion in YesWiki",
"details" : "# Authenticated arbitrary file deletion in YesWiki <= 4.4.5\n\n### Summary\nIt is possible for any authenticated user, through the use of the filemanager to delete any file owned by the user running the FastCGI Process Manager (FPM) on the host without any limitation on the filesystem's scope.\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 `filemanager` that allows a user to manage files that are attached to a resource when they have owner permission on it. This part of the code is managed in `tools/attach/libs/attach.lib.php`\n\n```php\npublic function doFileManager($isAction = false)\n{\n $do = (isset($_GET['do']) && $_GET['do']) ? $_GET['do'] : '';\n switch ($do) {\n case 'restore':\n $this->fmRestore();\n $this->fmShow(true, $isAction);\n break;\n case 'erase':\n $this->fmErase();\n $this->fmShow(true, $isAction);\n break;\n case 'del':\n $this->fmDelete();\n $this->fmShow(false, $isAction);\n break;\n case 'trash':\n $this->fmShow(true, $isAction);\n break;\n case 'emptytrash':\n $this->fmEmptyTrash(); //pas de break car apres un emptytrash => retour au gestionnaire\n // no break\n default:\n $this->fmShow(false, $isAction);\n }\n}\n```\n\nThe **[fmErase()](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/attach/libs/attach.lib.php#L999)** function doesn't sanitize or verify the path that has been provided by the user in any way. Thus allowing a malicious user to specify any arbitrary file on the filesystem and having it deleted through the use of `unlink()` (as long as the user that runs the process has permission to delete it).\n\n```php\npublic function fmErase()\n{\n $path = $this->GetUploadPath();\n $filename = $path . '/' . ($_GET['file'] ? $_GET['file'] : '');\n if (file_exists($filename)) {\n unlink($filename);\n }\n}\n```\n\nIn addition to this deletion accross all the filesystem through `fmErase()`, it is also possible to delete any file attached to an existing wiki page, for instance, if user A creates a page and attaches images/documents to it, they always get uploaded to the files/ directory. If user B (malicious), knows the path of the files he can also arbitrarly delete them. (**[fmDelete()](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/attach/libs/attach.lib.php#L1011)** is also impacted by this case)\n\n### PoC\n#### 1. Environnement setup\n> The following actions have been performed as a privileged user\n\nFirst, let's create one user (in addition to the WikiAdmin user):\n\n\n\nRestrict the edition of 'PagePrincipale' wiki page to administrators only:\n\n\n\n#### 2. Upload of a file on a resource not owned by our user\n> The following actions have been performed as a privileged user\n\nSecond, let's upload a media to this `PagePrincipale` wiki page:\n\n\n\n\nThen view it in the page's filemanager:\n\n\n\nWe can confirm that our file has been uploaded to the `files/` directory by directly looking at the `yeswiki` container:\n\n\n\n#### 3. Arbitrary deletion (in files/)\n> The following actions have been performed using an unprivileged user\n\nNow, get the full path/name of the media in the files directory by opening it in a new tab:\n\n\n\nAfterwards, we need an instance of filemanager to be accessible to our user so we need to create a page that we own, here is used the agenda and the creation of a new event:\n\n\n\nCall the `erase` method on the PagePrincipale's uploaded media:\n\n\n\nThe media is now deleted from PagePrincipale (the button is shown when the attached media doesn't exist, it's an intended behaviour):\n\n\n\nIt has also disappeared from the `files/` directory:\n\n\n\nThis behaviour can be applied to **any** file under the `files/` directory.\n\n#### 4. Arbitrary deletion (in /tmp/)\n> The following actions have been performed using a privileged access\n\nFinally, using the same user as the process running the app, we create a file under the `/tmp` directory:\n\n\n\n> The following actions have been performed using an unprivileged user\n\nWe can once again call the `erase` method using a relative path:\n\n\n\nThe file isn't here anymore:\n\n\n\n### Impact\nThis vulnerability allows any authenticated user to arbitrarly remove content from the Wiki resulting in partial loss of data and defacement/deteroriation of the website. In the context of a container installation of YesWiki without any modification, the 'yeswiki' files (for example .php) are not owned by the same user (root) as the one running the FPM process (www-data). However in a standard installation, www-data may also be the owner of the PHP files, allowing a malicious user to completely cut the access to the wiki by deleting all important PHP files (like index.php or core files of YesWiki).\n\n### Suggestion of possible corrective measures\n\n- Restrict the possible paths of `fmErase()` to the `upload_path` directory.\n\n- Restrict the use of `fmErase()` to trashed files only.\n\n```php\npublic function fmErase()\n{\n $path = $this->GetUploadPath();\n $filename = $this->GetUploadPath() . '/' . basename(realpath(($_GET['file'] ? $_GET['file'] : ''))); //Sanitize file path\n if (file_exists($filename) && preg_match('/trash\\d{14}$/', $filename)) { //Make sure that the filename ends with trash and a date\n unlink($filename);\n }\n}\n```\n\n- Make sure that any request to `fmErase()` or `fmDelete()` originates from the owner of the resource to which the attachment is linked (asks a bit more than a few lines of code).\n\n",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H"
} ],
"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-43c9-gw4x-pcx6"
}, {
"type" : "ADVISORY",
"url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-24019"
}, {
"type" : "WEB",
"url" : "https://github.com/YesWiki/yeswiki/commit/3ddd833d22703caf9025659eb174f7765df7147c"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/YesWiki/yeswiki"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-22" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2025-01-21T20:11:37Z",
"nvd_published_at" : "2025-01-21T18:15:17Z"
}
}