CWE-86
AllowedImproper Neutralization of Invalid Characters in Identifiers in Web Pages
Abstraction: Variant · Status: Draft
The product does not neutralize or incorrectly neutralizes invalid characters or byte sequences in the middle of tag names, URI schemes, and other identifiers.
22 vulnerabilities reference this CWE, most recent first.
GHSA-29PJ-957V-52MC
Vulnerability from github – Published: 2026-08-06 20:30 – Updated: 2026-08-06 20:30## Summary
The AttributesExtension's href/src unsafe-link filter (AttributesHelper::filterAttributes()) can be bypassed by embedding control bytes in a javascript: URL that browsers discard before parsing the scheme. Two variants:
- Tab/newline inside the scheme — a literal ASCII TAB (0x09), CR (0x0D), or LF (0x0A), e.g.
java<TAB>script:alert(1). Per the WHATWG URL Standard's "basic URL parser" step 3, browsers "remove all ASCII tab or newline from input". - Leading C0 controls — e.g.
<0x01>javascript:alert(1). Per step 1 of the same algorithm, browsers remove any leading or trailing C0 control or space. (A leading space alone does not bypass, becauseparseAttributes()alreadytrim()s the value; other C0 bytes are not trimmed.)
The filter is a literal anchored-prefix regex (RegexHelper::isLinkPotentiallyUnsafe() / REGEX_UNSAFE_PROTOCOL) that matches neither obfuscated form, so in both cases the browser still executes javascript:alert(1).
This is confirmed reproducible even with allow_unsafe_links => false set — i.e. even applications that have followed the library's own documented hardening guidance for untrusted input remain exploitable.
This is a sibling gap in the same defense that CVE-2025-46734 (GHSA-3527-qv2q-pfvx) fixed in v2.7.0 — that fix made href/src respect allow_unsafe_links, but did not normalize control bytes before checking, so these obfuscation techniques were never covered.
Vulnerability
Files:
- src/Util/RegexHelper.php:69 (REGEX_UNSAFE_PROTOCOL), :239-242 (isLinkPotentiallyUnsafe())
- src/Extension/Attributes/Util/AttributesHelper.php:149-179 (filterAttributes())
CWE: CWE-79 (Improper Neutralization of Input During Web Page Generation / XSS) — primary
- CWE-692 (Incomplete Denylist to Cross-Site Scripting) — the anchored-prefix denylist in REGEX_UNSAFE_PROTOCOL is incomplete. This is a composite of CWE-184 and CWE-79, so it captures the full "incomplete denylist → XSS" chain on its own.
- CWE-86 (Improper Neutralization of Invalid Characters in Identifiers in Web Pages) — the specific evasion technique: control bytes embedded within the URI scheme identifier, which the browser strips before resolving it.
Root Cause
// src/Util/RegexHelper.php
public const REGEX_UNSAFE_PROTOCOL = '/^(?:javascript|vbscript|file|data):/i';
public static function isLinkPotentiallyUnsafe(string $url): bool
{
return \preg_match(self::REGEX_UNSAFE_PROTOCOL, $url) !== 0 && \preg_match(self::REGEX_SAFE_DATA_PROTOCOL, $url) === 0;
}
// src/Extension/Attributes/Util/AttributesHelper.php
foreach ($attributes as $name => $value) {
$attrNameLower = \strtolower($name);
if (! $allowUnsafeLinks && ($attrNameLower === 'href' || $attrNameLower === 'src') && \is_string($value) && RegexHelper::isLinkPotentiallyUnsafe($value)) {
unset($attributes[$name]);
continue;
}
...
The Attributes extension's own quote-value grammar (PARTIAL_DOUBLEQUOTEDVALUE = '"[^"]*"') accepts any byte except " inside quotes, including raw tab/CR/LF and other C0 controls, and parseAttributes() only trim()s (leading/trailing, and only the default charlist " \t\n\r\0\x0B" — so a leading \x01 survives). Critically, the core Markdown link-destination path (LinkParserHelper → UrlEncoder::unescapeAndEncode()) percent-encodes every control byte before this same safety check ever runs — but the Attributes extension's href/src handling has no equivalent normalization step, so the raw control byte reaches both the check and the final HTML output (Xml::escape() only escapes & < > " ', not tab/CR/LF, since they're legal bytes inside an HTML attribute).
Attack Scenario
- An application enables the (commonly-used)
AttributesExtensionand setsallow_unsafe_links => false— the project's own documented hardening step for untrusted input. - An attacker submits Markdown:
[Click me](javascript:alert(0)){href="java<TAB>script:alert(document.cookie)"}(TAB is one literal 0x09 byte). - The library emits
<a href="java<TAB>script:alert(document.cookie)">Click me</a>—isLinkPotentiallyUnsafe()doesn't match the tab-split scheme, so the filter takes no action. - A victim viewing/clicking the link has the browser strip the embedded TAB and execute
javascript:alert(document.cookie)in the victim's session — stored XSS, cookie theft, account takeover potential.
Why the payload needs an unsafe core destination. Step 2 above deliberately uses [Click me](javascript:alert(0)) rather than a normal link. LinkRenderer overwrites attrs['href'] with the node's own URL unless that URL is itself judged unsafe — so [x](https://example.com){href="java<TAB>script:..."} renders the harmless href="https://example.com", and an empty destination [x](){href="..."} renders href="". The attacker therefore supplies a core destination that the filter does catch, which suppresses the overwrite and lets the attribute-supplied href reach the final tag. This is no obstacle in practice — the attacker writes the entire Markdown document.
Two related forms that are not exploitable, noted so the fix isn't over-scoped:
- Attaching the attribute to a non-link block —
hi {href="java<TAB>script:alert(1)"}— does bypass the filter and emits<p href="java<TAB>script:alert(1)">, buthrefon a<p>is inert: there is nothing to navigate. (An earlier draft of this report described this as a "simpler, unconditional variant" of the attack; it is a filter bypass, not an XSS.) <img src>is unaffected, sinceImageRendererunconditionally overwritessrcfrom the core URL regardless of the safety verdict.
Recommended Fix
Normalize inside RegexHelper::isLinkPotentiallyUnsafe() before testing, mirroring the WHATWG URL parser's own normalization. This covers both variants, fixes every call site at once (LinkRenderer, ImageRenderer, and any third-party callers), and needs no changes in the Attributes extension.
Affected Versions
>= 1.5.0, <= 2.8.3 - every release that ships the AttributesExtension. Verified by installing each version and rendering the payloads with allow_unsafe_links => false. The attribute-value grammar (PARTIAL_DOUBLEQUOTEDVALUE = '"[^"]*"') has accepted raw control bytes since the extension was introduced, and none of the intervening parser rewrites narrowed it.
Prior Related Advisories
GHSA-3527-qv2q-pfvx / CVE-2025-46734 fixed a different Attributes-extension XSS (unallowlisted on* handlers, href/src not respecting allow_unsafe_links at all) in v2.7.0. This issue bypasses the specific href/src protection that fix introduced (the control-byte normalization gap was not part of that fix) - but the obfuscated inputs also work on older versions.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.8.3"
},
"package": {
"ecosystem": "Packagist",
"name": "league/commonmark"
},
"ranges": [
{
"events": [
{
"introduced": "1.5.0"
},
{
"fixed": "2.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-71478"
],
"database_specific": {
"cwe_ids": [
"CWE-692",
"CWE-79",
"CWE-86"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-06T20:30:39Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "\ufeff## Summary\n\nThe `AttributesExtension`\u0027s `href`/`src` unsafe-link filter (`AttributesHelper::filterAttributes()`) can be bypassed by embedding control bytes in a `javascript:` URL that browsers discard before parsing the scheme. Two variants:\n\n- **Tab/newline inside the scheme** \u2014 a literal ASCII TAB (0x09), CR (0x0D), or LF (0x0A), e.g. `java\u003cTAB\u003escript:alert(1)`. Per the WHATWG URL Standard\u0027s \"basic URL parser\" step 3, browsers \"remove all ASCII tab or newline from input\".\n- **Leading C0 controls** \u2014 e.g. `\u003c0x01\u003ejavascript:alert(1)`. Per step 1 of the same algorithm, browsers remove any leading or trailing C0 control or space. (A leading *space* alone does not bypass, because `parseAttributes()` already `trim()`s the value; other C0 bytes are not trimmed.)\n\nThe filter is a literal anchored-prefix regex (`RegexHelper::isLinkPotentiallyUnsafe()` / `REGEX_UNSAFE_PROTOCOL`) that matches neither obfuscated form, so in both cases the browser still executes `javascript:alert(1)`.\n\n**This is confirmed reproducible even with `allow_unsafe_links =\u003e false` set** \u2014 i.e. even applications that have followed the library\u0027s own documented hardening guidance for untrusted input remain exploitable.\n\nThis is a *sibling gap* in the same defense that CVE-2025-46734 (GHSA-3527-qv2q-pfvx) fixed in v2.7.0 \u2014 that fix made `href`/`src` respect `allow_unsafe_links`, but did not normalize control bytes before checking, so these obfuscation techniques were never covered.\n\n## Vulnerability\n\n**Files**:\n- `src/Util/RegexHelper.php:69` (`REGEX_UNSAFE_PROTOCOL`), `:239-242` (`isLinkPotentiallyUnsafe()`)\n- `src/Extension/Attributes/Util/AttributesHelper.php:149-179` (`filterAttributes()`)\n\n**CWE**: CWE-79 (Improper Neutralization of Input During Web Page Generation / XSS) \u2014 primary\n- CWE-692 (Incomplete Denylist to Cross-Site Scripting) \u2014 the anchored-prefix denylist in `REGEX_UNSAFE_PROTOCOL` is incomplete. This is a composite of CWE-184 and CWE-79, so it captures the full \"incomplete denylist \u2192 XSS\" chain on its own.\n- CWE-86 (Improper Neutralization of Invalid Characters in Identifiers in Web Pages) \u2014 the specific evasion technique: control bytes embedded within the URI scheme identifier, which the browser strips before resolving it.\n\n### Root Cause\n```php\n// src/Util/RegexHelper.php\npublic const REGEX_UNSAFE_PROTOCOL = \u0027/^(?:javascript|vbscript|file|data):/i\u0027;\n\npublic static function isLinkPotentiallyUnsafe(string $url): bool\n{\n return \\preg_match(self::REGEX_UNSAFE_PROTOCOL, $url) !== 0 \u0026\u0026 \\preg_match(self::REGEX_SAFE_DATA_PROTOCOL, $url) === 0;\n}\n\n// src/Extension/Attributes/Util/AttributesHelper.php\nforeach ($attributes as $name =\u003e $value) {\n $attrNameLower = \\strtolower($name);\n if (! $allowUnsafeLinks \u0026\u0026 ($attrNameLower === \u0027href\u0027 || $attrNameLower === \u0027src\u0027) \u0026\u0026 \\is_string($value) \u0026\u0026 RegexHelper::isLinkPotentiallyUnsafe($value)) {\n unset($attributes[$name]);\n continue;\n }\n ...\n```\nThe Attributes extension\u0027s own quote-value grammar (`PARTIAL_DOUBLEQUOTEDVALUE = \u0027\"[^\"]*\"\u0027`) accepts any byte except `\"` inside quotes, including raw tab/CR/LF and other C0 controls, and `parseAttributes()` only `trim()`s (leading/trailing, and only the default charlist `\" \\t\\n\\r\\0\\x0B\"` \u2014 so a leading `\\x01` survives). Critically, **the core Markdown link-destination path (`LinkParserHelper` \u2192 `UrlEncoder::unescapeAndEncode()`) percent-encodes every control byte before this same safety check ever runs \u2014 but the Attributes extension\u0027s `href`/`src` handling has no equivalent normalization step**, so the raw control byte reaches both the check and the final HTML output (`Xml::escape()` only escapes `\u0026 \u003c \u003e \" \u0027`, not tab/CR/LF, since they\u0027re legal bytes inside an HTML attribute).\n\n### Attack Scenario\n1. An application enables the (commonly-used) `AttributesExtension` and sets `allow_unsafe_links =\u003e false` \u2014 the project\u0027s own documented hardening step for untrusted input.\n2. An attacker submits Markdown: `[Click me](javascript:alert(0)){href=\"java\u003cTAB\u003escript:alert(document.cookie)\"}` (TAB is one literal 0x09 byte).\n3. The library emits `\u003ca href=\"java\u003cTAB\u003escript:alert(document.cookie)\"\u003eClick me\u003c/a\u003e` \u2014 `isLinkPotentiallyUnsafe()` doesn\u0027t match the tab-split scheme, so the filter takes no action.\n4. A victim viewing/clicking the link has the browser strip the embedded TAB and execute `javascript:alert(document.cookie)` in the victim\u0027s session \u2014 stored XSS, cookie theft, account takeover potential.\n\n**Why the payload needs an unsafe core destination.** Step 2 above deliberately uses `[Click me](javascript:alert(0))` rather than a normal link. `LinkRenderer` overwrites `attrs[\u0027href\u0027]` with the node\u0027s own URL *unless* that URL is itself judged unsafe \u2014 so `[x](https://example.com){href=\"java\u003cTAB\u003escript:...\"}` renders the harmless `href=\"https://example.com\"`, and an empty destination `[x](){href=\"...\"}` renders `href=\"\"`. The attacker therefore supplies a core destination that the filter *does* catch, which suppresses the overwrite and lets the attribute-supplied `href` reach the final tag. This is no obstacle in practice \u2014 the attacker writes the entire Markdown document.\n\nTwo related forms that are **not** exploitable, noted so the fix isn\u0027t over-scoped:\n\n- Attaching the attribute to a non-link block \u2014 `hi {href=\"java\u003cTAB\u003escript:alert(1)\"}` \u2014 does bypass the filter and emits `\u003cp href=\"java\u003cTAB\u003escript:alert(1)\"\u003e`, but `href` on a `\u003cp\u003e` is inert: there is nothing to navigate. (An earlier draft of this report described this as a \"simpler, unconditional variant\" of the attack; it is a filter bypass, not an XSS.)\n- `\u003cimg src\u003e` is unaffected, since `ImageRenderer` unconditionally overwrites `src` from the core URL regardless of the safety verdict.\n\n### Recommended Fix\n\nNormalize inside `RegexHelper::isLinkPotentiallyUnsafe()` before testing, mirroring the WHATWG URL parser\u0027s own normalization. This covers both variants, fixes every call site at once (`LinkRenderer`, `ImageRenderer`, and any third-party callers), and needs no changes in the Attributes extension.\n\n## Affected Versions\n\n**`\u003e= 1.5.0, \u003c= 2.8.3`** - every release that ships the `AttributesExtension`. Verified by installing each version and rendering the payloads with `allow_unsafe_links =\u003e false`. The attribute-value grammar (`PARTIAL_DOUBLEQUOTEDVALUE = \u0027\"[^\"]*\"\u0027`) has accepted raw control bytes since the extension was introduced, and none of the intervening parser rewrites narrowed it.\n\n## Prior Related Advisories\n\nGHSA-3527-qv2q-pfvx / CVE-2025-46734 fixed a different Attributes-extension XSS (unallowlisted `on*` handlers, `href`/`src` not respecting `allow_unsafe_links` at all) in v2.7.0. This issue bypasses the specific `href`/`src` protection that fix introduced (the control-byte normalization gap was not part of that fix) - but the obfuscated inputs also work on older versions.",
"id": "GHSA-29pj-957v-52mc",
"modified": "2026-08-06T20:30:40Z",
"published": "2026-08-06T20:30:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thephpleague/commonmark/security/advisories/GHSA-29pj-957v-52mc"
},
{
"type": "WEB",
"url": "https://github.com/thephpleague/commonmark/commit/493a5aa7d65754b73846006eaff9c2c4431a8e2c"
},
{
"type": "PACKAGE",
"url": "https://github.com/thephpleague/commonmark"
},
{
"type": "WEB",
"url": "https://github.com/thephpleague/commonmark/releases/tag/2.9.0"
}
],
"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": "league/commonmark: AttributesExtension href/src unsafe-link filter bypass via embedded control bytes"
}
GHSA-663W-2XP3-5739
Vulnerability from github – Published: 2023-10-25 21:02 – Updated: 2023-11-01 06:06Impact
The cleaning of attributes during XHTML rendering, introduced in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid attribute names. This can be exploited, e.g., via the link syntax in any content that supports XWiki syntax like comments in XWiki:
[[Link1>>https://XWiki.example.com||/onmouseover="alert('XSS1')"]]
When a user moves the mouse over this link, the malicious JavaScript code is executed in the context of the user session. When this user is a privileged user who has programming rights, this allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance.
While this attribute was correctly recognized as not allowed, the attribute was still printed with a prefix data-xwiki-translated-attribute- without further cleaning or validation.
Note that while versions below 14.6 are not vulnerable to this particular vulnerability, they are still vulnerable to XSS through attributes in XWiki syntax, see the corresponding advisory.
Patches
This problem has been patched in XWiki 14.10.4 and 15.0 RC1 by removing characters not allowed in data attributes and then validating the cleaned attribute again.
Workarounds
There are no known workarounds apart from upgrading to a version including the fix.
References
- https://jira.xwiki.org/browse/XRENDERING-697
- https://github.com/xwiki/xwiki-rendering/commit/f4d5acac451dccaf276e69f0b49b72221eef5d2f
For more information
If you have any questions or comments about this advisory: * Open an issue in Jira XWiki * Email us at XWiki Security mailing-list
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.rendering:xwiki-rendering-xml"
},
"ranges": [
{
"events": [
{
"introduced": "14.6-rc-1"
},
{
"fixed": "14.10.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-37908"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-83",
"CWE-86"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-25T21:02:49Z",
"nvd_published_at": "2023-10-25T18:17:28Z",
"severity": "CRITICAL"
},
"details": "### Impact\nThe cleaning of attributes during XHTML rendering, introduced in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid attribute names. This can be exploited, e.g., via the link syntax in any content that supports XWiki syntax like comments in XWiki: \n\n```\n[[Link1\u003e\u003ehttps://XWiki.example.com||/onmouseover=\"alert(\u0027XSS1\u0027)\"]]\n```\n\nWhen a user moves the mouse over this link, the malicious JavaScript code is executed in the context of the user session. When this user is a privileged user who has programming rights, this allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance.\n\nWhile this attribute was correctly recognized as not allowed, the attribute was still printed with a prefix `data-xwiki-translated-attribute-` without further cleaning or validation.\n\nNote that while versions below 14.6 are not vulnerable to this particular vulnerability, they are still vulnerable to XSS through attributes in XWiki syntax, see [the corresponding advisory](https://github.com/xwiki/xwiki-rendering/security/advisories/GHSA-6gf5-c898-7rxp).\n\n### Patches\nThis problem has been patched in XWiki 14.10.4 and 15.0 RC1 by removing characters not allowed in data attributes and then validating the cleaned attribute again.\n\n### Workarounds\nThere are no known workarounds apart from upgrading to a version including the fix.\n\n### References\n* https://jira.xwiki.org/browse/XRENDERING-697\n* https://github.com/xwiki/xwiki-rendering/commit/f4d5acac451dccaf276e69f0b49b72221eef5d2f\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki](https://jira.xwiki.org/)\n* Email us at [XWiki Security mailing-list](mailto:security@xwiki.org)\n",
"id": "GHSA-663w-2xp3-5739",
"modified": "2023-11-01T06:06:17Z",
"published": "2023-10-25T21:02:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-rendering/security/advisories/GHSA-663w-2xp3-5739"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-rendering/security/advisories/GHSA-6gf5-c898-7rxp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37908"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-rendering/commit/f4d5acac451dccaf276e69f0b49b72221eef5d2f"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-rendering"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XRENDERING-697"
}
],
"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": "org.xwiki.rendering:xwiki-rendering-xml Improper Neutralization of Invalid Characters in Identifiers in Web Pages vulnerability"
}
GHSA-68QF-XHQ3-9QJ5
Vulnerability from github – Published: 2024-07-26 12:35 – Updated: 2025-11-04 00:30Apache Traffic Server accepts characters that are not allowed for HTTP field names and forwards malformed requests to origin servers. This can be utilized for request smuggling and may also lead cache poisoning if the origin servers are vulnerable.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.10, from 9.0.0 through 9.2.4.
Users are recommended to upgrade to version 8.1.11 or 9.2.5, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2023-38522"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-444",
"CWE-86"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-26T10:15:01Z",
"severity": "HIGH"
},
"details": "Apache Traffic Server accepts characters that are not allowed for HTTP field names and forwards malformed requests to origin servers. This can be utilized for request smuggling and may also lead cache poisoning if the origin servers are vulnerable.\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.10, from 9.0.0 through 9.2.4.\n\nUsers are recommended to upgrade to version 8.1.11 or 9.2.5, which fixes the issue.",
"id": "GHSA-68qf-xhq3-9qj5",
"modified": "2025-11-04T00:30:58Z",
"published": "2024-07-26T12:35:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38522"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/c4mcmpblgl8kkmyt56t23543gp8v56m0"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00040.html"
}
],
"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"
}
]
}
GHSA-7X89-2C7C-8XJF
Vulnerability from github – Published: 2025-01-08 18:30 – Updated: 2025-01-08 18:30A vulnerability in the web-based management interface of Cisco Common Services Platform Collector (CSPC) could allow an authenticated, remote attacker to conduct cross-site scripting (XSS) attacks against a user of the interface.
This vulnerability is due to insufficient validation of user-supplied input by the web-based management interface of an affected system. 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 must have at least a low-privileged account on an affected device. Cisco has not released software updates that address this vulnerability. There are no workarounds that address this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2025-20166"
],
"database_specific": {
"cwe_ids": [
"CWE-86"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-08T17:15:16Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web-based management interface of Cisco Common Services Platform Collector (CSPC) could allow an authenticated, remote attacker to conduct cross-site scripting (XSS) attacks against a user of the interface.\n\nThis vulnerability is due to insufficient validation of user-supplied input by the web-based management interface of an affected system. 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 must have at least a low-privileged account on an affected device.\nCisco has not released software updates that address this vulnerability. There are no workarounds that address this vulnerability.",
"id": "GHSA-7x89-2c7c-8xjf",
"modified": "2025-01-08T18:30:48Z",
"published": "2025-01-08T18:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20166"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cspc-xss-CDOJZyH"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-xwork-xss-KCcg7WwU"
}
],
"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-8W77-HPX9-8FM3
Vulnerability from github – Published: 2024-11-06 21:30 – Updated: 2025-01-07 18:30A malicious website could have included an iframe with an malformed URI resulting in a non-exploitable browser crash. This vulnerability affects Firefox < 126.
{
"affected": [],
"aliases": [
"CVE-2024-10941"
],
"database_specific": {
"cwe_ids": [
"CWE-86"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-06T21:15:05Z",
"severity": "MODERATE"
},
"details": "A malicious website could have included an iframe with an malformed URI resulting in a non-exploitable browser crash. This vulnerability affects Firefox \u003c 126.",
"id": "GHSA-8w77-hpx9-8fm3",
"modified": "2025-01-07T18:30:43Z",
"published": "2024-11-06T21:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10941"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1880879"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1887614"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2024-21"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F8FG-PG57-V4J8
Vulnerability from github – Published: 2026-09-01 20:18 – Updated: 2026-09-01 20:18Summary
The AttributesExtension documents a security guarantee:
Note: Attributes starting with
on(e.g.onclickoronerror) are capable of executing JavaScript code and are therefore never allowed by default. You must explicitly add them to theallowlist if you want to use them.—
docs/2.x/extensions/attributes.md
Prefixing the attribute name with a single U+000C FORM FEED byte defeats that guarantee.
{<FF>onclick="alert(1)"} passes through AttributesHelper::filterAttributes() untouched and is
written verbatim into the output, where browsers parse it as a genuine onclick handler.
The same prefix defeats the allow_unsafe_links check, letting a javascript: URI through on
href / src even when allow_unsafe_links is false.
This bypasses the fix shipped in the 2.7.0 security release ("Fix XSS in AttributesExtension",
43207253ea5f14867c77c697cd3838c446cadcea), which added filterAttributes() for the express
purpose of blocking these attributes.
Throughout this report <FF> denotes a literal U+000C byte ("\x0C" in PHP). It is invisible in
rendered text, so all payloads below are written with PHP escape sequences to stay unambiguous.
Details
Three behaviours combine.
1. \x0C survives the parser's trim().
AttributesHelper::SINGLE_ATTRIBUTE begins with \s*, and Cursor::match() returns
$matches[0][0] — the entire match, including that leading whitespace. The result is cleaned
with PHP's trim():
// src/Extension/Attributes/Util/AttributesHelper.php:62
while ($attribute = \trim((string) $attributeCursor->match('/^' . self::SINGLE_ATTRIBUTE . '/i'))) {
PCRE \s matches \x0C, but PHP's default trim() charlist is " \t\n\r\0\x0B" — it includes
the vertical tab \x0B but not the form feed \x0C. The byte is therefore consumed by the
regex, retained in the returned match, and not stripped. It ends up inside the attribute name:
// src/Extension/Attributes/Util/AttributesHelper.php:94
$attributes[\trim($name)] = \trim($value); // $name === "\x0Conclick"
\x0C is the only byte with this property: every other character the HTML5 tokenizer treats as
whitespace (\x09, \x0A, \x0D, \x20), plus \x0B, is in PHP's trim charlist. The PoC
includes a \x0B case as a control, and it is correctly stripped.
2. The filter's string comparisons miss it.
filterAttributes() compares the raw name against literal strings:
// src/Extension/Attributes/Util/AttributesHelper.php:148-166
$attrNameLower = \strtolower($name); // "\x0conclick"
... ($attrNameLower === 'href' || $attrNameLower === 'src') ... // false
... \str_starts_with($attrNameLower, 'on') ... // false -> not removed
3. The renderer never escapes attribute names.
// src/Util/HtmlElement.php:123-129
$result .= ' ' . $key . '="' . Xml::escape($value) . '"'; // $key emitted raw
Because the HTML5 tokenizer treats \x0C as whitespace between attributes, the browser reads
the name as plain onclick.
PoC
<?php
require 'vendor/autoload.php';
use League\CommonMark\Environment\Environment;
use League\CommonMark\Extension\Attributes\AttributesExtension;
use League\CommonMark\Extension\CommonMark\CommonMarkCoreExtension;
use League\CommonMark\MarkdownConverter;
// The most defensive configuration docs/2.x/security.md recommends.
$env = new Environment([
'html_input' => 'escape',
'allow_unsafe_links' => false,
'max_nesting_level' => 100,
// 'attributes' => ['allow' => [...]] deliberately left at its default []
]);
$env->addExtension(new CommonMarkCoreExtension());
$env->addExtension(new AttributesExtension());
$converter = new MarkdownConverter($env);
$FF = "\x0C";
echo $converter->convert('hello {onclick="alert(1)"}')->getContent();
// <p>hello</p> <- filtered, as documented
echo $converter->convert('hello {' . $FF . 'onclick="alert(1)"}')->getContent();
// <p \x0Conclick="alert(1)">hello</p> <- BYPASS
Full observed output (\x0C shown escaped; it is a literal single byte in the real output):
| # | Markdown input | Rendered output | Result |
|---|---|---|---|
| A | hello {onclick="alert(1)"} |
<p>hello</p> |
filtered (control) |
| B | hello {\x0Conclick="alert(1)"} |
<p \x0Conclick="alert(1)">hello</p> |
bypass |
| C | hello {\x0Bonclick="alert(1)"} |
<p>hello</p> |
filtered (control) |
| D | [click](javascript:alert(1)) |
<p><a>click</a></p> |
filtered (control) |
| E | [click](https://example.com){\x0Chref="javascript:alert(1)"} |
<p><a \x0Chref="javascript:alert(1)" href="https://example.com">click</a></p> |
bypass |
| F | {\x0Conerror="alert(1)"} |
<p><img \x0Conerror="alert(1)" src="…" alt="x" /></p> |
bypass |
| G | # heading + newline + {\x0Conclick="alert(1)"} |
<h1 \x0Conclick="alert(1)">heading</h1> |
bypass (block syntax) |
In case E the injected href precedes the legitimate one. Per the HTML5 duplicate-attribute rule
the first occurrence wins, so the javascript: URI is the one the browser actually uses.
Browser confirmation. Loading the library's unmodified output in Chrome for Testing 148:
<img> attribute names : ["onerror","src","alt"] <- parsed as a real `onerror`
typeof img.onerror : function <- bound as an event handler
handlers fired : ["img-onerror"] <- fired on load, no interaction
document.title : XSS-FIRED
link href attribute : "javascript:void(0)"
link href property : "javascript:void(0)" <- javascript: URI is the effective href
page errors : []
The onerror case executes with no user interaction — rendering the attacker's Markdown is
sufficient.
Verified against git HEAD (f966b17a) and against tag 2.9.0, on PHP 8.5.8.
Impact
Stored cross-site scripting in any application that renders untrusted Markdown with
AttributesExtension enabled and attributes.allow left at its default [] — even when the
application has followed every hardening step in docs/2.x/security.md
(html_input => 'escape', allow_unsafe_links => false, max_nesting_level => 100).
Consequences are the usual for stored XSS: session and cookie theft, actions performed as the
viewing user, and account takeover where the host application permits it. Because the payload can
be attached to an image (onerror), it fires on page load without requiring the victim to
interact with anything.
The affected configuration is the extension's default: attributes.allow defaults to [], and
the documentation describes that default as safe with respect to on* attributes.
Workaround for users
Setting an explicit allow list takes the other branch of filterAttributes(), which drops the
form-feed name because it is not in the list:
$config = ['attributes' => ['allow' => ['id', 'class', 'align']]];
Verified: hello {\x0Conclick="alert(1)"} then renders as <p>hello</p>.
Suggested fix
The narrow fix is to add \x0C to the trim charlist at AttributesHelper.php lines 62, 89, 90
and 94. That closes this instance but leaves the shape of the problem in place.
A more durable fix is to reject anything that is not a well-formed attribute name in
filterAttributes(), reusing the constant the parser already defines (RegexHelper is already
imported in that file):
foreach ($attributes as $name => $value) {
// Names are compared against literal strings below and emitted without escaping,
// so anything that isn't a plain attribute name must not get through.
if (\preg_match('/^' . RegexHelper::PARTIAL_ATTRIBUTENAME . '$/i', $name) !== 1) {
unset($attributes[$name]);
continue;
}
$attrNameLower = \strtolower($name);
// ... existing logic unchanged
}
As defence in depth, HtmlElement::__toString() could validate or escape $key. It currently
trusts its callers to supply safe attribute names, and filterAttributes() is the only thing
standing between that method and user-supplied input.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "league/commonmark"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0"
},
{
"fixed": "2.9.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-86"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-01T20:18:29Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nThe `AttributesExtension` documents a security guarantee:\n\n\u003e **Note:** Attributes starting with `on` (e.g. `onclick` or `onerror`) are capable of executing\n\u003e JavaScript code and are therefore **never allowed by default**. You must explicitly add them to\n\u003e the `allow` list if you want to use them.\n\u003e\n\u003e \u2014 `docs/2.x/extensions/attributes.md`\n\nPrefixing the attribute name with a single U+000C FORM FEED byte defeats that guarantee.\n`{\u003cFF\u003eonclick=\"alert(1)\"}` passes through `AttributesHelper::filterAttributes()` untouched and is\nwritten verbatim into the output, where browsers parse it as a genuine `onclick` handler.\n\nThe same prefix defeats the `allow_unsafe_links` check, letting a `javascript:` URI through on\n`href` / `src` even when `allow_unsafe_links` is `false`.\n\nThis bypasses the fix shipped in the **2.7.0 security release** (\"Fix XSS in AttributesExtension\",\n43207253ea5f14867c77c697cd3838c446cadcea), which added `filterAttributes()` for the express\npurpose of blocking these attributes.\n\nThroughout this report `\u003cFF\u003e` denotes a literal U+000C byte (`\"\\x0C\"` in PHP). It is invisible in\nrendered text, so all payloads below are written with PHP escape sequences to stay unambiguous.\n\n### Details\n\nThree behaviours combine.\n\n**1. `\\x0C` survives the parser\u0027s `trim()`.**\n\n`AttributesHelper::SINGLE_ATTRIBUTE` begins with `\\s*`, and `Cursor::match()` returns\n`$matches[0][0]` \u2014 the *entire* match, including that leading whitespace. The result is cleaned\nwith PHP\u0027s `trim()`:\n\n```php\n// src/Extension/Attributes/Util/AttributesHelper.php:62\nwhile ($attribute = \\trim((string) $attributeCursor-\u003ematch(\u0027/^\u0027 . self::SINGLE_ATTRIBUTE . \u0027/i\u0027))) {\n```\n\nPCRE `\\s` matches `\\x0C`, but PHP\u0027s default `trim()` charlist is `\" \\t\\n\\r\\0\\x0B\"` \u2014 it includes\nthe vertical tab `\\x0B` but **not** the form feed `\\x0C`. The byte is therefore consumed by the\nregex, retained in the returned match, and not stripped. It ends up inside the attribute name:\n\n```php\n// src/Extension/Attributes/Util/AttributesHelper.php:94\n$attributes[\\trim($name)] = \\trim($value); // $name === \"\\x0Conclick\"\n```\n\n`\\x0C` is the only byte with this property: every other character the HTML5 tokenizer treats as\nwhitespace (`\\x09`, `\\x0A`, `\\x0D`, `\\x20`), plus `\\x0B`, is in PHP\u0027s trim charlist. The PoC\nincludes a `\\x0B` case as a control, and it is correctly stripped.\n\n**2. The filter\u0027s string comparisons miss it.**\n\n`filterAttributes()` compares the raw name against literal strings:\n\n```php\n// src/Extension/Attributes/Util/AttributesHelper.php:148-166\n$attrNameLower = \\strtolower($name); // \"\\x0conclick\"\n... ($attrNameLower === \u0027href\u0027 || $attrNameLower === \u0027src\u0027) ... // false\n... \\str_starts_with($attrNameLower, \u0027on\u0027) ... // false -\u003e not removed\n```\n\n**3. The renderer never escapes attribute names.**\n\n```php\n// src/Util/HtmlElement.php:123-129\n$result .= \u0027 \u0027 . $key . \u0027=\"\u0027 . Xml::escape($value) . \u0027\"\u0027; // $key emitted raw\n```\n\nBecause the HTML5 tokenizer treats `\\x0C` as whitespace *between* attributes, the browser reads\nthe name as plain `onclick`.\n\n### PoC\n\n```php\n\u003c?php\nrequire \u0027vendor/autoload.php\u0027;\n\nuse League\\CommonMark\\Environment\\Environment;\nuse League\\CommonMark\\Extension\\Attributes\\AttributesExtension;\nuse League\\CommonMark\\Extension\\CommonMark\\CommonMarkCoreExtension;\nuse League\\CommonMark\\MarkdownConverter;\n\n// The most defensive configuration docs/2.x/security.md recommends.\n$env = new Environment([\n \u0027html_input\u0027 =\u003e \u0027escape\u0027,\n \u0027allow_unsafe_links\u0027 =\u003e false,\n \u0027max_nesting_level\u0027 =\u003e 100,\n // \u0027attributes\u0027 =\u003e [\u0027allow\u0027 =\u003e [...]] deliberately left at its default []\n]);\n$env-\u003eaddExtension(new CommonMarkCoreExtension());\n$env-\u003eaddExtension(new AttributesExtension());\n$converter = new MarkdownConverter($env);\n\n$FF = \"\\x0C\";\n\necho $converter-\u003econvert(\u0027hello {onclick=\"alert(1)\"}\u0027)-\u003egetContent();\n// \u003cp\u003ehello\u003c/p\u003e \u003c- filtered, as documented\n\necho $converter-\u003econvert(\u0027hello {\u0027 . $FF . \u0027onclick=\"alert(1)\"}\u0027)-\u003egetContent();\n// \u003cp \\x0Conclick=\"alert(1)\"\u003ehello\u003c/p\u003e \u003c- BYPASS\n```\n\nFull observed output (`\\x0C` shown escaped; it is a literal single byte in the real output):\n\n| # | Markdown input | Rendered output | Result |\n|---|---|---|---|\n| A | `hello {onclick=\"alert(1)\"}` | `\u003cp\u003ehello\u003c/p\u003e` | filtered (control) |\n| B | `hello {\\x0Conclick=\"alert(1)\"}` | `\u003cp \\x0Conclick=\"alert(1)\"\u003ehello\u003c/p\u003e` | **bypass** |\n| C | `hello {\\x0Bonclick=\"alert(1)\"}` | `\u003cp\u003ehello\u003c/p\u003e` | filtered (control) |\n| D | `[click](javascript:alert(1))` | `\u003cp\u003e\u003ca\u003eclick\u003c/a\u003e\u003c/p\u003e` | filtered (control) |\n| E | `[click](https://example.com){\\x0Chref=\"javascript:alert(1)\"}` | `\u003cp\u003e\u003ca \\x0Chref=\"javascript:alert(1)\" href=\"https://example.com\"\u003eclick\u003c/a\u003e\u003c/p\u003e` | **bypass** |\n| F | `{\\x0Conerror=\"alert(1)\"}` | `\u003cp\u003e\u003cimg \\x0Conerror=\"alert(1)\" src=\"\u2026\" alt=\"x\" /\u003e\u003c/p\u003e` | **bypass** |\n| G | `# heading` + newline + `{\\x0Conclick=\"alert(1)\"}` | `\u003ch1 \\x0Conclick=\"alert(1)\"\u003eheading\u003c/h1\u003e` | **bypass** (block syntax) |\n\nIn case E the injected `href` precedes the legitimate one. Per the HTML5 duplicate-attribute rule\nthe **first** occurrence wins, so the `javascript:` URI is the one the browser actually uses.\n\n**Browser confirmation.** Loading the library\u0027s unmodified output in Chrome for Testing 148:\n\n```\n\u003cimg\u003e attribute names : [\"onerror\",\"src\",\"alt\"] \u003c- parsed as a real `onerror`\ntypeof img.onerror : function \u003c- bound as an event handler\nhandlers fired : [\"img-onerror\"] \u003c- fired on load, no interaction\ndocument.title : XSS-FIRED\nlink href attribute : \"javascript:void(0)\"\nlink href property : \"javascript:void(0)\" \u003c- javascript: URI is the effective href\npage errors : []\n```\n\nThe `onerror` case executes with **no user interaction** \u2014 rendering the attacker\u0027s Markdown is\nsufficient.\n\nVerified against git HEAD (`f966b17a`) and against tag `2.9.0`, on PHP 8.5.8.\n\n### Impact\n\nStored cross-site scripting in any application that renders untrusted Markdown with\n`AttributesExtension` enabled and `attributes.allow` left at its default `[]` \u2014 even when the\napplication has followed every hardening step in `docs/2.x/security.md`\n(`html_input =\u003e \u0027escape\u0027`, `allow_unsafe_links =\u003e false`, `max_nesting_level =\u003e 100`).\n\nConsequences are the usual for stored XSS: session and cookie theft, actions performed as the\nviewing user, and account takeover where the host application permits it. Because the payload can\nbe attached to an image (`onerror`), it fires on page load without requiring the victim to\ninteract with anything.\n\nThe affected configuration is the extension\u0027s default: `attributes.allow` defaults to `[]`, and\nthe documentation describes that default as safe with respect to `on*` attributes.\n\n### Workaround for users\n\nSetting an explicit allow list takes the other branch of `filterAttributes()`, which drops the\nform-feed name because it is not in the list:\n\n```php\n$config = [\u0027attributes\u0027 =\u003e [\u0027allow\u0027 =\u003e [\u0027id\u0027, \u0027class\u0027, \u0027align\u0027]]];\n```\n\nVerified: `hello {\\x0Conclick=\"alert(1)\"}` then renders as `\u003cp\u003ehello\u003c/p\u003e`.\n\n### Suggested fix\n\nThe narrow fix is to add `\\x0C` to the trim charlist at `AttributesHelper.php` lines 62, 89, 90\nand 94. That closes this instance but leaves the shape of the problem in place.\n\nA more durable fix is to reject anything that is not a well-formed attribute name in\n`filterAttributes()`, reusing the constant the parser already defines (`RegexHelper` is already\nimported in that file):\n\n```php\nforeach ($attributes as $name =\u003e $value) {\n // Names are compared against literal strings below and emitted without escaping,\n // so anything that isn\u0027t a plain attribute name must not get through.\n if (\\preg_match(\u0027/^\u0027 . RegexHelper::PARTIAL_ATTRIBUTENAME . \u0027$/i\u0027, $name) !== 1) {\n unset($attributes[$name]);\n continue;\n }\n\n $attrNameLower = \\strtolower($name);\n // ... existing logic unchanged\n}\n```\n\nAs defence in depth, `HtmlElement::__toString()` could validate or escape `$key`. It currently\ntrusts its callers to supply safe attribute names, and `filterAttributes()` is the only thing\nstanding between that method and user-supplied input.",
"id": "GHSA-f8fg-pg57-v4j8",
"modified": "2026-09-01T20:18:29Z",
"published": "2026-09-01T20:18:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thephpleague/commonmark/security/advisories/GHSA-f8fg-pg57-v4j8"
},
{
"type": "WEB",
"url": "https://github.com/thephpleague/commonmark/commit/dfcdf4554c16aa37c15e3a5ee3243ee26147c239"
},
{
"type": "PACKAGE",
"url": "https://github.com/thephpleague/commonmark"
},
{
"type": "WEB",
"url": "https://github.com/thephpleague/commonmark/releases/tag/2.9.1"
}
],
"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": "league/commonmark XSS: `on*` event-handler filter in `AttributesExtension` bypassed with a U+000C form feed"
}
GHSA-GWWR-J6XF-QR2H
Vulnerability from github – Published: 2023-08-11 03:30 – Updated: 2023-11-03 21:30Improper neutralization in software for the Intel(R) oneVPL GPU software before version 22.6.5 may allow an authenticated user to potentially enable denial of service via local access.
{
"affected": [],
"aliases": [
"CVE-2023-22840"
],
"database_specific": {
"cwe_ids": [
"CWE-86"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-11T03:15:17Z",
"severity": "MODERATE"
},
"details": "Improper neutralization in software for the Intel(R) oneVPL GPU software before version 22.6.5 may allow an authenticated user to potentially enable denial of service via local access.",
"id": "GHSA-gwwr-j6xf-qr2h",
"modified": "2023-11-03T21:30:19Z",
"published": "2023-08-11T03:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22840"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/J7RNFPWOSFII2JE2KDRHPLJANZC3YATW"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/L27GRS7E45IOCZ44VQX2NJ33GVRBWHBS"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TULYSWHC3X76AIGGMUSLBTWOXNND6IEV"
},
{
"type": "WEB",
"url": "http://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00818.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-GX8G-PW4X-WMMV
Vulnerability from github – Published: 2026-02-09 06:30 – Updated: 2026-03-05 15:30A vulnerability has been found in FAST/TOOLS provided by Yokogawa Electric Corporation.
This product does not properly encode URLs. An attacker could tamper with web pages or execute malicious scripts.
The affected products and versions are as follows: FAST/TOOLS (Packages: RVSVRN, UNSVRN, HMIWEB, FTEES, HMIMOB) R9.01 to R10.04
{
"affected": [],
"aliases": [
"CVE-2025-66606"
],
"database_specific": {
"cwe_ids": [
"CWE-86"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-09T04:15:49Z",
"severity": "LOW"
},
"details": "A vulnerability has been found in FAST/TOOLS provided by Yokogawa Electric Corporation.\n\n\n\nThis product does not\nproperly encode URLs. An attacker could tamper with web pages or execute\nmalicious scripts.\n\n\n\nThe\naffected products and versions are as follows: FAST/TOOLS (Packages: RVSVRN, UNSVRN, HMIWEB, FTEES, HMIMOB) R9.01 to\nR10.04",
"id": "GHSA-gx8g-pw4x-wmmv",
"modified": "2026-03-05T15:30:33Z",
"published": "2026-02-09T06:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66606"
},
{
"type": "WEB",
"url": "https://web-material3.yokogawa.com/1/39206/files/YSAR-26-0001-E.pdf"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-HWMV-FPMH-92PC
Vulnerability from github – Published: 2025-01-08 18:30 – Updated: 2025-01-08 18:30A vulnerability in the web-based management interface of Cisco Common Services Platform Collector (CSPC) could allow an authenticated, remote attacker to conduct cross-site scripting (XSS) attacks against a user of the interface.
This vulnerability is due to insufficient validation of user-supplied input by the web-based management interface of an affected system. 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 must have at least a low-privileged account on an affected device. Cisco has not released software updates that address this vulnerability. There are no workarounds that address this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2025-20168"
],
"database_specific": {
"cwe_ids": [
"CWE-86"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-08T17:15:17Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web-based management interface of Cisco Common Services Platform Collector (CSPC) could allow an authenticated, remote attacker to conduct cross-site scripting (XSS) attacks against a user of the interface.\n\nThis vulnerability is due to insufficient validation of user-supplied input by the web-based management interface of an affected system. 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 must have at least a low-privileged account on an affected device.\nCisco has not released software updates that address this vulnerability. There are no workarounds that address this vulnerability.",
"id": "GHSA-hwmv-fpmh-92pc",
"modified": "2025-01-08T18:30:48Z",
"published": "2025-01-08T18:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20168"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cspc-xss-CDOJZyH"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-xwork-xss-KCcg7WwU"
}
],
"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-PV7V-PH6G-3GXV
Vulnerability from github – Published: 2023-05-09 19:59 – Updated: 2023-05-09 19:59Impact
The HTML sanitizer, introduced in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid data attributes. This can be exploited, e.g., via the link syntax in any content that supports XWiki syntax like comments in XWiki:
[[Link1>>https://XWiki.example.com||data-x/onmouseover="alert('XSS1')"]].
When a user moves the mouse over this link, the malicious JavaScript code is executed in the context of the user session. When this user is a privileged user who has programming rights, this allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance.
Note that this vulnerability does not affect restricted cleaning in HTMLCleaner as there attributes are cleaned and thus characters like / and > are removed in all attribute names.
Patches
This problem has been patched in XWiki 14.10.4 and 15.0 RC1 by making sure that data attributes only contain allowed characters.
Workarounds
There are no known workarounds apart from upgrading to a version including the fix.
References
- https://jira.xwiki.org/browse/XCOMMONS-2606
- https://github.com/xwiki/xwiki-commons/commit/0b8e9c45b7e7457043938f35265b2aa5adc76a68
For more information
If you have any questions or comments about this advisory: * Open an issue in Jira XWiki * Email us at XWiki Security mailing-list
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.commons:xwiki-commons-xml"
},
"ranges": [
{
"events": [
{
"introduced": "14.6-rc-1"
},
{
"fixed": "14.10.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-31126"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-86"
],
"github_reviewed": true,
"github_reviewed_at": "2023-05-09T19:59:31Z",
"nvd_published_at": "2023-05-09T13:15:18Z",
"severity": "CRITICAL"
},
"details": "### Impact\nThe HTML sanitizer, introduced in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid data attributes. This can be exploited, e.g., via the link syntax in any content that supports XWiki syntax like comments in XWiki: \n\n```\n[[Link1\u003e\u003ehttps://XWiki.example.com||data-x/onmouseover=\"alert(\u0027XSS1\u0027)\"]].\n```\n\nWhen a user moves the mouse over this link, the malicious JavaScript code is executed in the context of the user session. When this user is a privileged user who has programming rights, this allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance.\n\nNote that this vulnerability does not affect restricted cleaning in HTMLCleaner as there attributes are cleaned and thus characters like `/` and `\u003e` are removed in all attribute names.\n\n### Patches\nThis problem has been patched in XWiki 14.10.4 and 15.0 RC1 by making sure that data attributes only contain allowed characters.\n\n### Workarounds\nThere are no known workarounds apart from upgrading to a version including the fix.\n\n### References\n* https://jira.xwiki.org/browse/XCOMMONS-2606\n* https://github.com/xwiki/xwiki-commons/commit/0b8e9c45b7e7457043938f35265b2aa5adc76a68\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki](https://jira.xwiki.org/)\n* Email us at [XWiki Security mailing-list](mailto:security@xwiki.org)",
"id": "GHSA-pv7v-ph6g-3gxv",
"modified": "2023-05-09T19:59:31Z",
"published": "2023-05-09T19:59:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-commons/security/advisories/GHSA-pv7v-ph6g-3gxv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31126"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-commons/commit/0b8e9c45b7e7457043938f35265b2aa5adc76a68"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-commons"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XCOMMONS-2606"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Improper Neutralization of Invalid Characters in Data Attribute Names in org.xwiki.commons:xwiki-commons-xml"
}
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-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-247: XSS Using Invalid Characters
An adversary inserts invalid characters in identifiers to bypass application filtering of input. Filters may not scan beyond invalid characters but during later stages of processing content that follows these invalid characters may still be processed. This allows the adversary to sneak prohibited commands past filters and perform normally prohibited operations. Invalid characters may include null, carriage return, line feed or tab in an identifier. Successful bypassing of the filter can result in a XSS attack, resulting in the disclosure of web cookies or possibly other results.
CAPEC-73: User-Controlled Filename
An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.
CAPEC-85: AJAX Footprinting
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.