Common Weakness Enumeration

CWE-79

Allowed

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

Abstraction: Base · Status: Stable

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.

66759 vulnerabilities reference this CWE, most recent first.

GHSA-XC5X-XVCR-5H87

Vulnerability from github – Published: 2025-05-15 21:31 – Updated: 2025-05-17 06:30

Details

The Events Calendar WordPress plugin before 6.6.4 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-8493"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-15T20:15:58Z",
    "severity": "MODERATE"
  },
  "details": "The Events Calendar WordPress plugin before 6.6.4 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).",
  "id": "GHSA-xc5x-xvcr-5h87",
  "modified": "2025-05-17T06:30:26Z",
  "published": "2025-05-15T21:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8493"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/561b3185-501a-4a75-b880-226b159c0431"
    }
  ],
  "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"
    }
  ]
}

GHSA-XC66-8WC2-287H

Vulnerability from github – Published: 2022-05-17 00:26 – Updated: 2022-05-17 00:26

Details

IBM WebSphere Application Server 7.0, 8.0, 8.5, and 9.0 is vulnerable to HTTP response splitting attacks. A remote attacker could exploit this vulnerability using specially-crafted URL to cause the server to return a split response, once the URL is clicked. This would allow the attacker to perform further attacks, such as Web cache poisoning, cross-site scripting, and possibly obtain sensitive information. IBM X-Force ID: 129578.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-1503"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-10-10T21:29:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM WebSphere Application Server 7.0, 8.0, 8.5, and 9.0 is vulnerable to HTTP response splitting attacks. A remote attacker could exploit this vulnerability using specially-crafted URL to cause the server to return a split response, once the URL is clicked. This would allow the attacker to perform further attacks, such as Web cache poisoning, cross-site scripting, and possibly obtain sensitive information. IBM X-Force ID: 129578.",
  "id": "GHSA-xc66-8wc2-287h",
  "modified": "2022-05-17T00:26:26Z",
  "published": "2022-05-17T00:26:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1503"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/129578"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg22006815"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101234"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1039521"
    }
  ],
  "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-XC6C-MH6C-56HR

Vulnerability from github – Published: 2022-05-17 01:45 – Updated: 2022-05-17 01:45

Details

Cross-site scripting (XSS) vulnerability in the ThreeWP Email Reflector plugin before 1.16 for WordPress allows remote attackers to inject arbitrary web script or HTML via the Subject of an email.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2012-2572"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-06-19T14:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Cross-site scripting (XSS) vulnerability in the ThreeWP Email Reflector plugin before 1.16 for WordPress allows remote attackers to inject arbitrary web script or HTML via the Subject of an email.",
  "id": "GHSA-xc6c-mh6c-56hr",
  "modified": "2022-05-17T01:45:48Z",
  "published": "2022-05-17T01:45:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-2572"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/77502"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/show/osvdb/85134"
    },
    {
      "type": "WEB",
      "url": "http://wordpress.org/plugins/threewp-email-reflector/changelog"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/20365"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/54903"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XC6G-GGRC-QQ4R

Vulnerability from github – Published: 2018-11-09 17:47 – Updated: 2023-09-08 23:04

Summary

Cross-Site Scripting in sanitize-html

Details

Affected versions of sanitize-html are vulnerable to cross-site scripting when allowedTags includes at least one nonTextTag.

Proof of Concept

var sanitizeHtml = require('sanitize-html');

var dirty = '!<textarea>&lt;/textarea&gt;<svg/onload=prompt`xs`&gt;</textarea>!';
var clean = sanitizeHtml(dirty, {
    allowedTags: [ 'textarea' ]
});

console.log(clean);

// !<textarea></textarea><svg/onload=prompt`xs`></textarea>!

Recommendation

Update to version 1.11.4 or later.

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.11.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "sanitize-html"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-16016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T22:02:52Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Affected versions of `sanitize-html` are vulnerable to cross-site scripting when allowedTags includes at least one `nonTextTag`.\n\n## Proof of Concept\n\n```js\nvar sanitizeHtml = require(\u0027sanitize-html\u0027);\n\nvar dirty = \u0027!\u003ctextarea\u003e\u0026lt;/textarea\u0026gt;\u003csvg/onload=prompt`xs`\u0026gt;\u003c/textarea\u003e!\u0027;\nvar clean = sanitizeHtml(dirty, {\n    allowedTags: [ \u0027textarea\u0027 ]\n});\n\nconsole.log(clean);\n\n// !\u003ctextarea\u003e\u003c/textarea\u003e\u003csvg/onload=prompt`xs`\u003e\u003c/textarea\u003e!\n```\n\n\n## Recommendation\n\nUpdate to version 1.11.4 or later.",
  "id": "GHSA-xc6g-ggrc-qq4r",
  "modified": "2023-09-08T23:04:54Z",
  "published": "2018-11-09T17:47:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16016"
    },
    {
      "type": "WEB",
      "url": "https://github.com/punkave/sanitize-html/issues/100"
    },
    {
      "type": "WEB",
      "url": "https://github.com/punkave/sanitize-html/commit/5d205a1005ba0df80e21d8c64a15bb3accdb2403"
    },
    {
      "type": "WEB",
      "url": "https://github.com/punkave/sanitize-html/commit/5d205a1005ba0df80e21d8c64a15bb3accdb2403)))"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-xc6g-ggrc-qq4r"
    },
    {
      "type": "WEB",
      "url": "https://npmjs.com/package/sanitize-html#discarding-the-entire-contents-of-a-disallowed-tag"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/154"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Cross-Site Scripting in sanitize-html"
}

