ghsa-43c9-gw4x-pcx6
Vulnerability from github
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() 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() 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 theupload_pathdirectory. -
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()orfmDelete()originates from the owner of the resource to which the attachment is linked (asks a bit more than a few lines of code).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.4.5"
},
"package": {
"ecosystem": "Packagist",
"name": "yeswiki/yeswiki"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-24019"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-21T20:11:37Z",
"nvd_published_at": "2025-01-21T18:15:17Z",
"severity": "HIGH"
},
"details": "# Authenticated arbitrary file deletion in YesWiki \u003c= 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\u0027s 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[\u0027do\u0027]) \u0026\u0026 $_GET[\u0027do\u0027]) ? $_GET[\u0027do\u0027] : \u0027\u0027;\n switch ($do) {\n case \u0027restore\u0027:\n $this-\u003efmRestore();\n $this-\u003efmShow(true, $isAction);\n break;\n case \u0027erase\u0027:\n $this-\u003efmErase();\n $this-\u003efmShow(true, $isAction);\n break;\n case \u0027del\u0027:\n $this-\u003efmDelete();\n $this-\u003efmShow(false, $isAction);\n break;\n case \u0027trash\u0027:\n $this-\u003efmShow(true, $isAction);\n break;\n case \u0027emptytrash\u0027:\n $this-\u003efmEmptyTrash(); //pas de break car apres un emptytrash =\u003e retour au gestionnaire\n // no break\n default:\n $this-\u003efmShow(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\u0027t 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-\u003eGetUploadPath();\n $filename = $path . \u0027/\u0027 . ($_GET[\u0027file\u0027] ? $_GET[\u0027file\u0027] : \u0027\u0027);\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\u003e The following actions have been performed as a privileged user\n\nFirst, let\u0027s create one user (in addition to the WikiAdmin user):\n\n\n\nRestrict the edition of \u0027PagePrincipale\u0027 wiki page to administrators only:\n\n\n\n#### 2. Upload of a file on a resource not owned by our user\n\u003e The following actions have been performed as a privileged user\n\nSecond, let\u0027s upload a media to this `PagePrincipale` wiki page:\n\n\n\n\nThen view it in the page\u0027s 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\u003e 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\u0027s uploaded media:\n\n\n\nThe media is now deleted from PagePrincipale (the button is shown when the attached media doesn\u0027t exist, it\u0027s 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\u003e 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\u003e 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\u0027t 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 \u0027yeswiki\u0027 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-\u003eGetUploadPath();\n $filename = $this-\u003eGetUploadPath() . \u0027/\u0027 . basename(realpath(($_GET[\u0027file\u0027] ? $_GET[\u0027file\u0027] : \u0027\u0027))); //Sanitize file path\n if (file_exists($filename) \u0026\u0026 preg_match(\u0027/trash\\d{14}$/\u0027, $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",
"id": "GHSA-43c9-gw4x-pcx6",
"modified": "2025-01-21T20:11:37Z",
"published": "2025-01-21T20:11:37Z",
"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"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "Authenticated arbitrary file deletion in YesWiki"
}
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.