GHSA-XC7J-3G8Q-9VH4

Vulnerability from github – Published: 2026-07-09 21:00 – Updated: 2026-07-09 21:00
VLAI
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:19placeholder="{{ field.label|raw('html')|striptags }}"
  • tools/bazar/templates/inputs/email.twig:13placeholder="{{ field.label|raw('html')|striptags }}"
  • tools/bazar/templates/layouts/input.twig:7title="{{ 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 (&quot;, &#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'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

  1. Install YesWiki and log in as admin (or as any user with the saisie_formulaire ACL).
  2. 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.

Show details on source website

{
  "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))"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…