GHSA-XC6R-XW3R-WM8F

Vulnerability from github – Published: 2022-05-14 02:48 – Updated: 2022-05-14 02:48

Details

Multiple cross-site scripting (XSS) vulnerabilities in macIpSpoofView.html in Dell SonicWall SonicOS 7.5.0.12 and 6.x allow remote attackers to inject arbitrary web script or HTML via the (1) searchSpoof or (2) searchSpoofIpDet parameter.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2015-3447"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2015-04-29T20:59:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple cross-site scripting (XSS) vulnerabilities in macIpSpoofView.html in Dell SonicWall SonicOS 7.5.0.12 and 6.x allow remote attackers to inject arbitrary web script or HTML via the (1) searchSpoof or (2) searchSpoofIpDet parameter.",
  "id": "GHSA-xc6r-xw3r-wm8f",
  "modified": "2022-05-14T02:48:48Z",
  "published": "2022-05-14T02:48:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-3447"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2015/Apr/97"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/535393/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/74406"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1032204"
    },
    {
      "type": "WEB",
      "url": "http://www.vulnerability-lab.com/get_content.php?id=1359"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XC72-G7RW-977P

Vulnerability from github – Published: 2023-05-08 15:30 – Updated: 2024-04-04 03:50

Details

The Custom Post Type List Shortcode WordPress plugin through 1.4.4 does not validate and escape some of its shortcode attributes before outputting them back in a page/post where the shortcode is embed, which could allow users with the contributor role and above to perform Stored Cross-Site Scripting attacks.

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-0542"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-08T14:15:11Z",
    "severity": "MODERATE"
  },
  "details": "The Custom Post Type List Shortcode WordPress plugin through 1.4.4 does not validate and escape some of its shortcode attributes before outputting them back in a page/post where the shortcode is embed, which could allow users with the contributor role and above to perform Stored Cross-Site Scripting attacks.",
  "id": "GHSA-xc72-g7rw-977p",
  "modified": "2024-04-04T03:50:47Z",
  "published": "2023-05-08T15:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0542"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/17de2f77-3e6c-4c22-9196-6e5577ee7fcf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XC7J-3G8Q-9VH4

Vulnerability from github – Published: 2026-07-09 21:00 – Updated: 2026-07-09 21:00

Summary

YesWiki has stored XSS in Bazar form-field templates via unescaped field.label / field.hint (|raw('html'))

Details

Bazar form-field templates still apply `|raw('html')` to `field.label` / `field.hint` in attribute and label-body contexts — stored XSS in form renders (sibling class of commit `e6b66aa`)

CWE: CWE-79 (Improper Neutralization of Input During Web Page Generation, "Cross-site Scripting") via CWE-116 (Improper Encoding or Escaping of Output) — same class as the partial fix at commit e6b66aa

CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N → 4.7 (Medium)

(Privileges Required = High because writing the field definitions requires saisie_formulaire, which tools/bazar/services/Guard.php:58-61 grants only to admins by default; Scope = Changed because the XSS payload set by a form-editor admin executes in the origin context of arbitrary viewers, including unauthenticated visitors.)

Summary

Commit e6b66aa ("fix(bazar): leave the twig escape placeholder as is", 2026-05-19) recognised that emitting field.label through Twig's raw('html') filter into an HTML attribute is unsafe — Twig's raw marker suppresses the attribute auto-escape, striptags removes <…> tags but not ", so a label containing " can break out of the attribute and inject event-handler attributes. The commit fixed tools/bazar/templates/inputs/text.twig:19 and tools/bazar/templates/inputs/textarea.twig:3.

At least seven additional templates have the same pattern and were not touched by the fix:

tools/bazar/templates/inputs/range.twig:19 — placeholder="{{ field.label|raw('html')|striptags }}"
tools/bazar/templates/inputs/email.twig:13 — placeholder="{{ field.label|raw('html')|striptags }}"
tools/bazar/templates/layouts/input.twig:7 — title="{{ field.hint|raw('html') }}" alt="{{ field.hint|raw('html') }}"
tools/bazar/templates/inputs/textarea.twig:14 — same title=/alt= pattern (the commit only fixed line 3, line 14 remains)
tools/bazar/templates/inputs/user.twig:41, 55 — same
tools/bazar/templates/inputs/bookmarklet.twig:4 — same
tools/bazar/templates/layouts/input.twig:9, tools/bazar/templates/layouts/field.twig:5, tools/bazar/templates/inputs/subscribe.twig:16, tools/bazar/templates/inputs/linked-entry.twig:4, tools/bazar/templates/inputs/textarea.twig:16, tools/bazar/templates/inputs/bookmarklet.twig:6 — {{ field.label|raw }} outside an attribute (label-body), with no striptags at all, so direct tag injection (<img src=x onerror=…>) executes

