CWE-87
AllowedImproper Neutralization of Alternate XSS Syntax
Abstraction: Variant · Status: Draft
The product does not neutralize or incorrectly neutralizes user-controlled input for alternate script syntax.
98 vulnerabilities reference this CWE, most recent first.
GHSA-P3XJ-62JC-GR96
Vulnerability from github – Published: 2022-11-04 19:01 – Updated: 2022-11-08 19:00A vulnerability in the web-based management interface of Cisco Identity Services Engine (ISE) could allow an authenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the web-based management interface of an affected device. This vulnerability is due to insufficient validation of user-supplied input by the web-based management interface of an affected device. An attacker could exploit this vulnerability by injecting malicious code into specific pages of the interface. A successful exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or access sensitive, browser-based information. To exploit this vulnerability, the attacker would need valid credentials to access the web-based management interface of an affected device.
{
"affected": [],
"aliases": [
"CVE-2022-20963"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-87"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-04T18:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web-based management interface of Cisco Identity Services Engine (ISE) could allow an authenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the web-based management interface of an affected device. This vulnerability is due to insufficient validation of user-supplied input by the web-based management interface of an affected device. An attacker could exploit this vulnerability by injecting malicious code into specific pages of the interface. A successful exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or access sensitive, browser-based information. To exploit this vulnerability, the attacker would need valid credentials to access the web-based management interface of an affected device.",
"id": "GHSA-p3xj-62jc-gr96",
"modified": "2022-11-08T19:00:23Z",
"published": "2022-11-04T19:01:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20963"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ise-stor-xss-kpRBWXY"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ise-stor-xss-kpRBWXY"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-R8XC-XXH3-Q5X3
Vulnerability from github – Published: 2023-06-22 19:59 – Updated: 2023-06-30 20:27Impact
Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the resubmit template to perform a XSS, e.g. by using URL such as:
xwiki/bin/view/XWiki/Main?xpage=resubmit&resubmit=javascript:alert(document.domain)&xback=javascript:alert(document.domain)
This vulnerability exists since XWiki 2.5-milestone-2.
Patches
The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.
Workarounds
It's possible to workaround the vulnerability by editing the template resubmit.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.
References
- Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20343
- Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583
- Commit containing the actual fix in the page: https://github.com/xwiki/xwiki-platform/commit/dbc92dcdace33823ffd1e1591617006cb5fc6a7f
For more information
If you have any questions or comments about this advisory: * Open an issue in Jira XWiki.org * Email us at Security Mailing List
Attribution
This vulnerability has been reported by René de Sain @renniepak.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-web-templates"
},
"ranges": [
{
"events": [
{
"introduced": "2.5-milestone-2"
},
{
"fixed": "14.10.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-web-templates"
},
"ranges": [
{
"events": [
{
"introduced": "15.0-rc-1"
},
{
"fixed": "15.1-rc-1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-35160"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-87"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-22T19:59:55Z",
"nvd_published_at": "2023-06-23T19:15:09Z",
"severity": "CRITICAL"
},
"details": "### Impact\nUsers are able to forge an URL with a payload allowing to inject Javascript in the page (XSS).\nIt\u0027s possible to exploit the resubmit template to perform a XSS, e.g. by using URL such as:\n\n \u003e xwiki/bin/view/XWiki/Main?xpage=resubmit\u0026resubmit=javascript:alert(document.domain)\u0026xback=javascript:alert(document.domain)\n\nThis vulnerability exists since XWiki 2.5-milestone-2.\n\n### Patches\n\nThe vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.\n\n### Workarounds\n\nIt\u0027s possible to workaround the vulnerability by editing the template resubmit.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.\n\n### References\n\n * Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20343\n * Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583\n * Commit containing the actual fix in the page: https://github.com/xwiki/xwiki-platform/commit/dbc92dcdace33823ffd1e1591617006cb5fc6a7f\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)\n\n### Attribution\n\nThis vulnerability has been reported by Ren\u00e9 de Sain @renniepak.",
"id": "GHSA-r8xc-xxh3-q5x3",
"modified": "2023-06-30T20:27:58Z",
"published": "2023-06-22T19:59:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-r8xc-xxh3-q5x3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35160"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/dbc92dcdace33823ffd1e1591617006cb5fc6a7f"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-20343"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-20583"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "XWiki Platform vulnerable to reflected cross-site scripting via back and xcontinue parameters in resubmit template"
}
GHSA-R9XJ-MVQF-JM7W
Vulnerability from github – Published: 2025-10-16 20:48 – Updated: 2025-10-16 21:54Summary
In Bagisto v2.3.7, the “Create New Customer” feature (in the admin panel) is vulnerable to reflected / stored Cross-Site Scripting (XSS). An attacker with access to the admin create-customer form can inject malicious JavaScript payloads into certain input fields. These payloads may later execute in the context of an admin’s browser or another user viewing the customer data, enabling session theft or admin-level actions.
Details
The vulnerability arises because certain input fields are not properly sanitized or escaped when rendering customer data in the admin UI. The form data is stored in the database (i.e. it is stored XSS), and later when customer records are displayed (e.g. in a grid, detail view, or listing), the input is interpolated into HTML without encoding or filtering.
PoC
Navigate to sales orders, and create a new customer.
Enter the payload
"><svg/onload=prompt(document.domain)> to the first_name and last_name.
Scripts were triggered.
Impact
Stored XSS vulnerability — malicious script persisted in database and executed when viewing the data. An attacker (with limited privilege) could inject JavaScript that runs in the browser of an admin or user who views injected customer records. The script can steal session cookies, perform actions on behalf of admin, escalate privileges, or pivot into further attacks. In an e-commerce admin system, this is high severity due to potential access to customer data, order management, or site configuration.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.3.7"
},
"package": {
"ecosystem": "Packagist",
"name": "bagisto/bagisto"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-62414"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-80",
"CWE-87"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-16T20:48:48Z",
"nvd_published_at": "2025-10-16T19:15:34Z",
"severity": "MODERATE"
},
"details": "### Summary\nIn Bagisto v2.3.7, the \u201cCreate New Customer\u201d feature (in the admin panel) is vulnerable to reflected / stored Cross-Site Scripting (XSS). An attacker with access to the admin create-customer form can inject malicious JavaScript payloads into certain input fields. These payloads may later execute in the context of an admin\u2019s browser or another user viewing the customer data, enabling session theft or admin-level actions.\n\n### Details\nThe vulnerability arises because certain input fields are not properly sanitized or escaped when rendering customer data in the admin UI. The form data is stored in the database (i.e. it is stored XSS), and later when customer records are displayed (e.g. in a grid, detail view, or listing), the input is interpolated into HTML without encoding or filtering. \n\n### PoC\nNavigate to sales orders, and create a new customer.\n\u003cimg width=\"643\" height=\"567\" alt=\"image\" src=\"https://github.com/user-attachments/assets/e3a7c5a2-f53b-4db6-ac23-3451bca58956\" /\u003e\nEnter the payload `\"\u003e\u003csvg/onload=prompt(document.domain)\u003e` to the first_name and last_name.\n\u003cimg width=\"1527\" height=\"767\" alt=\"image\" src=\"https://github.com/user-attachments/assets/86ac325e-7700-477d-a13d-be2d4885f510\" /\u003e\nScripts were triggered.\n\u003cimg width=\"1267\" height=\"321\" alt=\"image\" src=\"https://github.com/user-attachments/assets/ce673b44-13cc-4e88-a89e-03bf0bd7e244\" /\u003e\n\u003cimg width=\"1336\" height=\"404\" alt=\"image\" src=\"https://github.com/user-attachments/assets/d45913ea-b177-4926-8612-92518e12f11e\" /\u003e\n\n\n### Impact\nStored XSS vulnerability \u2014 malicious script persisted in database and executed when viewing the data. An attacker (with limited privilege) could inject JavaScript that runs in the browser of an admin or user who views injected customer records. The script can steal session cookies, perform actions on behalf of admin, escalate privileges, or pivot into further attacks. In an e-commerce admin system, this is high severity due to potential access to customer data, order management, or site configuration.",
"id": "GHSA-r9xj-mvqf-jm7w",
"modified": "2025-10-16T21:54:57Z",
"published": "2025-10-16T20:48:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bagisto/bagisto/security/advisories/GHSA-r9xj-mvqf-jm7w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62414"
},
{
"type": "PACKAGE",
"url": "https://github.com/bagisto/bagisto"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "bagisto has Cross Site Scripting (XSS) in Create New Customer"
}
GHSA-WPPQ-9H6P-CRXG
Vulnerability from github – Published: 2024-05-22 00:30 – Updated: 2024-05-22 00:30The Media Library Assistant plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the lang parameter in all versions up to, and including, 3.15 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.
{
"affected": [],
"aliases": [
"CVE-2024-3519"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-87"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-22T00:15:08Z",
"severity": "MODERATE"
},
"details": "The Media Library Assistant plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the lang parameter in all versions up to, and including, 3.15 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.",
"id": "GHSA-wppq-9h6p-crxg",
"modified": "2024-05-22T00:30:34Z",
"published": "2024-05-22T00:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3519"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=3069819%40media-library-assistant%2Ftrunk\u0026old=3060779%40media-library-assistant%2Ftrunk\u0026sfp_email=\u0026sfph_mail=#file3"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/7e1cdaf3-76fe-4b73-b30b-4554f0d34d11?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WR9H-4R83-F4V6
Vulnerability from github – Published: 2026-06-18 15:04 – Updated: 2026-06-18 15:04TL;DR
This vulnerability affects Kirby sites and plugins that use the writer or list fields or that use $dom->sanitize(), Sane::sanitize(), Sane\Html::sanitize(), Sane\Svg::sanitize(), Sane\Xml::sanitize(), Sane::sanitizeFile() or $file->sanitizeContents() with untrusted input.
It was possible to inject malicious markup as children of an unknown HTML/XML tag, which would then be passed through Dom::sanitize() without being correctly sanitized according to the provided sanitization rules, causing a cross-site scripting (XSS) risk.
This vulnerability is of high severity for affected sites.
The default file upload protection is not affected, so sites that only validate uploaded files are not exposed to this vulnerability. The vulnerability can only be exploited by authenticated users.
Introduction
Cross-site scripting (XSS) is a type of vulnerability that allows executing any kind of JavaScript code inside the site frontend or Panel session of the same or other users. In the Panel, a harmful script can, for example, trigger requests to Kirby's API with the permissions of the victim.
In a stored XSS attack, the malicious payload is saved into the content data and has the potential to affect other users or site visitors.
Such vulnerabilities are critical if you might have potential attackers in your group of authenticated Panel users. They can escalate their privileges if they get access to the Panel session of an admin user. Depending on your site, other JavaScript-powered attacks are possible.
A specific class of stored XSS is auto-firing, meaning the maliciously injected JavaScript code is executed by the browser when the page loads without the victim having to perform a specific action.
Affected components
The Dom::sanitize() method allows removing unwanted or malicious elements or attributes from DOM documents (which includes HTML, SVG or arbitrary XML data). Sanitized content is supposed to be protected against cross-site scripting (XSS) attacks by removing their impact from untrusted content input.
Dom::sanitize() internally checks all nodes and attributes of the DOM document. It removes nodes, attributes, processing instructions, doctypes and namespaces that are not allowed according to the provided configuration. Nodes with tags that have been explicitly blocklisted are removed together with their children. Nodes with explicitly allowlisted tags are kept. If a tag is neither allowlisted nor blocklisted, nodes with that tag are unwrapped by Dom::unwrap() (meaning the children are kept).
Dom::sanitize() is used in the following components:
- The
writerfield sanitizes all entered content on the backend before it is saved to the content file. - The
listfield performs the same sanitization as thewriterfield since Kirby 5.4.1 (and in backported versions since Kirby 4.9.1). - The
Kirby\Saneclass package includes higher-level classesSane\Html,Sane\SvgandSane\Xmlthat all rely on DOM sanitization. - These classes are in turn also used by
Sane::sanitizeFile()and$file->sanitizeContents(). - Any of the mentioned methods could also be used in site or plugin code, for example in a
file.create:beforehook that cleans uploaded SVG/HTML files.
Only the sanitization path (returning a cleaned document) is affected. The validation path is not affected by this vulnerability. Kirby's default upload protection performs validation, so malicious SVG or HTML uploads continue to be rejected.
Impact
In affected releases, Dom::sanitize() did not sanitize nodes that had been unwrapped from their parent node. The affected child nodes would be copied into the resulting sanitized document without being sanitized.
An authenticated Panel user who can edit a writer or list field can store markup that survives sanitization and executes as JavaScript when the content is rendered, both in the Panel and on the site frontend. This allows a lower-privileged editor to run scripts in the context of higher-privileged users (for example admins) who view the content ("stored XSS"). Where a plugin or custom code cleans uploaded SVG/HTML with the Sane API, the same flaw leaves active content in the stored file, which executes when the file is served.
Patches
The problem has been patched in Kirby 4.9.4 and Kirby 5.4.4. Please update to one of these or a later version to fix the vulnerability.
In all of the mentioned releases, Dom::unwrap() now moves the allowed children to the parent instead of cloning them, so the exact nodes remain in the document and are covered by the sanitization pass.
Note that content that was passed through the sanitizer and stored as field content before the patch may contain malicious content that was not properly sanitized due to the vulnerable code. If you cannot rule out attackers under the authenticated users of a security-critical site, we advise reviewing the content for possible attacks or to re-sanitize all content of affected fields.
Credits
Thanks to Shafiq Aiman (@shafiqaimanx) for responsibly reporting the identified issue.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.9.3"
},
"package": {
"ecosystem": "Packagist",
"name": "getkirby/cms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.9.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.4.3"
},
"package": {
"ecosystem": "Packagist",
"name": "getkirby/cms"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-alpha.1"
},
{
"fixed": "5.4.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54002"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-87"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T15:04:52Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### TL;DR\n\nThis vulnerability affects Kirby sites and plugins that use the `writer` or `list` fields or that use `$dom-\u003esanitize()`, `Sane::sanitize()`, `Sane\\Html::sanitize()`, `Sane\\Svg::sanitize()`, `Sane\\Xml::sanitize()`, `Sane::sanitizeFile()` or `$file-\u003esanitizeContents()` with untrusted input.\n\nIt was possible to inject malicious markup as children of an unknown HTML/XML tag, which would then be passed through `Dom::sanitize()` without being correctly sanitized according to the provided sanitization rules, causing a cross-site scripting (XSS) risk.\n\n**This vulnerability is of high severity for affected sites.**\n\nThe default file upload protection is *not* affected, so sites that only *validate* uploaded files are not exposed to this vulnerability. The vulnerability can only be exploited by authenticated users.\n\n----\n\n### Introduction\n\nCross-site scripting (XSS) is a type of vulnerability that allows executing any kind of JavaScript code inside the site frontend or Panel session of the same or other users. In the Panel, a harmful script can, for example, trigger requests to Kirby\u0027s API with the permissions of the victim.\n\nIn a *stored* XSS attack, the malicious payload is saved into the content data and has the potential to affect other users or site visitors.\n\nSuch vulnerabilities are critical if you might have potential attackers in your group of authenticated Panel users. They can escalate their privileges if they get access to the Panel session of an admin user. Depending on your site, other JavaScript-powered attacks are possible.\n\nA specific class of stored XSS is auto-firing, meaning the maliciously injected JavaScript code is executed by the browser when the page loads without the victim having to perform a specific action.\n\n### Affected components\n\nThe `Dom::sanitize()` method allows removing unwanted or malicious elements or attributes from DOM documents (which includes HTML, SVG or arbitrary XML data). Sanitized content is supposed to be protected against cross-site scripting (XSS) attacks by removing their impact from untrusted content input.\n\n`Dom::sanitize()` internally checks all nodes and attributes of the DOM document. It removes nodes, attributes, processing instructions, doctypes and namespaces that are not allowed according to the provided configuration. Nodes with tags that have been explicitly blocklisted are removed together with their children. Nodes with explicitly allowlisted tags are kept. If a tag is neither allowlisted nor blocklisted, nodes with that tag are unwrapped by `Dom::unwrap()` (meaning the children are kept).\n\n`Dom::sanitize()` is used in the following components:\n\n- The `writer` field sanitizes all entered content on the backend before it is saved to the content file.\n- The `list` field performs the same sanitization as the `writer` field since Kirby 5.4.1 (and in backported versions since Kirby 4.9.1).\n- The `Kirby\\Sane` class package includes higher-level classes `Sane\\Html`, `Sane\\Svg` and `Sane\\Xml` that all rely on DOM sanitization.\n- These classes are in turn also used by `Sane::sanitizeFile()` and `$file-\u003esanitizeContents()`.\n- Any of the mentioned methods could also be used in site or plugin code, for example in a `file.create:before` hook that cleans uploaded SVG/HTML files.\n\nOnly the sanitization path (returning a cleaned document) is affected. The validation path is *not* affected by this vulnerability. Kirby\u0027s default upload protection performs validation, so malicious SVG or HTML uploads continue to be rejected.\n\n### Impact\n\nIn affected releases, `Dom::sanitize()` did not sanitize nodes that had been unwrapped from their parent node. The affected child nodes would be copied into the resulting sanitized document without being sanitized.\n\nAn authenticated Panel user who can edit a `writer` or `list` field can store markup that survives sanitization and executes as JavaScript when the content is rendered, both in the Panel and on the site frontend. This allows a lower-privileged editor to run scripts in the context of higher-privileged users (for example admins) who view the content (\"stored XSS\"). Where a plugin or custom code cleans uploaded SVG/HTML with the `Sane` API, the same flaw leaves active content in the stored file, which executes when the file is served.\n\n### Patches\n\nThe problem has been patched in [Kirby 4.9.4](https://github.com/getkirby/kirby/releases/tag/4.9.4) and [Kirby 5.4.4](https://github.com/getkirby/kirby/releases/tag/5.4.4). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability.\n\nIn all of the mentioned releases, `Dom::unwrap()` now *moves* the allowed children to the parent instead of cloning them, so the exact nodes remain in the document and are covered by the sanitization pass.\n\nNote that content that was passed through the sanitizer and stored as field content before the patch may contain malicious content that was not properly sanitized due to the vulnerable code. If you cannot rule out attackers under the authenticated users of a security-critical site, we advise reviewing the content for possible attacks or to re-sanitize all content of affected fields.\n\n### Credits\n\nThanks to Shafiq Aiman (@shafiqaimanx) for responsibly reporting the identified issue.",
"id": "GHSA-wr9h-4r83-f4v6",
"modified": "2026-06-18T15:04:52Z",
"published": "2026-06-18T15:04:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getkirby/kirby/security/advisories/GHSA-wr9h-4r83-f4v6"
},
{
"type": "PACKAGE",
"url": "https://github.com/getkirby/kirby"
},
{
"type": "WEB",
"url": "https://github.com/getkirby/kirby/releases/tag/4.9.4"
},
{
"type": "WEB",
"url": "https://github.com/getkirby/kirby/releases/tag/5.4.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Kirby: Cross-site scripting (XSS) from incomplete HTML/XML sanitization in `Dom::sanitize()`"
}
GHSA-X234-MG7Q-M8G8
Vulnerability from github – Published: 2023-06-22 19:59 – Updated: 2023-06-22 19:59Impact
Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the deletespace template to perform a XSS, e.g. by using URL such as:
xwiki/bin/deletespace/Sandbox/?xredirect=javascript:alert(document.domain)
This vulnerability exists since XWiki 3.4-milestone-1.
Patches
The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.
Workarounds
It's possible to workaround the vulnerability by editing the template deletespace.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.
References
- Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20612
- Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583
- Commit containing the actual fix in the template: https://github.com/xwiki/xwiki-platform/commit/5c20ff5e3bdea50f1053fe99a27e011b8d0e4b34
For more information
If you have any questions or comments about this advisory: * Open an issue in Jira XWiki.org * Email us at Security Mailing List
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-web-templates"
},
"ranges": [
{
"events": [
{
"introduced": "3.4-milestone-1"
},
{
"fixed": "14.10.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-web-templates"
},
"ranges": [
{
"events": [
{
"introduced": "15.0-rc-1"
},
{
"fixed": "15.1-rc-1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-35159"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-87"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-22T19:59:47Z",
"nvd_published_at": "2023-06-23T19:15:09Z",
"severity": "CRITICAL"
},
"details": "### Impact\nUsers are able to forge an URL with a payload allowing to inject Javascript in the page (XSS).\nIt\u0027s possible to exploit the deletespace template to perform a XSS, e.g. by using URL such as:\n\n\u003e xwiki/bin/deletespace/Sandbox/?xredirect=javascript:alert(document.domain)\n\nThis vulnerability exists since XWiki 3.4-milestone-1.\n\n### Patches\nThe vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.\n\n### Workarounds\n\nIt\u0027s possible to workaround the vulnerability by editing the template deletespace.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.\n\n### References\n\n * Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20612\n * Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583\n * Commit containing the actual fix in the template: https://github.com/xwiki/xwiki-platform/commit/5c20ff5e3bdea50f1053fe99a27e011b8d0e4b34\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)\n",
"id": "GHSA-x234-mg7q-m8g8",
"modified": "2023-06-22T19:59:47Z",
"published": "2023-06-22T19:59:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-x234-mg7q-m8g8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35159"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/5c20ff5e3bdea50f1053fe99a27e011b8d0e4b34"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-20583"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-20612"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "XWiki Platform vulnerable to reflected cross-site scripting via xredirect parameter in deletespace template"
}
GHSA-X4H7-RF56-3V6W
Vulnerability from github – Published: 2024-01-11 09:30 – Updated: 2024-01-11 09:30The Calculated Fields Form plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 1.2.40 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.
{
"affected": [],
"aliases": [
"CVE-2023-6446"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-87"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-11T07:15:08Z",
"severity": "MODERATE"
},
"details": "The Calculated Fields Form plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 1.2.40 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.",
"id": "GHSA-x4h7-rf56-3v6w",
"modified": "2024-01-11T09:30:34Z",
"published": "2024-01-11T09:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6446"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3005354/calculated-fields-form"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c879123c-531e-43d8-a7d3-16a3c86b68a3?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-X8JV-Q8J2-487C
Vulnerability from github – Published: 2026-05-06 20:57 – Updated: 2026-05-15 23:49A reflected XSS vulnerability was found under admin panel -> System -> Import/Export -> Dataflow - Profiles.
Steps to produce
-
Login to the admin panel
-
Go to the path
System -> Import/Export -> Dataflow - Profiles -
Select profile direction as
Import. -
Click on
Import Customers -
Upload the file.
File Link: customer_20260212_204335.csv
-
Go back to
Run profile. -
Select the uploaded file and Click on
Run in Popup. -
One can see a URL like this
https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/import-20260215151125-1_customer_20260212_204335.csv/
-
One can see the filename getting reflection in HTML tags.
-
Inject an HTML tag and observe.
https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/"><h3>hacked</h3>/
-
One can see the tag is getting executed.
-
Proceed for XSS.
https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/%3CScRiPt%20%3Eprompt(document.cookie)%3C%2FScRiPt%3E
- There is an XSS popup.
Impact
Cookie stealing, JS deface, many more
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 20.17.0"
},
"package": {
"ecosystem": "Packagist",
"name": "openmage/magento-lts"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "20.18.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42458"
],
"database_specific": {
"cwe_ids": [
"CWE-87"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T20:57:37Z",
"nvd_published_at": "2026-05-15T17:16:46Z",
"severity": "MODERATE"
},
"details": "A reflected XSS vulnerability was found under admin panel -\u003e System -\u003e Import/Export -\u003e Dataflow - Profiles.\n\n## Steps to produce\n\n+ Login to the admin panel \n\n+ Go to the path `System -\u003e Import/Export -\u003e Dataflow - Profiles`\n\n+ Select profile direction as `Import`.\n\n+ Click on `Import Customers` \n\n+ Upload the file.\n\nFile Link: [customer_20260212_204335.csv](https://github.com/user-attachments/files/25629638/customer_20260212_204335.csv)\n\n+ Go back to `Run profile`.\n\n+ Select the uploaded file and Click on `Run in Popup`.\n\n+ One can see a URL like this \n\n```\nhttps://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/import-20260215151125-1_customer_20260212_204335.csv/\n```\n\n\n+ One can see the filename getting reflection in HTML tags.\n\n+ Inject an HTML tag and observe.\n\n```\nhttps://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/\"\u003e\u003ch3\u003ehacked\u003c/h3\u003e/\n``` \n\n\u003cimg width=\"1796\" height=\"302\" alt=\"image (3)\" src=\"https://github.com/user-attachments/assets/502330b0-fa73-4b90-a81f-6216a98e474a\" /\u003e\n\n+ One can see the tag is getting executed.\n\n+ Proceed for XSS.\n\n```\nhttps://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/%3CScRiPt%20%3Eprompt(document.cookie)%3C%2FScRiPt%3E\n```\n\n\u003cimg width=\"1670\" height=\"562\" alt=\"image (4)\" src=\"https://github.com/user-attachments/assets/98a75081-fa8c-4483-9078-0ab5e7e14e4d\" /\u003e\n\n\n+ There is an XSS popup.\n\n## Impact\n\nCookie stealing, JS deface, many more",
"id": "GHSA-x8jv-q8j2-487c",
"modified": "2026-05-15T23:49:07Z",
"published": "2026-05-06T20:57:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OpenMage/magento-lts/security/advisories/GHSA-x8jv-q8j2-487c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42458"
},
{
"type": "PACKAGE",
"url": "https://github.com/OpenMage/magento-lts"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Magento LTS: Reflected XSS - Import -\u003e Data Flow (profiles) "
}
Mitigation
Resolve all input to absolute or canonical representations before processing.
Mitigation
Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.
Mitigation MIT-30.1
Strategy: Output Encoding
- Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.
- The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.
Mitigation MIT-43
With Struts, write all data from form beans with the bean's filter attribute set to true.
Mitigation MIT-31
Strategy: Attack Surface Reduction
To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XmlHttpRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
CAPEC-199: XSS Using Alternate Syntax
An adversary uses alternate forms of keywords or commands that result in the same action as the primary form but which may not be caught by filters. For example, many keywords are processed in a case insensitive manner. If the site's web filtering algorithm does not convert all tags into a consistent case before the comparison with forbidden keywords it is possible to bypass filters (e.g., incomplete black lists) by using an alternate case structure. For example, the "script" tag using the alternate forms of "Script" or "ScRiPt" may bypass filters where "script" is the only form tested. Other variants using different syntax representations are also possible as well as using pollution meta-characters or entities that are eventually ignored by the rendering engine. The attack can result in the execution of otherwise prohibited functionality.