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.
1010 vulnerabilities reference this CWE, most recent first.
GHSA-WW33-JPPQ-QFRP
Vulnerability from github – Published: 2025-01-02 22:43 – Updated: 2025-08-14 19:34Summary
Due to insufficient validation on the content of new FAQ posts, it is possible for authenticated users to inject malicious HTML or JavaScript code that can impact other users viewing the FAQ. This vulnerability arises when user-provided inputs in FAQ entries are not sanitized or escaped before being rendered on the page.
Details
An attacker can inject malicious HTML content into the FAQ editor at http://localhost/admin/index.php?action=editentry, resulting in a complete disruption of the FAQ page's user interface. By injecting malformed HTML elements styled to cover the entire screen, an attacker can render the page unusable. This injection manipulates the page structure by introducing overlapping buttons, images, and iframes, breaking the intended layout and functionality.
PoC
- In the source code of a FAQ Q&A post, insert the likes of this snippet:
<p><--`<img src="`"> --!></p>
<div style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"><form><button>HTML INJECTION 1<img> <img> <img> <img> <iframe></iframe></button>
<div style="xg-p: absolute; top: 0; left: 0; width: 100%; height: 100%;">x</div>
<button>HTML INJECTION 2<iframe></iframe> <iframe></iframe> </button></form></div>
2. A normal user would see the broken FAQ page, or otherwise manipulated by the attacker to present a different malicious page:
A demo (fresh install overwrites every 24hours) here: https://roy.demo.phpmyfaq.de/content/1/24/en/24.html?
Impact
Exploiting this issue can lead to Denial of Service for legitimate users, damage to the user experience, and potential abuse in phishing or defacement attacks.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "phpmyfaq/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "3.2.10"
},
{
"last_affected": "4.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "thorsten/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "3.2.10"
},
{
"last_affected": "4.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-56199"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-80"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-02T22:43:40Z",
"nvd_published_at": "2025-01-02T18:15:20Z",
"severity": "MODERATE"
},
"details": "### Summary\nDue to insufficient validation on the content of new FAQ posts, it is possible for authenticated users to inject malicious HTML or JavaScript code that can impact other users viewing the FAQ. This vulnerability arises when user-provided inputs in FAQ entries are not sanitized or escaped before being rendered on the page.\n\n### Details\nAn attacker can inject malicious HTML content into the FAQ editor at http://localhost/admin/index.php?action=editentry, resulting in a complete disruption of the FAQ page\u0027s user interface. By injecting malformed HTML elements styled to cover the entire screen, an attacker can render the page unusable. This injection manipulates the page structure by introducing overlapping buttons, images, and iframes, breaking the intended layout and functionality. \n\n### PoC\n\n1. In the source code of a FAQ Q\u0026A post, insert the likes of this snippet:\n```\n\u003cp\u003e\u0026lt;--`\u003cimg src=\"\u0026#96;\"\u003e --!\u0026gt;\u003c/p\u003e\n\u003cdiv style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%;\"\u003e\u003cform\u003e\u003cbutton\u003eHTML INJECTION 1\u003cimg\u003e \u003cimg\u003e \u003cimg\u003e \u003cimg\u003e \u003ciframe\u003e\u003c/iframe\u003e\u003c/button\u003e\n\u003cdiv style=\"xg-p: absolute; top: 0; left: 0; width: 100%; height: 100%;\"\u003ex\u003c/div\u003e\n\u003cbutton\u003eHTML INJECTION 2\u003ciframe\u003e\u003c/iframe\u003e \u003ciframe\u003e\u003c/iframe\u003e \u003c/button\u003e\u003c/form\u003e\u003c/div\u003e\n```\n\n\n2. A normal user would see the broken FAQ page, or otherwise manipulated by the attacker to present a different malicious page:\n\n \nA demo (fresh install overwrites every 24hours) here: https://roy.demo.phpmyfaq.de/content/1/24/en/24.html?\n\n### Impact\nExploiting this issue can lead to Denial of Service for legitimate users, damage to the user experience, and potential abuse in phishing or defacement attacks.",
"id": "GHSA-ww33-jppq-qfrp",
"modified": "2025-08-14T19:34:18Z",
"published": "2025-01-02T22:43:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-ww33-jppq-qfrp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56199"
},
{
"type": "PACKAGE",
"url": "https://github.com/thorsten/phpMyFAQ"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "phpMyFAQ Vulnerable to Stored HTML Injection at FAQ"
}
GHSA-WW6P-Q26W-FR6M
Vulnerability from github – Published: 2024-05-20 17:14 – Updated: 2024-05-20 17:14Versions preceding 0.6.1 of the phpxmlrpc/extras project are susceptible to a Cross-Site Scripting (XSS) vulnerability. This vulnerability exists within the class documenting_xmlrpc_server when processing the GET methodName parameter.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "phpxmlrpc/extras"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-80"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-20T17:14:55Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Versions preceding 0.6.1 of the phpxmlrpc/extras project are susceptible to a Cross-Site Scripting (XSS) vulnerability. This vulnerability exists within the class documenting_xmlrpc_server when processing the GET methodName parameter.",
"id": "GHSA-ww6p-q26w-fr6m",
"modified": "2024-05-20T17:14:55Z",
"published": "2024-05-20T17:14:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gggeek/phpxmlrpc-extras/commit/65c336e3def9ce71b3e799104d3a6ad15668ddb0"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/phpxmlrpc/extras/2017-10-29.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/gggeek/phpxmlrpc-extras"
},
{
"type": "WEB",
"url": "https://github.com/gggeek/phpxmlrpc-extras/releases/tag/0.6.1"
}
],
"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": "phpxmlrpc/extra XSS in class documenting_xmlrpc_server"
}
GHSA-WX4M-69M9-GX3M
Vulnerability from github – Published: 2026-09-22 20:40 – Updated: 2026-09-22 20:40Summary
An authenticated party can add a malicious name to any statistics-capable entity, allowing for Cross-Site Scripting attacks against anyone who views a Statistics Graph card containing that entity, when they hover over any data point on the chart.
Payload
Payload triggering
An alternative, and more impactful scenario, is that the entity gets a malicious name from the provider of the integration (e.g. Tibber, Shelly, or any HACS integration), and is exploited that way through the default name — without requiring any direct access to the Home Assistant instance. This is the same supply-chain vector as CVE-2025-62172.
Details
The Statistics Graph card renders entity names in ECharts tooltips as raw HTML. The offending
line is in src/components/chart/statistics-chart.ts:
https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/components/chart/statistics-chart.ts#L236
Where param.seriesName is interpolated verbatim into the returned HTML string:
return `${time}${param.marker} ${param.seriesName}: ${value}`;
No call to filterXSS() is made — unlike the Energy dashboard chart, which was patched as part
of CVE-2025-62172:
// FIXED in energy-chart-options.ts:268
return `${param.marker} ${filterXSS(param.seriesName!)}: ...`;
The statistics-chart component was not updated when the Energy chart was patched, leaving the
same class of vulnerability in place.
The existing entity and payload used for CVE-2025-62172 is also a valid exploit for this vulnerability:
The name value flows through the following chain:
-
nameis set fromgetStatisticLabel(this.hass, statistic_id, meta): https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/components/chart/statistics-chart.ts#L411 -
getStatisticLabelis defined here and callscomputeStateName(entity): https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/data/recorder.ts#L329-L339 -
computeStateNameis defined here — no HTML encoding is applied: https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/common/entity/compute_state_name.ts
The only transformation applied to the name is replacing underscores with spaces
(computeObjectId(entityId).replace(/_/g, " ")), which does not prevent HTML injection.
NB: Do note that only the fields Mean, State, Sum and Change are vulnerable. The top 3 (Min, Max, Mean) or the bottom 3 (State, Sum, Change) are selected by default though, making it vulnerable by default:
Another requirement is that the Chart Type is of type Line, not Bar, which is also the default:
PoC
-
In Settings → Devices & Services → Helpers, click + Create Helper. (For testing)
-
Choose Template → Template sensor. Fill in the form:
- Name:
test <img src=x onerror=alert(document.domain) /> - State template:
{{0.00000001*as_timestamp(states('sensor.date_time_iso'))}} - Unit of measurement:
kWh - State class:
Measurement - Click Submit.
- Open a dashboard and add a Statistics Graph card targeting the new sensor:
NB: Set time-window to 5 minutes for ease of testing so you see data quickly
-
Hover over any data point on the chart.
-
The
onerrorhandler fires —alert(document.domain)executes in the browser or HTML-injection appears depending on the payload
** Exact helper as described here**
Own sensor
Own sensor 2
Impact
The vulnerability can be exploited remotely via the supply-chain vector: any integration that automatically names entities (e.g. energy providers like Tibber) could deliver the payload without requiring the attacker to have any account on the target Home Assistant instance. This mirrors the exact attack path described in CVE-2025-62172. The most likely exploit is also through energy providers due to them providing multiple entities compatible with statistic graphs.
Compared to CVE-2025-62172, this has the requirement that you add a Statistics Graph to your dashboard (or somehow view the entity in a Statistics Graph through other means, if such a method exists). Otherwise the attack flow is identical. Suggested CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
The root cause — missing filterXSS() on param.seriesName — is identical to the already-fixed
Energy dashboard. The Statistics Graph card, which uses a shared statistics-chart component,
was not included in the previous fix scope.
Credit: Robin Lunde - https://robinlunde.com
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "homeassistant"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-91130"
],
"database_specific": {
"cwe_ids": [
"CWE-80"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T20:40:55Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\nAn authenticated party can add a malicious name to any statistics-capable entity, allowing for\nCross-Site Scripting attacks against anyone who views a Statistics Graph card containing that\nentity, when they hover over any data point on the chart.\n\n**Payload**\n\u003cimg width=\"1529\" height=\"441\" alt=\"image\" src=\"https://github.com/user-attachments/assets/6926ce53-75fb-455a-bd4e-0c5281e8bed8\" /\u003e\n\n**Payload triggering**\n\u003cimg width=\"835\" height=\"469\" alt=\"image\" src=\"https://github.com/user-attachments/assets/0bb9d17a-c123-4d44-8471-35097f65ddd2\" /\u003e\n\nAn alternative, and more impactful scenario, is that the entity gets a malicious name from the\nprovider of the integration (e.g. Tibber, Shelly, or any HACS integration), and is exploited\nthat way through the default name \u2014 without requiring any direct access to the Home Assistant\ninstance. This is the same supply-chain vector as CVE-2025-62172.\n\n\n### Details\n\nThe Statistics Graph card renders entity names in ECharts tooltips as raw HTML. The offending\nline is in `src/components/chart/statistics-chart.ts`:\n\nhttps://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/components/chart/statistics-chart.ts#L236\n\nWhere **_`param.seriesName`_** is interpolated verbatim into the returned HTML string:\n\n```\nreturn `${time}${param.marker} ${param.seriesName}: ${value}`;\n```\n\nNo call to `filterXSS()` is made \u2014 unlike the Energy dashboard chart, which was patched as part\nof CVE-2025-62172:\n\n```\n// FIXED in energy-chart-options.ts:268\nreturn `${param.marker} ${filterXSS(param.seriesName!)}: ...`;\n```\n\nThe `statistics-chart` component was not updated when the Energy chart was patched, leaving the\nsame class of vulnerability in place.\n\nThe existing entity and payload used for CVE-2025-62172 is also a valid exploit for this vulnerability:\n\u003cimg width=\"962\" height=\"500\" alt=\"image\" src=\"https://github.com/user-attachments/assets/35c84dcd-64d4-47b6-8df2-6c8b63cac880\" /\u003e\n\n\nThe name value flows through the following chain:\n\n1. `name` is set from `getStatisticLabel(this.hass, statistic_id, meta)`:\n https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/components/chart/statistics-chart.ts#L411\n\n2. `getStatisticLabel` is defined here and calls `computeStateName(entity)`:\n https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/data/recorder.ts#L329-L339\n\n3. `computeStateName` is defined here \u2014 no HTML encoding is applied:\n https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/common/entity/compute_state_name.ts\n\nThe only transformation applied to the name is replacing underscores with spaces\n(`computeObjectId(entityId).replace(/_/g, \" \")`), which does not prevent HTML injection.\n\n\n**NB:** Do note that only the fields `Mean, State, Sum and Change` are vulnerable. The top 3 (Min, Max, Mean) or the bottom 3 (State, Sum, Change) are selected by default though, making it vulnerable by default:\n\u003cimg width=\"105\" height=\"216\" alt=\"image\" src=\"https://github.com/user-attachments/assets/7a784c90-cca5-46da-bcb9-6942ad81da0c\" /\u003e\n\nAnother requirement is that the Chart Type is of type Line, not Bar, which is also the default:\n\u003cimg width=\"133\" height=\"91\" alt=\"image\" src=\"https://github.com/user-attachments/assets/4f131495-9000-4a80-808b-bf4be9f7a2f6\" /\u003e\n\n\n\n---\n\n### PoC\n\n1. In **Settings \u2192 Devices \u0026 Services \u2192 Helpers**, click **+ Create Helper**. (For testing)\n\n2. Choose **Template** \u2192 **Template sensor**. Fill in the form:\n - **Name:** `test \u003cimg src=x onerror=alert(document.domain) /\u003e`\n - **State template:** `{{0.00000001*as_timestamp(states(\u0027sensor.date_time_iso\u0027))}}`\n - **Unit of measurement:** `kWh`\n - **State class:** `Measurement`\n - Click **Submit**.\n\n\u003cimg width=\"392\" height=\"741\" alt=\"image\" src=\"https://github.com/user-attachments/assets/6a9b2c65-93fb-4d20-89b8-5a1f47a2bcb0\" /\u003e\n\n\n3. Open a dashboard and add a **Statistics Graph** card targeting the new sensor:\n\n\n\u003cimg width=\"694\" height=\"720\" alt=\"image\" src=\"https://github.com/user-attachments/assets/83996d12-d5ba-467a-9ca1-cbc46246ddff\" /\u003e\n\n**NB:** Set time-window to 5 minutes for ease of testing so you see data quickly\n\n\n4. Hover over any data point on the chart.\n\n\n\n\n5. The `onerror` handler fires \u2014 `alert(document.domain)` executes in the browser or HTML-injection appears depending on the payload\n\n\n** Exact helper as described here**\n\u003cimg width=\"802\" height=\"441\" alt=\"image\" src=\"https://github.com/user-attachments/assets/09284c10-bc39-410a-aff0-307e0bfd0502\" /\u003e\n\n**Own sensor**\n\u003cimg width=\"962\" height=\"500\" alt=\"image\" src=\"https://github.com/user-attachments/assets/35c84dcd-64d4-47b6-8df2-6c8b63cac880\" /\u003e\n\n**Own sensor 2**\n\u003cimg width=\"835\" height=\"469\" alt=\"image\" src=\"https://github.com/user-attachments/assets/0bb9d17a-c123-4d44-8471-35097f65ddd2\" /\u003e\n---\n\n### Impact\n\nThe vulnerability can be exploited remotely via the supply-chain vector: any integration that\nautomatically names entities (e.g. energy providers like Tibber) could deliver the payload\nwithout requiring the attacker to have any account on the target Home Assistant instance. This\nmirrors the exact attack path described in CVE-2025-62172. The most likely exploit is also through energy providers due to them providing multiple entities compatible with statistic graphs.\n\nCompared to CVE-2025-62172, this has the requirement that you add a Statistics Graph to your dashboard (or somehow view the entity in a Statistics Graph through other means, if such a method exists). Otherwise the attack flow is identical.\nSuggested CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H\n\nThe root cause \u2014 missing `filterXSS()` on `param.seriesName` \u2014 is identical to the already-fixed\nEnergy dashboard. The Statistics Graph card, which uses a shared `statistics-chart` component,\nwas not included in the previous fix scope.\n\nCredit: Robin Lunde - [https://robinlunde.com](https://robinlunde.com)",
"id": "GHSA-wx4m-69m9-gx3m",
"modified": "2026-09-22T20:40:55Z",
"published": "2026-09-22T20:40:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/home-assistant/core/security/advisories/GHSA-wx4m-69m9-gx3m"
},
{
"type": "WEB",
"url": "https://github.com/home-assistant/frontend/pull/52235"
},
{
"type": "WEB",
"url": "https://github.com/home-assistant/frontend/commit/b8c201b6d34414d30c622797366570185c219614"
},
{
"type": "PACKAGE",
"url": "https://github.com/home-assistant/core"
},
{
"type": "WEB",
"url": "https://github.com/home-assistant/core/releases/tag/2026.7.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Home Assistant: XSS in Statistics Graph Card"
}
GHSA-WXR4-VF8W-QXX9
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-08-06 00:00A vulnerability in the web-based interface of Cisco Webex Meetings could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the web-based interface of the affected service. The vulnerability is due to insufficient validation of user-supplied input by the web-based interface of the affected service. An attacker could exploit this vulnerability by persuading a user of the interface to click a maliciously crafted link. 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.
{
"affected": [],
"aliases": [
"CVE-2021-1351"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-80"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-17T17:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web-based interface of Cisco Webex Meetings could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the web-based interface of the affected service. The vulnerability is due to insufficient validation of user-supplied input by the web-based interface of the affected service. An attacker could exploit this vulnerability by persuading a user of the interface to click a maliciously crafted link. 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.",
"id": "GHSA-wxr4-vf8w-qxx9",
"modified": "2022-08-06T00:00:39Z",
"published": "2022-05-24T17:42:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1351"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-webex-xss-Lz6HbGCt"
}
],
"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-X22V-J859-94XP
Vulnerability from github – Published: 2025-11-14 18:31 – Updated: 2025-11-14 21:30A Reflected Cross Site Scripting (XSS) vulnerability was found in the Application Server of Desktop Alert PingAlert version 6.1.0.11 to 6.1.1.2 which allows an attacker to hijack user’s browser, capturing sensitive information.
{
"affected": [],
"aliases": [
"CVE-2025-54346"
],
"database_specific": {
"cwe_ids": [
"CWE-80"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-14T18:15:48Z",
"severity": "HIGH"
},
"details": "A Reflected Cross Site Scripting (XSS) vulnerability was found in the Application Server of Desktop Alert PingAlert version 6.1.0.11 to 6.1.1.2 which allows an attacker to hijack user\u2019s browser, capturing sensitive information.",
"id": "GHSA-x22v-j859-94xp",
"modified": "2025-11-14T21:30:29Z",
"published": "2025-11-14T18:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54346"
},
{
"type": "WEB",
"url": "https://desktopalert.net"
},
{
"type": "WEB",
"url": "https://desktopalert.net/cve-2025-54346"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-X2XW-HW8G-6773
Vulnerability from github – Published: 2023-04-11 15:41 – Updated: 2025-11-17 17:32Impact
Pages that are indexed in search results have their entire contents indexed, including any HTML code snippets. These HTML snippets would appear in the search results unsanitised, so it was possible to render arbitrary HTML or run arbitrary scripts.
This is a low risk security issue; to exploit it, an attacker would need to find a way of committing malicious code to a page indexed by a site that uses tech-docs-gem (which are typically not editable by untrusted users). Their code would also be limited by the relatively short length that's rendered in the corresponding search result. Nevertheless, the XSS would then be triggerable by visiting a pre-constructed URL (/search/index.html?q=some+search+term), which users could be tricked into clicking on through social engineering.
Patches
This has been fixed in v3.3.1. HTML is now sanitised in search results.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "govuk_tech_docs"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.2"
},
{
"fixed": "3.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-22048"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-80"
],
"github_reviewed": true,
"github_reviewed_at": "2023-04-11T15:41:30Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\n\nPages that are indexed in search results have their entire contents indexed, including any HTML code snippets. These HTML snippets would appear in the search results unsanitised, so it was possible to render arbitrary HTML or run arbitrary scripts.\n\nThis is a low risk security issue; to exploit it, an attacker would need to find a way of committing malicious code to a page indexed by a site that uses tech-docs-gem (which are typically not editable by untrusted users). Their code would also be limited by the relatively short length that\u0027s rendered in the corresponding search result. Nevertheless, the XSS would then be triggerable by visiting a pre-constructed URL (/search/index.html?q=some+search+term), which users could be tricked into clicking on through social engineering.\n\n### Patches\n\nThis has been fixed in v3.3.1. HTML is now sanitised in search results.",
"id": "GHSA-x2xw-hw8g-6773",
"modified": "2025-11-17T17:32:14Z",
"published": "2023-04-11T15:41:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/alphagov/tech-docs-gem/security/advisories/GHSA-x2xw-hw8g-6773"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22048"
},
{
"type": "WEB",
"url": "https://github.com/alphagov/tech-docs-gem/pull/323"
},
{
"type": "WEB",
"url": "https://github.com/alphagov/tech-docs-gem/commit/a51c7058cec46bf2a4e25a1da62b14ac3fd46b53"
},
{
"type": "PACKAGE",
"url": "https://github.com/alphagov/tech-docs-gem"
},
{
"type": "WEB",
"url": "https://github.com/alphagov/tech-docs-gem/releases/tag/v3.3.1"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/govuk_tech_docs/CVE-2024-22048.yml"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "govuk_tech_docs vulnerable to unescaped HTML on search results page"
}
GHSA-X3V6-F5FR-4WWV
Vulnerability from github – Published: 2025-02-13 09:31 – Updated: 2025-02-13 22:16An authenticated user can perform XSS and potentially impersonate another user.
This issue affects Apache Atlas versions 2.3.0 and earlier.
Users are recommended to upgrade to version 2.4.0, which fixes the issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.atlas:apache-atlas"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-46910"
],
"database_specific": {
"cwe_ids": [
"CWE-80"
],
"github_reviewed": true,
"github_reviewed_at": "2025-02-13T17:24:09Z",
"nvd_published_at": "2025-02-13T09:15:09Z",
"severity": "MODERATE"
},
"details": "An authenticated user can perform XSS and potentially impersonate another user.\n\nThis issue affects Apache Atlas versions\u00a02.3.0 and earlier.\n\nUsers are recommended to upgrade to version 2.4.0, which fixes the issue.",
"id": "GHSA-x3v6-f5fr-4wwv",
"modified": "2025-02-13T22:16:38Z",
"published": "2025-02-13T09:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46910"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/atlas"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/sqzp34l4cdk21zoq5g31qlsvr7jvb1fy"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/02/12/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Apache Atlas: An authenticated user can perform XSS and potentially impersonate another user"
}
GHSA-X525-54HF-XR53
Vulnerability from github – Published: 2024-05-10 15:29 – Updated: 2024-05-14 20:00Description:
A Stored Blind Cross-Site Scripting (XSS) vulnerability has been identified in the Failed Login Attempts Logging Feature of the Froxlor Application. Stored Blind XSS occurs when user input is not properly sanitized and is stored on the server, allowing an attacker to inject malicious scripts that will be executed when other users access the affected page. In this case, an unauthenticated User can inject malicious scripts in the loginname parameter on the Login attempt, which will then be executed when viewed by the Administrator in the System Logs.
The application protects users against XSS attacks by utilizing an xss sanitization library. But the checks of the library were bypassed by crafting an XSS Payload using data binding and interpolation of Vue.js
A working XSS payload was crafted which forces an administrator to add a new malicious attacker-controlled Administrator User. The Payload is: payload.txt
By exploiting this vulnerability, an unauthenticated attacker can force the Administrator to perform actions without the administrator even noticing anything suspicious. In one scenario, I made an exploit that forced the administrator to add an attacker-controlled Administrator into the Froxlor Application, resulting in a compromise of the Froxlor Application.
Impact:
The impact of this vulnerability is severe as it allows an attacker to compromise the Froxlor Application. By exploiting this vulnerability, the attacker can perform various malicious actions such as forcing the Administrator to execute actions without their knowledge or consent. For instance, the attacker can force the Administrator to add a new administrator controlled by the attacker, thereby giving the attacker full control over the application.
Attackers can steal sensitive information such as login credentials, session tokens, and personally identifiable information (PII).
The vulnerability can lead to defacement of the Application.
Mitigation:
Implement thorough input validation and sanitization mechanisms on all user inputs. This will help prevent malicious scripts from being stored and executed. sanitize {{ and }} to prevent data binding and interpolation of Vue.js. Sanitize malicious Javascript functions. Etc.
Steps to Reproduce:
Attacker Steps: 1. Provide an invalid username in Login. 2. Turn on intercept in Burp Suite. 3. In the intercepted request, add the following XSS payload as the value of loginname parameter (Copy from below file): payload.txt 4. Turn off the intercept.
Victim Steps: 5. Login as admin. 6. Go to System Logs, XSS payload will be executed and a popup will appear showing that the Application has been compromised.
Attacker Step:
7. Back at the Attacker's side, log in to the newly created attacker-controlled admin account having all the privileges. The credentials will be username: abcd & Password: abcd@@1234
Evidence:
Figure 1: Code of Logging Invalid login attempts
Figure 2: Code of saving Logs.
Figure 3: Attacker injecting XSS payload.
Figure 4: XSS payload Executed.
Figure 5: XSS payload Reflection.
Video POC
https://github.com/froxlor/Froxlor/assets/59286712/7ba7d3e7-9ee9-4e64-988c-33fd4ebbca27
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "froxlor/froxlor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-34070"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-80"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-10T15:29:59Z",
"nvd_published_at": "2024-05-14T15:38:26Z",
"severity": "CRITICAL"
},
"details": "### Description:\n\nA Stored Blind Cross-Site Scripting (XSS) vulnerability has been identified in the Failed Login Attempts Logging Feature of the Froxlor Application. Stored Blind XSS occurs when user input is not properly sanitized and is stored on the server, allowing an attacker to inject malicious scripts that will be executed when other users access the affected page. In this case, an unauthenticated User can inject malicious scripts in the loginname parameter on the Login attempt, which will then be executed when viewed by the Administrator in the System Logs.\n\nThe application protects users against XSS attacks by utilizing an xss sanitization library. But the checks of the library were bypassed by crafting an XSS Payload using data binding and interpolation of Vue.js\n\nA working XSS payload was crafted which forces an administrator to add a new malicious attacker-controlled Administrator User. The Payload is:\n[payload.txt](https://github.com/froxlor/Froxlor/files/15142616/payload.txt)\n\n\nBy exploiting this vulnerability, an unauthenticated attacker can force the Administrator to perform actions without the administrator even noticing anything suspicious. In one scenario, I made an exploit that forced the administrator to add an attacker-controlled Administrator into the Froxlor Application, resulting in a compromise of the Froxlor Application.\n\n### Impact:\nThe impact of this vulnerability is severe as it allows an attacker to compromise the Froxlor Application. By exploiting this vulnerability, the attacker can perform various malicious actions such as forcing the Administrator to execute actions without their knowledge or consent. For instance, the attacker can force the Administrator to add a new administrator controlled by the attacker, thereby giving the attacker full control over the application.\n\nAttackers can steal sensitive information such as login credentials, session tokens, and personally identifiable information (PII).\n\nThe vulnerability can lead to defacement of the Application.\n\n\n### Mitigation:\nImplement thorough input validation and sanitization mechanisms on all user inputs. This will help prevent malicious scripts from being stored and executed. sanitize {{ and }} to prevent data binding and interpolation of Vue.js.\nSanitize malicious Javascript functions. Etc.\n\n### Steps to Reproduce:\n\n**Attacker Steps:**\n1. Provide an invalid username in Login.\n2. Turn on intercept in Burp Suite.\n3. In the intercepted request, add the following XSS payload as the value of loginname parameter (Copy from below file):\n[payload.txt](https://github.com/froxlor/Froxlor/files/15142616/payload.txt)\n4. Turn off the intercept.\n\n**Victim Steps:**\n5. Login as admin.\n6. Go to System Logs, XSS payload will be executed and a popup will appear showing that the Application has been compromised.\n\n**Attacker Step:**\n7. Back at the Attacker\u0027s side, log in to the newly created attacker-controlled admin account having all the privileges. The credentials will be username: `abcd` \u0026 Password: `abcd@@1234`\n\n### Evidence:\n\n\n_Figure 1: Code of Logging Invalid login attempts_\n\n\n_Figure 2: Code of saving Logs._\n\n\n_Figure 3: Attacker injecting XSS payload._\n\n\n_Figure 4: XSS payload Executed._\n\n\n_Figure 5: XSS payload Reflection._\n\n### Video POC\n\nhttps://github.com/froxlor/Froxlor/assets/59286712/7ba7d3e7-9ee9-4e64-988c-33fd4ebbca27\n\n",
"id": "GHSA-x525-54hf-xr53",
"modified": "2024-05-14T20:00:57Z",
"published": "2024-05-10T15:29:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/froxlor/Froxlor/security/advisories/GHSA-x525-54hf-xr53"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34070"
},
{
"type": "WEB",
"url": "https://github.com/froxlor/Froxlor/commit/a862307bce5cdfb1c208b835f3e8faddd23046e6"
},
{
"type": "PACKAGE",
"url": "https://github.com/froxlor/Froxlor"
}
],
"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": "Blind XSS Leading to Froxlor Application Compromise"
}
GHSA-X58F-RJP3-RH75
Vulnerability from github – Published: 2023-07-06 15:30 – Updated: 2025-11-04 21:30Cross-site scripting (xss) vulnerabilities exist in the requestHandlers.js detail_device functionality of Milesight VPN v2.0.2. A specially-crafted HTTP request can lead to arbitrary Javascript code injection. An attacker can send an HTTP request to trigger these vulnerabilities.This XSS is exploited through the name field of the database.
{
"affected": [],
"aliases": [
"CVE-2023-24496"
],
"database_specific": {
"cwe_ids": [
"CWE-80"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-06T15:15:11Z",
"severity": "MODERATE"
},
"details": "Cross-site scripting (xss) vulnerabilities exist in the requestHandlers.js detail_device functionality of Milesight VPN v2.0.2. A specially-crafted HTTP request can lead to arbitrary Javascript code injection. An attacker can send an HTTP request to trigger these vulnerabilities.This XSS is exploited through the name field of the database.",
"id": "GHSA-x58f-rjp3-rh75",
"modified": "2025-11-04T21:30:34Z",
"published": "2023-07-06T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24496"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2023-1704"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2023-1704"
}
],
"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"
}
]
}
GHSA-X7RM-W2H5-52QJ
Vulnerability from github – Published: 2022-04-12 00:00 – Updated: 2022-04-16 00:01An unprivileged user could use the functionality of the NS WooCommerce Watermark WordPress plugin through 2.11.3 to load images that hide malware for example from passing malicious domains to hide their trace, by making them pass through the vulnerable domain.
{
"affected": [],
"aliases": [
"CVE-2022-0989"
],
"database_specific": {
"cwe_ids": [
"CWE-80"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-11T15:15:00Z",
"severity": "HIGH"
},
"details": "An unprivileged user could use the functionality of the NS WooCommerce Watermark WordPress plugin through 2.11.3 to load images that hide malware for example from passing malicious domains to hide their trace, by making them pass through the vulnerable domain.",
"id": "GHSA-x7rm-w2h5-52qj",
"modified": "2022-04-16T00:01:10Z",
"published": "2022-04-12T00:00:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0989"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/a6bfc150-8e3f-4b2d-a6e1-09406af41dd4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"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.