The layouts/input.twig and layouts/field.twig files are base layouts inherited by every Bazar field type, so a single malicious field.hint reaches into every form that uses that field.

Affected

YesWiki doryphore at HEAD 6c653dd (the audit checkout)
All releases that ship the listed templates with the |raw('html') / |raw filter in attribute or label-body context

Vulnerability details

[A] — Source: `field.label` and `field.hint` are populated from form definitions

tools/bazar/fields/BazarField.php:46-53:

$this->label = empty($values[self::FIELD_LABEL]) ? '' : html_entity_decode($values[self::FIELD_LABEL]);
$this->size = $values[self::FIELD_SIZE];
$this->maxChars = $values[self::FIELD_MAX_CHARS];
$this->default = $values[self::FIELD_DEFAULT];
$this->required = $values[self::FIELD_REQUIRED] == 1;
$this->searchable = $values[self::FIELD_SEARCHABLE];
$this->hint = $values[self::FIELD_HINT];                       // [A] no decoding/escaping

field.label is html_entity_decode($values[FIELD_LABEL]) — the decode actively turns HTML-entity-encoded payloads (", ") back into raw ", defeating any entity-encoded mitigation a form author might apply. field.hint is the raw string from the form definition. Both flow into the field's __toString-like context unchanged. Form definitions are written by users with the saisie_formulaire ACL (tools/bazar/services/Guard.php:45-62 — admins by default; the same ACL the audit team chose to gate imported-form POST handling under in commit fe7244b).

[B] — Sink class 1: attribute-context `|raw('html')|striptags` (placeholder breakout)

tools/bazar/templates/inputs/range.twig:19:

placeholder="{{ field.label|raw('html')|striptags }}"

tools/bazar/templates/inputs/email.twig:13:

placeholder="{{ field.label|raw('html')|striptags }}"

raw('html') marks the value as a Markup object, which causes Twig's HTML auto-escaper to skip it (Twig\Markup::__toString). striptags removes <…> sequences but does not touch ", ', or =. A field.label of:

hi" onmouseover="alert(document.cookie)" x="

passes striptags unchanged, is marked safe by raw('html'), and lands inside the attribute as:

placeholder="hi" onmouseover="alert(document.cookie)" x=""

The injected onmouseover fires when a viewer hovers the input. Same vector as the pre-fix text.twig:19.

[C] — Sink class 2: attribute-context `|raw('html')` without `striptags` (worse)

tools/bazar/templates/layouts/input.twig:7:

{% if field.hint %}
    <img loading="lazy" class="tooltip_aide" title="{{ field.hint|raw('html') }}" alt="{{ field.hint|raw('html') }}" src="tools/bazar/presentation/images/aide.png" width="16" height="16" />
{% endif %}

Identical patterns in tools/bazar/templates/inputs/textarea.twig:14, tools/bazar/templates/inputs/user.twig:41, tools/bazar/templates/inputs/user.twig:55, tools/bazar/templates/inputs/bookmarklet.twig:4.

There is no striptags here at all, so the attacker has the full attribute-injection alphabet plus full HTML if the parser desynchronises. Setting field.hint = '"><script>alert(1)</script>' gives:

<img … title=""><script>alert(1)</script>" alt="…" …

The <script> runs at page parse time. Because layouts/input.twig is extended by every field-type template, a single malicious field.hint on any field in any form propagates into every form render.

[D] — Sink class 3: label-body `|raw` (direct DOM injection)

tools/bazar/templates/layouts/input.twig:9:

{{ field.label|raw }}

tools/bazar/templates/layouts/field.twig:5:

{%- block label -%}{{ field.label|raw }}{%- endblock -%}

Plus subscribe.twig:16, linked-entry.twig:4, textarea.twig:16, bookmarklet.twig:6.

These are outside any attribute, in the body of a <label> element. raw suppresses escaping, there is no striptags. field.label = '<img src=x onerror=alert(1)>' injects an <img> tag straight into the label DOM; the onerror fires the moment the page renders, with no user interaction.

Why the fix at `e6b66aa` is incomplete

The fix correctly replaced field.label | raw('html') | striptags with field.label | striptags | trim (no raw) in text.twig's placeholder and textarea.twig's textarea placeholder. The fix is the right pattern — drop the raw so Twig's attribute-context autoescaper does its job — but it was applied at two specific call sites instead of being treated as a class-wide replacement. The siblings above use the same |raw('html')|striptags or |raw('html') idiom and are all currently exploitable.

Proof of concept

Setup

Install YesWiki and log in as admin (or as any user with the saisie_formulaire ACL).
Navigate to Bazar → Formulaires → Nouveau formulaire and create a form. Add any field of type range, email, or any other field type (every field type renders through layouts/input.twig, so the title= / alt= / label-body vectors apply universally).

PoC 1 — `range.twig` placeholder attribute breakout (Sink class [B])

Set the field's label to:

