CVE-2025-24019

YesWiki is a wiki system written in PHP. In versions up to and including 4.4.5, 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 vulnerability allows any authenticated user to arbitrarily remove content from the Wiki resulting in partial loss of data and defacement/deterioration 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). Version 4.5.0 contains a patch for this issue.

YesWiki is a wiki system written in PHP. In versions up to and including 4.4.5, 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 vulnerability allows any authenticated user to arbitrarily remove content from the Wiki resulting in partial loss of data and defacement/deterioration 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). Version 4.5.0 contains a patch for this issue.

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

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).

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…

YesWiki is a wiki system written in PHP. In versions up to and including 4.4.5, 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 vulnerability allows any authenticated user to arbitrarily remove content from the Wiki resulting in partial loss of data and defacement/deterioration 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). Version 4.5.0 contains a patch for this issue.

YesWiki is a wiki system written in PHP. In versions up to and including 4.4.5, 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 vulnerability allows any authenticated user to arbitrarily remove content from the Wiki resulting in partial loss of data and defacement/deterioration 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). Version 4.5.0 contains a patch for this issue.

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

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).

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…