CWE-692
DiscouragedIncomplete Denylist to Cross-Site Scripting
Abstraction: Compound · Status: Draft
The product uses a denylist-based protection mechanism to defend against XSS attacks, but the denylist is incomplete, allowing XSS variants to succeed.
19 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-3J9W-8RX6-5CW3
Vulnerability from github – Published: 2026-07-17 15:32 – Updated: 2026-07-17 15:32HCL Aftermarket EPC is vulnerable to attack since HTTP OPTIONS method is enabled on this web server. The OPTIONS method provides a list of the methods that are supported by the Web server which allows an attacker to narrow and intensify their efforts.
{
"affected": [],
"aliases": [
"CVE-2024-42214"
],
"database_specific": {
"cwe_ids": [
"CWE-692"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-17T14:17:18Z",
"severity": "MODERATE"
},
"details": "HCL Aftermarket EPC is vulnerable to attack since HTTP OPTIONS method is enabled on this web server. The OPTIONS method provides a list of the methods that are supported by the Web server which allows an attacker to narrow and intensify their efforts.",
"id": "GHSA-3j9w-8rx6-5cw3",
"modified": "2026-07-17T15:32:30Z",
"published": "2026-07-17T15:32:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42214"
},
{
"type": "WEB",
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0132294"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7423-XF8W-J7HG
Vulnerability from github – Published: 2025-09-24 18:30 – Updated: 2025-09-24 18:30A vulnerability in the web UI of Cisco IOS XE Software could allow an unauthenticated, remote attacker to conduct a reflected cross-site scripting attack (XSS) on an affected device.
This vulnerability is due to improper sanitization of user-supplied input. An attacker could exploit this vulnerability by persuading a user to click a malicious link. A successful exploit could allow the attacker to execute a reflected XSS attack and steal user cookies from the affected device.
{
"affected": [],
"aliases": [
"CVE-2025-20240"
],
"database_specific": {
"cwe_ids": [
"CWE-692"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-24T18:15:34Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web UI of Cisco IOS XE Software could allow an unauthenticated, remote attacker to conduct a reflected cross-site scripting attack (XSS) on an affected device.\n\n This vulnerability is due to improper sanitization of user-supplied input. An attacker could exploit this vulnerability by persuading a user to click a malicious link. A successful exploit could allow the attacker to execute a reflected XSS attack and steal user cookies from the affected device.",
"id": "GHSA-7423-xf8w-j7hg",
"modified": "2025-09-24T18:30:31Z",
"published": "2025-09-24T18:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20240"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-webui-xss-VWyDgjOU"
}
],
"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-7GHR-CG6G-WRCG
Vulnerability from github – Published: 2026-07-17 15:32 – Updated: 2026-07-17 15:32HCL Aftermarket EPC is vulnerable to attack since the server is not configured with “X-XSS-Protection" header
{
"affected": [],
"aliases": [
"CVE-2024-23569"
],
"database_specific": {
"cwe_ids": [
"CWE-692"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-17T14:17:17Z",
"severity": "MODERATE"
},
"details": "HCL Aftermarket EPC is vulnerable to attack since the server is not configured with \u201cX-XSS-Protection\" header",
"id": "GHSA-7ghr-cg6g-wrcg",
"modified": "2026-07-17T15:32:30Z",
"published": "2026-07-17T15:32:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23569"
},
{
"type": "WEB",
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0132294"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C4WC-GGRJ-JG9V
Vulnerability from github – Published: 2026-10-08 22:09 – Updated: 2026-10-08 22:09Impact
There is a Cross-Site-Scripting vulnerability in fields that allow entering custom URLs.
Patches
You should to update to Indico 3.3.13 as soon as possible. See the docs for instructions on how to update.
Workarounds
- Set
CSP_ENABLED = Trueinindico.conf- this is recommended regardless of updating. - Only let trustworthy users manage events or create content (including material uploads which speakers can typically do as well) on Indico.
For more information
If you have any questions or comments about this advisory:
- Open a thread in our forum
- Email us privately at indico-team@cern.ch
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "indico"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.3.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107396"
],
"database_specific": {
"cwe_ids": [
"CWE-692"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T22:09:41Z",
"nvd_published_at": "2026-10-08T20:17:34Z",
"severity": "MODERATE"
},
"details": "### Impact\nThere is a Cross-Site-Scripting vulnerability in fields that allow entering custom URLs.\n\n### Patches\nYou should to update to [Indico 3.3.13](https://github.com/indico/indico/releases/tag/v3.3.13) as soon as possible.\nSee [the docs](https://docs.getindico.io/en/stable/installation/upgrade/) for instructions on how to update.\n\n### Workarounds\n- Set `CSP_ENABLED = True` in `indico.conf` - **this is recommended regardless of updating**.\n- Only let trustworthy users manage events or create content (including material uploads which speakers can typically do as well) on Indico.\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n- Open a thread in [our forum](https://talk.getindico.io/)\n- Email us privately at [indico-team@cern.ch](mailto:indico-team@cern.ch)",
"id": "GHSA-c4wc-ggrj-jg9v",
"modified": "2026-10-08T22:09:41Z",
"published": "2026-10-08T22:09:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/indico/indico/security/advisories/GHSA-c4wc-ggrj-jg9v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107396"
},
{
"type": "WEB",
"url": "https://github.com/indico/indico/pull/7619"
},
{
"type": "WEB",
"url": "https://github.com/indico/indico/commit/d4c8c7127176efa4cb53c64119ca8ee2b551be18"
},
{
"type": "PACKAGE",
"url": "https://github.com/indico/indico"
},
{
"type": "WEB",
"url": "https://github.com/indico/indico/releases/tag/v3.3.13"
}
],
"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"
}
],
"summary": "Indico: Cross-Site-Scripting in link fields"
}
GHSA-CGR4-C233-H733
Vulnerability from github – Published: 2024-11-13 18:37 – Updated: 2024-11-13 18:37Summary
A vulnerability exists in the Create User process, allowing the creation of a new admin account with an option to upload a profile image. An attacker can upload a malicious SVG file containing an embedded script. When the profile image is accessed, the embedded script executes, leading to the potential theft of session cookies.
Details
- Login as admin
- Go to Create User
- Fill up everything in the registration form then upload SVG image as a profile picture
- In SVG image, add script tag to prepare for XSS attack
- Complete the Create User process
- Right click at the image to obtain image URL address
- XSS triggered
PoC
The below link is a private YouTube video for PoC. https://youtu.be/5j8owD0--1A
Impact
The stored XSS can lead to session hijacking and privilege escalation, effectively bypassing any CSRF protections in place.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "unopim/unopim"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-52305"
],
"database_specific": {
"cwe_ids": [
"CWE-616",
"CWE-692",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-13T18:37:15Z",
"nvd_published_at": "2024-11-13T16:15:20Z",
"severity": "MODERATE"
},
"details": "### Summary\nA vulnerability exists in the Create User process, allowing the creation of a new admin account with an option to upload a profile image. An attacker can upload a malicious SVG file containing an embedded script. When the profile image is accessed, the embedded script executes, leading to the potential theft of session cookies.\n\n### Details\n1. Login as admin\n2. Go to Create User\n3. Fill up everything in the registration form then upload SVG image as a profile picture\n4. In SVG image, add script tag to prepare for XSS attack\n5. Complete the Create User process\n6. Right click at the image to obtain image URL address\n7. XSS triggered\n### PoC\nThe below link is a private YouTube video for PoC. \nhttps://youtu.be/5j8owD0--1A\n\n### Impact\nThe stored XSS can lead to session hijacking and privilege escalation, effectively bypassing any CSRF protections in place.\n",
"id": "GHSA-cgr4-c233-h733",
"modified": "2024-11-13T18:37:15Z",
"published": "2024-11-13T18:37:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/unopim/unopim/security/advisories/GHSA-cgr4-c233-h733"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52305"
},
{
"type": "WEB",
"url": "https://github.com/unopim/unopim/commit/9a0da7a0892c60f58df2351b5a9498dcb4cb8b7a"
},
{
"type": "PACKAGE",
"url": "https://github.com/unopim/unopim"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "UnoPim Stored XSS : Cookie hijacking through Create User function"
}
GHSA-H248-33JR-X3G2
Vulnerability from github – Published: 2024-04-19 00:30 – Updated: 2025-11-04 21:31Cross Site Scripting vulnerability in DerbyNet v9.0 and below allows attackers to execute arbitrary code via the checkin.php component.
{
"affected": [],
"aliases": [
"CVE-2024-30924"
],
"database_specific": {
"cwe_ids": [
"CWE-692"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-18T22:15:10Z",
"severity": "LOW"
},
"details": "Cross Site Scripting vulnerability in DerbyNet v9.0 and below allows attackers to execute arbitrary code via the checkin.php component.",
"id": "GHSA-h248-33jr-x3g2",
"modified": "2025-11-04T21:31:29Z",
"published": "2024-04-19T00:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30924"
},
{
"type": "WEB",
"url": "https://chocapikk.com/posts/2024/derbynet-vulnerabilities"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Apr/10"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-P2PF-G8CQ-3GQ5
Vulnerability from github – Published: 2023-03-01 20:37 – Updated: 2024-05-20 21:48Description
teler-waf is a Go HTTP middleware that provides teler IDS functionality to protect against web-based attacks. teler-waf prior to version v0.2.0 is vulnerable to a bypass attack when a specific case-sensitive hex entities payload with special characters such as CR/LF and horizontal tab is used. This vulnerability allows an attacker to execute arbitrary JavaScript code on the victim's browser and compromise the security of the web application.
Impact
An attacker can exploit this vulnerability to bypass common web attack threat rules in teler-waf and launch cross-site scripting (XSS) attacks. The attacker can execute arbitrary JavaScript code on the victim's browser and steal sensitive information, such as login credentials and session tokens, or take control of the victim's browser and perform malicious actions.
Patches
Version v0.2.0 includes a patch for this vulnerability.
Workarounds
We advised updating their installations to version v0.2.0 and frontwards immediately.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kitabisa/teler-waf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-26047"
],
"database_specific": {
"cwe_ids": [
"CWE-692",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-01T20:37:23Z",
"nvd_published_at": "2023-03-03T23:15:00Z",
"severity": "MODERATE"
},
"details": "### Description\n\nteler-waf is a Go HTTP middleware that provides teler IDS functionality to protect against web-based attacks. teler-waf prior to version v0.2.0 is vulnerable to a bypass attack when a specific case-sensitive hex entities payload with special characters such as CR/LF and horizontal tab is used. This vulnerability allows an attacker to execute arbitrary JavaScript code on the victim\u0027s browser and compromise the security of the web application.\n\n### Impact\n\nAn attacker can exploit this vulnerability to bypass common web attack threat rules in teler-waf and launch cross-site scripting (XSS) attacks. The attacker can execute arbitrary JavaScript code on the victim\u0027s browser and steal sensitive information, such as login credentials and session tokens, or take control of the victim\u0027s browser and perform malicious actions.\n\n### Patches\n\nVersion [v0.2.0](https://github.com/kitabisa/teler-waf/releases/tag/v0.2.0) includes a patch for this vulnerability.\n\n### Workarounds\n\nWe advised updating their installations to version v0.2.0 and frontwards immediately.",
"id": "GHSA-p2pf-g8cq-3gq5",
"modified": "2024-05-20T21:48:31Z",
"published": "2023-03-01T20:37:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kitabisa/teler-waf/security/advisories/GHSA-p2pf-g8cq-3gq5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26047"
},
{
"type": "WEB",
"url": "https://github.com/dwisiswant0/cwa-filter-rules/commit/d818d1645832d1a02cd210c7680e692d2bf4313b"
},
{
"type": "WEB",
"url": "https://github.com/kitabisa/teler-waf/commit/6e1b0e19b8adc1bbc3513a986025d4adf88d59f8"
},
{
"type": "PACKAGE",
"url": "https://github.com/kitabisa/teler-waf"
},
{
"type": "WEB",
"url": "https://github.com/kitabisa/teler-waf/compare/v0.1.2...v0.2.0"
},
{
"type": "WEB",
"url": "https://github.com/kitabisa/teler-waf/releases/tag/v0.2.0"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2023-1600"
}
],
"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": "teler-waf contains detection rule bypass via Entities payload"
}
GHSA-WJQM-G2VX-78PG
Vulnerability from github – Published: 2026-07-10 21:32 – Updated: 2026-07-10 21:32The WordPress Infinite Scroll – Ajax Load More plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 7.0.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.
{
"affected": [],
"aliases": [
"CVE-2026-15295"
],
"database_specific": {
"cwe_ids": [
"CWE-692"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-10T20:16:45Z",
"severity": "MODERATE"
},
"details": "The WordPress Infinite Scroll \u2013 Ajax Load More plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 7.0.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.",
"id": "GHSA-wjqm-g2vx-78pg",
"modified": "2026-07-10T21:32:33Z",
"published": "2026-07-10T21:32:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15295"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=3033302%40ajax-load-more%2Ftrunk\u0026old=3025859%40ajax-load-more%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/a9bbcb41-d604-45ec-a36a-4b41e8f7a508?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-120: Double Encoding
The adversary utilizes a repeating of the encoding process for a set of characters (that is, character encoding a character encoding of a character) to obfuscate the payload of a particular request. This may allow the adversary to bypass filters that attempt to detect illegal characters or strings, such as those that might be used in traversal or injection attacks. Filters may be able to catch illegal encoded strings, but may not catch doubly encoded strings. For example, a dot (.), often used in path traversal attacks and therefore often blocked by filters, could be URL encoded as %2E. However, many filters recognize this encoding and would still block the request. In a double encoding, the % in the above URL encoding would be encoded again as %25, resulting in %252E which some filters might not catch, but which could still be interpreted as a dot (.) by interpreters on the target.
CAPEC-267: Leverage Alternate Encoding
An adversary leverages the possibility to encode potentially harmful input or content used by applications such that the applications are ineffective at validating this encoding standard.
CAPEC-71: Using Unicode Encoding to Bypass Validation Logic
An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.
CAPEC-80: Using UTF-8 Encoding to Bypass Validation Logic
This attack is a specific variation on leveraging alternate encodings to bypass validation logic. This attack leverages the possibility to encode potentially harmful input in UTF-8 and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult. UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. Legal UTF-8 characters are one to four bytes long. However, early version of the UTF-8 specification got some entries wrong (in some cases it permitted overlong characters). UTF-8 encoders are supposed to use the "shortest possible" encoding, but naive decoders may accept encodings that are longer than necessary. According to the RFC 3629, a particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters.
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.