Enter value" onmouseover="alert('XSS via field.label in range.twig')" x="

Save the form. Have any visitor (including unauthenticated guests if the form is published) open a page that renders the form. Hovering the range input fires the injected handler.

Rendered HTML:

<input type="range" … placeholder="Enter value" onmouseover="alert('XSS via field.label in range.twig')" x="" required />

PoC 2 — `layouts/input.twig` tooltip injection (Sink class [C])

Set the field's hint (Aide) to:

"><script>alert('XSS via field.hint in layouts/input.twig — fires on EVERY field type')</script><span x="

Save. Any page that renders the form executes the script at parse time, before any user interaction. The vector is universal because layouts/input.twig is the base template extended by every field type.

PoC 3 — `layouts/input.twig` label-body injection (Sink class [D])

Set the field's label to:

<img src=x onerror="alert('XSS via field.label in layouts/input.twig')">

Save. Page render fires the onerror immediately — no hover, no click, no striptags filter in the way.

Impact

Direct

Stored XSS on every visitor of any Bazar form page — a privileged form editor injects script into a field's label/hint and the script runs in the wiki origin against every viewer of the form, including unauthenticated guests. Cookie theft, session hijack of any admin who visits, full content modification, phishing overlays.
Universal sink in layouts/input.twig — sinks [C] and [D] live in the base layout extended by every field type, so a single field with a malicious hint poisons every form render across the wiki, not just forms using a specific input type.

Indirect / second-order

Privilege amplification despite saisie_formulaire being admin-only by default — many deployments grant saisie_formulaire to specific user groups (per-deployment ACL configured via config['permissions']['action']['saisie_formulaire']). For those deployments, the bug is exploitable by any user in those groups against any visitor. The audit pattern at commit fe7244b (the same team explicitly gated imported-form POST handling on saisie_formulaire) demonstrates that saisie_formulaire is in fact a "trusted-input" boundary — outputs of that boundary should not assume HTML-safety.
Composability with the unpatched POI/CSRF in BazarImportAction (reported separately as 01-bazarimport-poi-csrf.md) — once any XSS exists in the wiki origin, an attacker can fetch a CSRF token (if added as part of the POI fix) and chain XSS → POI → RCE without needing to phish the admin onto a third-party origin.
The pre-fe7244b window — for any deployment still running a build that predates fe7244b (the imported-form auth fix from 2026-05-12), the source of field.label / field.hint was reachable from unauthenticated POST to the imported-form handler, making this finding unauth-stored-XSS on those builds. The current code path closes that source side, but reinforces that the sink-side fix at e6b66aa should be applied class-wide.

Suggested fix

Apply the same transformation e6b66aa applied to text.twig / textarea.twig placeholders, class-wide:

For attribute contexts (placeholder=, title=, alt=, etc.) — drop the raw filter. Let Twig's attribute-context autoescape handle the value:

twig placeholder="{{ field.label|striptags|trim }}" title="{{ field.hint|striptags|trim }}" alt="{{ field.hint|striptags|trim }}"

striptags is fine to keep if there's a UX reason to strip incidental HTML; the security is in the absence of raw.

For label-body contexts (<label>{{ field.label|raw }}</label>) — decide which is the design intent and apply it everywhere:
If labels really need to render bold/italic/links: pass field.label through HtmlPurifierService::cleanHTML() at the point where the field object is constructed (i.e. BazarField::__construct's $this->label = … line), so any subsequent template emits already-purified HTML and raw becomes safe.
If labels are plain text: drop the raw filter and let {{ field.label }} autoescape.

The label-body case in layouts/input.twig:9, layouts/field.twig:5, and the four inputs/*.twig files is the highest-impact patch target because it's reached by every field type; the attribute-context cases are more surgical.

Sweep target list (all in tools/bazar/templates/):

inputs/range.twig:19
inputs/email.twig:13
layouts/input.twig:7, 9
layouts/field.twig:5
inputs/textarea.twig:14, 16
inputs/user.twig:41, 55
inputs/bookmarklet.twig:4, 6
inputs/subscribe.twig:16
inputs/linked-entry.twig:4

A grep-driven CI check for |raw('html') and |raw inside Bazar twig templates would surface any future reintroduction.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "yeswiki/yeswiki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.6.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52772"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T21:00:33Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# Bazar form-field templates still apply `|raw(\u0027html\u0027)` to `field.label` / `field.hint` in attribute and label-body contexts \u2014 stored XSS in form renders (sibling class of commit `e6b66aa`)\n\n**CWE**: CWE-79 (Improper Neutralization of Input During Web Page Generation, \"Cross-site Scripting\") via CWE-116 (Improper Encoding or Escaping of Output) \u2014 same class as the partial fix at commit `e6b66aa`\n\n**CVSS v3.1**: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N` \u2192 4.7 (Medium)\n\n(Privileges Required = High because writing the field definitions requires `saisie_formulaire`, which `tools/bazar/services/Guard.php:58-61` grants only to admins by default; Scope = Changed because the XSS payload set by a form-editor admin executes in the origin context of arbitrary viewers, including unauthenticated visitors.)\n\n## Summary\n\nCommit `e6b66aa` (\"fix(bazar): leave the twig escape placeholder as is\", 2026-05-19) recognised that emitting `field.label` through Twig\u0027s `raw(\u0027html\u0027)` filter into an HTML attribute is unsafe \u2014 Twig\u0027s `raw` marker suppresses the attribute auto-escape, `striptags` removes `\u003c\u2026\u003e` tags but not `\"`, so a label containing `\"` can break out of the attribute and inject event-handler attributes. The commit fixed `tools/bazar/templates/inputs/text.twig:19` and `tools/bazar/templates/inputs/textarea.twig:3`.\n\nAt least seven additional templates have the same pattern and were not touched by the fix:\n\n- `tools/bazar/templates/inputs/range.twig:19` \u2014 `placeholder=\"{{ field.label|raw(\u0027html\u0027)|striptags }}\"`\n- `tools/bazar/templates/inputs/email.twig:13` \u2014 `placeholder=\"{{ field.label|raw(\u0027html\u0027)|striptags }}\"`\n- `tools/bazar/templates/layouts/input.twig:7` \u2014 `title=\"{{ field.hint|raw(\u0027html\u0027) }}\" alt=\"{{ field.hint|raw(\u0027html\u0027) }}\"`\n- `tools/bazar/templates/inputs/textarea.twig:14` \u2014 same `title=`/`alt=` pattern (the commit only fixed line 3, line 14 remains)\n- `tools/bazar/templates/inputs/user.twig:41, 55` \u2014 same\n- `tools/bazar/templates/inputs/bookmarklet.twig:4` \u2014 same\n- `tools/bazar/templates/layouts/input.twig:9`, `tools/bazar/templates/layouts/field.twig:5`, `tools/bazar/templates/inputs/subscribe.twig:16`, `tools/bazar/templates/inputs/linked-entry.twig:4`, `tools/bazar/templates/inputs/textarea.twig:16`, `tools/bazar/templates/inputs/bookmarklet.twig:6` \u2014 `{{ field.label|raw }}` *outside* an attribute (label-body), with no `striptags` at all, so direct tag injection (`\u003cimg src=x onerror=\u2026\u003e`) executes\n\nThe `layouts/input.twig` and `layouts/field.twig` files are base layouts inherited by **every** Bazar field type, so a single malicious `field.hint` reaches into every form that uses that field.\n\n## Affected\n\n- YesWiki `doryphore` at HEAD `6c653dd` (the audit checkout)\n- All releases that ship the listed templates with the `|raw(\u0027html\u0027)` / `|raw` filter in attribute or label-body context\n\n## Vulnerability details\n\n### [A] \u2014 Source: `field.label` and `field.hint` are populated from form definitions\n\n`tools/bazar/fields/BazarField.php:46-53`:\n\n```php\n$this-\u003elabel = empty($values[self::FIELD_LABEL]) ? \u0027\u0027 : html_entity_decode($values[self::FIELD_LABEL]);\n$this-\u003esize = $values[self::FIELD_SIZE];\n$this-\u003emaxChars = $values[self::FIELD_MAX_CHARS];\n$this-\u003edefault = $values[self::FIELD_DEFAULT];\n$this-\u003erequired = $values[self::FIELD_REQUIRED] == 1;\n$this-\u003esearchable = $values[self::FIELD_SEARCHABLE];\n$this-\u003ehint = $values[self::FIELD_HINT];                       // [A] no decoding/escaping\n```\n\n`field.label` is `html_entity_decode($values[FIELD_LABEL])` \u2014 the decode actively *turns* HTML-entity-encoded payloads (`\u0026quot;`, `\u0026#34;`) back into raw `\"`, defeating any entity-encoded mitigation a form author might apply. `field.hint` is the raw string from the form definition. Both flow into the field\u0027s `__toString`-like context unchanged. Form definitions are written by users with the `saisie_formulaire` ACL (`tools/bazar/services/Guard.php:45-62` \u2014 admins by default; the same ACL the audit team chose to gate `imported-form` POST handling under in commit `fe7244b`).\n\n### [B] \u2014 Sink class 1: attribute-context `|raw(\u0027html\u0027)|striptags` (placeholder breakout)\n\n`tools/bazar/templates/inputs/range.twig:19`:\n\n```twig\nplaceholder=\"{{ field.label|raw(\u0027html\u0027)|striptags }}\"\n```\n\n`tools/bazar/templates/inputs/email.twig:13`:\n\n```twig\nplaceholder=\"{{ field.label|raw(\u0027html\u0027)|striptags }}\"\n```\n\n`raw(\u0027html\u0027)` marks the value as a `Markup` object, which causes Twig\u0027s HTML auto-escaper to skip it (`Twig\\Markup::__toString`). `striptags` removes `\u003c\u2026\u003e` sequences but does not touch `\"`, `\u0027`, or `=`. A `field.label` of:\n\n```\nhi\" onmouseover=\"alert(document.cookie)\" x=\"\n```\n\npasses `striptags` unchanged, is marked safe by `raw(\u0027html\u0027)`, and lands inside the attribute as:\n\n```html\nplaceholder=\"hi\" onmouseover=\"alert(document.cookie)\" x=\"\"\n```\n\nThe injected `onmouseover` fires when a viewer hovers the input. Same vector as the pre-fix `text.twig:19`.\n\n### [C] \u2014 Sink class 2: attribute-context `|raw(\u0027html\u0027)` *without* `striptags` (worse)\n\n`tools/bazar/templates/layouts/input.twig:7`:\n\n```twig\n{% if field.hint %}\n    \u003cimg loading=\"lazy\" class=\"tooltip_aide\" title=\"{{ field.hint|raw(\u0027html\u0027) }}\" alt=\"{{ field.hint|raw(\u0027html\u0027) }}\" src=\"tools/bazar/presentation/images/aide.png\" width=\"16\" height=\"16\" /\u003e\n{% endif %}\n```\n\nIdentical patterns in `tools/bazar/templates/inputs/textarea.twig:14`, `tools/bazar/templates/inputs/user.twig:41`, `tools/bazar/templates/inputs/user.twig:55`, `tools/bazar/templates/inputs/bookmarklet.twig:4`.\n\nThere is no `striptags` here at all, so the attacker has the full attribute-injection alphabet plus full HTML if the parser desynchronises. Setting `field.hint = \u0027\"\u003e\u003cscript\u003ealert(1)\u003c/script\u003e\u0027` gives:\n\n```html\n\u003cimg \u2026 title=\"\"\u003e\u003cscript\u003ealert(1)\u003c/script\u003e\" alt=\"\u2026\" \u2026\n```\n\nThe `\u003cscript\u003e` runs at page parse time. Because `layouts/input.twig` is extended by **every** field-type template, a single malicious `field.hint` on any field in any form propagates into every form render.\n\n### [D] \u2014 Sink class 3: label-body `|raw` (direct DOM injection)\n\n`tools/bazar/templates/layouts/input.twig:9`:\n\n```twig\n{{ field.label|raw }}\n```\n\n`tools/bazar/templates/layouts/field.twig:5`:\n\n```twig\n{%- block label -%}{{ field.label|raw }}{%- endblock -%}\n```\n\nPlus `subscribe.twig:16`, `linked-entry.twig:4`, `textarea.twig:16`, `bookmarklet.twig:6`.\n\nThese are outside any attribute, in the body of a `\u003clabel\u003e` element. `raw` suppresses escaping, there is no `striptags`. `field.label = \u0027\u003cimg src=x onerror=alert(1)\u003e\u0027` injects an `\u003cimg\u003e` tag straight into the label DOM; the `onerror` fires the moment the page renders, with no user interaction.\n\n### Why the fix at `e6b66aa` is incomplete\n\nThe fix correctly replaced `field.label | raw(\u0027html\u0027) | striptags` with `field.label | striptags | trim` (no `raw`) in `text.twig`\u0027s placeholder and `textarea.twig`\u0027s textarea placeholder. The fix is the right pattern \u2014 drop the `raw` so Twig\u0027s attribute-context autoescaper does its job \u2014 but it was applied at two specific call sites instead of being treated as a class-wide replacement. The siblings above use the same `|raw(\u0027html\u0027)|striptags` or `|raw(\u0027html\u0027)` idiom and are all currently exploitable.\n\n## Proof of concept\n\n### Setup\n\n1. Install YesWiki and log in as admin (or as any user with the `saisie_formulaire` ACL).\n2. Navigate to *Bazar \u2192 Formulaires \u2192 Nouveau formulaire* and create a form. Add any field of type `range`, `email`, or any other field type (every field type renders through `layouts/input.twig`, so the `title=` / `alt=` / label-body vectors apply universally).\n\n### PoC 1 \u2014 `range.twig` placeholder attribute breakout (Sink class [B])\n\nSet the field\u0027s label to:\n\n```\nEnter value\" onmouseover=\"alert(\u0027XSS via field.label in range.twig\u0027)\" x=\"\n```\n\nSave the form. Have any visitor (including unauthenticated guests if the form is published) open a page that renders the form. Hovering the range input fires the injected handler.\n\nRendered HTML:\n\n```html\n\u003cinput type=\"range\" \u2026 placeholder=\"Enter value\" onmouseover=\"alert(\u0027XSS via field.label in range.twig\u0027)\" x=\"\" required /\u003e\n```\n\n### PoC 2 \u2014 `layouts/input.twig` tooltip injection (Sink class [C])\n\nSet the field\u0027s `hint` (Aide) to:\n\n```\n\"\u003e\u003cscript\u003ealert(\u0027XSS via field.hint in layouts/input.twig \u2014 fires on EVERY field type\u0027)\u003c/script\u003e\u003cspan x=\"\n```\n\nSave. Any page that renders the form executes the script at parse time, before any user interaction. The vector is universal because `layouts/input.twig` is the base template extended by every field type.\n\n### PoC 3 \u2014 `layouts/input.twig` label-body injection (Sink class [D])\n\nSet the field\u0027s label to:\n\n```\n\u003cimg src=x onerror=\"alert(\u0027XSS via field.label in layouts/input.twig\u0027)\"\u003e\n```\n\nSave. Page render fires the `onerror` immediately \u2014 no hover, no click, no `striptags` filter in the way.\n\n## Impact\n\n### Direct\n\n- **Stored XSS on every visitor of any Bazar form page** \u2014 a privileged form editor injects script into a field\u0027s label/hint and the script runs in the wiki origin against every viewer of the form, including unauthenticated guests. Cookie theft, session hijack of any admin who visits, full content modification, phishing overlays.\n- **Universal sink in `layouts/input.twig`** \u2014 sinks [C] and [D] live in the base layout extended by every field type, so a single field with a malicious hint poisons every form render across the wiki, not just forms using a specific input type.\n\n### Indirect / second-order\n\n- **Privilege amplification despite `saisie_formulaire` being admin-only by default** \u2014 many deployments grant `saisie_formulaire` to specific user groups (per-deployment ACL configured via `config[\u0027permissions\u0027][\u0027action\u0027][\u0027saisie_formulaire\u0027]`). For those deployments, the bug is exploitable by any user in those groups against any visitor. The audit pattern at commit `fe7244b` (the same team explicitly gated `imported-form` POST handling on `saisie_formulaire`) demonstrates that `saisie_formulaire` is in fact a \"trusted-input\" boundary \u2014 outputs of that boundary should not assume HTML-safety.\n- **Composability with the unpatched POI/CSRF in `BazarImportAction` (reported separately as `01-bazarimport-poi-csrf.md`)** \u2014 once any XSS exists in the wiki origin, an attacker can fetch a CSRF token (if added as part of the POI fix) and chain XSS \u2192 POI \u2192 RCE without needing to phish the admin onto a third-party origin.\n- **The pre-`fe7244b` window** \u2014 for any deployment still running a build that predates `fe7244b` (the `imported-form` auth fix from 2026-05-12), the source of `field.label` / `field.hint` was reachable from **unauthenticated** POST to the `imported-form` handler, making this finding unauth-stored-XSS on those builds. The current code path closes that source side, but reinforces that the sink-side fix at `e6b66aa` should be applied class-wide.\n\n## Suggested fix\n\nApply the same transformation `e6b66aa` applied to `text.twig` / `textarea.twig` placeholders, class-wide:\n\n- For attribute contexts (`placeholder=`, `title=`, `alt=`, etc.) \u2014 drop the `raw` filter. Let Twig\u0027s attribute-context autoescape handle the value:\n\n  ```twig\n  placeholder=\"{{ field.label|striptags|trim }}\"\n  title=\"{{ field.hint|striptags|trim }}\"\n  alt=\"{{ field.hint|striptags|trim }}\"\n  ```\n\n  `striptags` is fine to keep if there\u0027s a UX reason to strip incidental HTML; the security is in the absence of `raw`.\n\n- For label-body contexts (`\u003clabel\u003e{{ field.label|raw }}\u003c/label\u003e`) \u2014 decide which is the design intent and apply it everywhere:\n  - If labels really need to render bold/italic/links: pass `field.label` through `HtmlPurifierService::cleanHTML()` at the point where the field object is constructed (i.e. `BazarField::__construct`\u0027s `$this-\u003elabel = \u2026` line), so any subsequent template emits already-purified HTML and `raw` becomes safe.\n  - If labels are plain text: drop the `raw` filter and let `{{ field.label }}` autoescape.\n\nThe label-body case in `layouts/input.twig:9`, `layouts/field.twig:5`, and the four `inputs/*.twig` files is the highest-impact patch target because it\u0027s reached by every field type; the attribute-context cases are more surgical.\n\nSweep target list (all in `tools/bazar/templates/`):\n\n- `inputs/range.twig:19`\n- `inputs/email.twig:13`\n- `layouts/input.twig:7, 9`\n- `layouts/field.twig:5`\n- `inputs/textarea.twig:14, 16`\n- `inputs/user.twig:41, 55`\n- `inputs/bookmarklet.twig:4, 6`\n- `inputs/subscribe.twig:16`\n- `inputs/linked-entry.twig:4`\n\nA grep-driven CI check for `|raw(\u0027html\u0027)` and `|raw` inside Bazar twig templates would surface any future reintroduction.",
  "id": "GHSA-xc7j-3g8q-9vh4",
  "modified": "2026-07-09T21:00:33Z",
  "published": "2026-07-09T21:00:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/YesWiki/yeswiki/security/advisories/GHSA-xc7j-3g8q-9vh4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/YesWiki/yeswiki/commit/5d1a4d07fecb0706f33e5dfbbe6ff5ef1892b2a7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/YesWiki/yeswiki"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "YesWiki has stored XSS in Bazar form-field templates via unescaped field.label / field.hint (|raw(\u0027html\u0027))"
}

GHSA-XC7Q-Q62F-WCVR

Vulnerability from github – Published: 2022-05-17 04:58 – Updated: 2023-08-29 18:50

Summary

Apache Solr for TYPO3 (solr) extension is vulnerable to Cross-site scripting (XSS)

Details

Cross-site scripting (XSS) vulnerability in the Apache Solr for TYPO3 (solr) extension before 2.8.3 for TYPO3 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "apache-solr-for-typo3/solr"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2013-6289"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-29T18:50:33Z",
    "nvd_published_at": "2013-10-28T22:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Cross-site scripting (XSS) vulnerability in the Apache Solr for TYPO3 (solr) extension before 2.8.3 for TYPO3 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors.",
  "id": "GHSA-xc7q-q62f-wcvr",
  "modified": "2023-08-29T18:50:33Z",
  "published": "2022-05-17T04:58:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-6289"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3-Solr/ext-solr/commit/57e3b06b498668e093b9b86f32f7509d12d6ae4e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3-Solr/ext-solr/commit/7ed1e9fc03f2036d80a416178493da72c620f7e9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/TYPO3-Solr/ext-solr"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/54978"
    },
    {
      "type": "WEB",
      "url": "http://typo3.org/extensions/repository/view/solr"
    },
    {
      "type": "WEB",
      "url": "http://typo3.org/teams/security/security-bulletins/typo3-extensions/typo3-ext-sa-2013-009"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/62674"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Solr for TYPO3 (solr) extension is vulnerable to Cross-site scripting (XSS)"
}

GHSA-XC7V-9M4Q-8Q68

Vulnerability from github – Published: 2024-01-24 18:31 – Updated: 2024-01-30 21:30

Details

Kanboard 1.2.34 is vulnerable to Html Injection in the group management feature.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-22720"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-24T18:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Kanboard 1.2.34 is vulnerable to Html Injection in the group management feature.",
  "id": "GHSA-xc7v-9m4q-8q68",
  "modified": "2024-01-30T21:30:29Z",
  "published": "2024-01-24T18:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22720"
    },
    {
      "type": "WEB",
      "url": "https://cupc4k3.medium.com/html-injection-vulnerability-in-kanboard-group-management-d9fe5154bb1b"
    }
  ],
  "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"
    }
  ]
}

GHSA-XC7W-HCQX-Q2X3

Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2024-04-04 05:38

Details

Auth. (admin+) Stored Cross-Site Scripting (XSS) vulnerability in Oliver Schlöbe Simple Yearly Archive plugin <= 2.1.8 versions.

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-25484"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-25T17:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Auth. (admin+) Stored Cross-Site Scripting (XSS) vulnerability in Oliver Schl\u00f6be Simple Yearly Archive plugin \u003c=\u00a02.1.8 versions.",
  "id": "GHSA-xc7w-hcqx-q2x3",
  "modified": "2024-04-04T05:38:08Z",
  "published": "2023-07-06T19:24:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25484"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/simple-yearly-archive/wordpress-simple-yearly-archive-plugin-2-1-8-cross-site-scripting-xss-vulnerability?_s_id=cve"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

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

CWE-79

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

Proof of Concept

Recommendation

Bazar form-field templates still apply |raw('html') to field.label / field.hint in attribute and label-body contexts — stored XSS in form renders (sibling class of commit e6b66aa)

Summary

Affected

Vulnerability details

[A] — Source: field.label and field.hint are populated from form definitions

[B] — Sink class 1: attribute-context |raw('html')|striptags (placeholder breakout)

[C] — Sink class 2: attribute-context |raw('html') without striptags (worse)

[D] — Sink class 3: label-body |raw (direct DOM injection)

Why the fix at e6b66aa is incomplete

Proof of concept

Setup

PoC 1 — range.twig placeholder attribute breakout (Sink class [B])

PoC 2 — layouts/input.twig tooltip injection (Sink class [C])

PoC 3 — layouts/input.twig label-body injection (Sink class [D])

Impact

Direct

Indirect / second-order

Suggested fix

Mitigation MIT-4

Mitigation

Mitigation MIT-6

Mitigation MIT-15

Mitigation MIT-27

Mitigation MIT-30.1

Mitigation MIT-43

Mitigation MIT-31

Mitigation MIT-5

Mitigation MIT-21

Mitigation MIT-29

Mitigation MIT-16

CAPEC-209: XSS Using MIME Type Mismatch

CAPEC-588: DOM-Based XSS

CAPEC-591: Reflected XSS

CAPEC-592: Stored XSS

CAPEC-63: Cross-Site Scripting (XSS)

CAPEC-85: AJAX Footprinting

Bazar form-field templates still apply `|raw('html')` to `field.label` / `field.hint` in attribute and label-body contexts — stored XSS in form renders (sibling class of commit `e6b66aa`)

[A] — Source: `field.label` and `field.hint` are populated from form definitions

[B] — Sink class 1: attribute-context `|raw('html')|striptags` (placeholder breakout)

[C] — Sink class 2: attribute-context `|raw('html')` without `striptags` (worse)

[D] — Sink class 3: label-body `|raw` (direct DOM injection)

Why the fix at `e6b66aa` is incomplete

PoC 1 — `range.twig` placeholder attribute breakout (Sink class [B])

PoC 2 — `layouts/input.twig` tooltip injection (Sink class [C])

PoC 3 — `layouts/input.twig` label-body injection (Sink class [D])