Common Weakness Enumeration

CWE-116

Allowed-with-Review

Improper Encoding or Escaping of Output

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.

610 vulnerabilities reference this CWE, most recent first.

GHSA-X72W-3H7J-3F2R

Vulnerability from github – Published: 2025-10-06 12:30 – Updated: 2026-06-06 09:31
VLAI
Details

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Logo Software Inc. Logo Cloud allows Phishing.This issue affects Logo Cloud: before 2.57.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-0607"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-06T10:15:32Z",
    "severity": "MODERATE"
  },
  "details": "Improper Neutralization of Input During Web Page Generation (XSS or \u0027Cross-site Scripting\u0027) vulnerability in Logo Software Inc. Logo Cloud allows Phishing.This issue affects Logo Cloud: before 2.57.",
  "id": "GHSA-x72w-3h7j-3f2r",
  "modified": "2026-06-06T09:31:14Z",
  "published": "2025-10-06T12:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0607"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-25-0318"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-25-0318"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X848-FC4R-XCW9

Vulnerability from github – Published: 2024-02-03 09:30 – Updated: 2024-02-03 09:30
VLAI
Details

A host header injection vulnerability in the HTTP handler component of Crafty Controller allows a remote, unauthenticated attacker to trigger a Denial of Service (DoS) condition via a modified host header

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-1064"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-644"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-03T09:15:11Z",
    "severity": "HIGH"
  },
  "details": "A host header injection vulnerability in the HTTP handler component of Crafty Controller allows a remote, unauthenticated attacker to trigger a Denial of Service (DoS) condition via a modified host header",
  "id": "GHSA-x848-fc4r-xcw9",
  "modified": "2024-02-03T09:30:18Z",
  "published": "2024-02-03T09:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1064"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/crafty-controller/crafty-4/-/issues/327"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X86F-C5G7-4MRQ

Vulnerability from github – Published: 2023-06-02 18:30 – Updated: 2024-04-04 04:29
VLAI
Details

When copying a network request from the developer tools panel as a curl command the output was not being properly sanitized and could allow arbitrary commands to be hidden within. This vulnerability affects Firefox < 109, Thunderbird < 102.7, and Firefox ESR < 102.7.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-23599"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-02T17:15:10Z",
    "severity": "MODERATE"
  },
  "details": "When copying a network request from the developer tools panel as a curl command the output was not being properly sanitized and could allow arbitrary commands to be hidden within. This vulnerability affects Firefox \u003c 109, Thunderbird \u003c 102.7, and Firefox ESR \u003c 102.7.",
  "id": "GHSA-x86f-c5g7-4mrq",
  "modified": "2024-04-04T04:29:39Z",
  "published": "2023-06-02T18:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23599"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1777800"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2023-01"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2023-02"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2023-03"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X8GM-J36P-FPPF

Vulnerability from github – Published: 2024-10-01 22:27 – Updated: 2024-12-19 20:14
VLAI
Summary
LibreNMS vulnerable to Stored Cross-site Scripting via File Upload
Details

Summary

Stored Cross-Site Scripting (XSS) can archive via Uploading a new Background for a Custom Map.

Details

Users with "admin" role can set background for a custom map, this allow the upload of SVG file that can contain XSS payload which will trigger onload. This led to Stored Cross-Site Scripting (XSS).

PoC

  1. Login using an Admin role account.

  2. Go over to "$URL/maps/custom", the Manage Custom Maps. image

  3. Create a new map then choose to edit it.

  4. Choose the "Set Background" option. image

  5. Choose to upload a SVG file that have this content.

<svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.domain)">
  <circle cx="50" cy="50" r="40" />
</svg>

  1. Once uploaded, there should be a link to the SVG return in the POST request to the API "$URL/maps/custom/1/background". image

  2. Go over to that link on browser, should see a pop-up. image

Impact

Attacker can use this to perform malicious java script code for malicious intent. This would impact other Admin role users and the Global Read role users. Normal users does not have permission to read the file, so they are not affected.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "librenms/librenms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "24.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47528"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-434",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-01T22:27:32Z",
    "nvd_published_at": "2024-10-01T21:15:08Z",
    "severity": "LOW"
  },
  "details": "### Summary\nStored Cross-Site Scripting (XSS) can archive via Uploading a new Background for a Custom Map.\n\n### Details\nUsers with \"admin\" role can set background for a custom map, this allow the upload of SVG file that can contain XSS payload which will trigger onload. This led to Stored Cross-Site Scripting (XSS).\n\n### PoC\n1. Login using an Admin role account.\n\n2. Go over to \"$URL/maps/custom\", the Manage Custom Maps.\n![image](https://github.com/user-attachments/assets/9d621532-7880-4010-b12d-efd377f0cfdd)\n\n3. Create a new map then choose to edit it.\n4. Choose the \"Set Background\" option.\n![image](https://github.com/user-attachments/assets/dc2e9453-ef3e-4649-a42f-60b7a2ad8189)\n\n5. Choose to upload a SVG file that have this content.\n```svg\n\u003csvg xmlns=\"http://www.w3.org/2000/svg\" onload=\"alert(document.domain)\"\u003e\n  \u003ccircle cx=\"50\" cy=\"50\" r=\"40\" /\u003e\n\u003c/svg\u003e\n```\n\n6. Once uploaded, there should be a link to the SVG return in the POST request to the API \"$URL/maps/custom/1/background\".\n![image](https://github.com/user-attachments/assets/dc224960-0bd3-42c9-ad49-2ec85b065939)\n\n7. Go over to that link on browser, should see a pop-up.\n![image](https://github.com/user-attachments/assets/47a7db14-bd89-48fe-885a-fd80a052115e)\n\n### Impact\nAttacker can use this to perform malicious java script code for malicious intent.\nThis would impact other Admin role users and the Global Read role users. Normal users does not have permission to read the file, so they are not affected.\n",
  "id": "GHSA-x8gm-j36p-fppf",
  "modified": "2024-12-19T20:14:29Z",
  "published": "2024-10-01T22:27:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/librenms/librenms/security/advisories/GHSA-x8gm-j36p-fppf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47528"
    },
    {
      "type": "WEB",
      "url": "https://github.com/librenms/librenms/commit/d959bf1b366319eda16e3cd6dfda8a22beb203be"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/librenms/librenms"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "LibreNMS vulnerable to Stored Cross-site Scripting via File Upload"
}

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: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 (&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.

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
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-XHJ6-R3M9-CX4X

Vulnerability from github – Published: 2022-02-15 00:02 – Updated: 2022-02-24 00:01
VLAI
Details

A Header Injection vulnerability exists in Compass Plus TranzWare Online FIMI Web Interface Tranzware Online (TWO) 5.3.33.3 F38 and FIMI 4.2.19.4 25.The HTTP host header can be manipulated and cause the application to behave in unexpected ways. Any changes made to the header would just cause the request to be sent to a completely different Domain/IP address. This is due to that the server implicitly trusts the Host header, and fails to validate or escape it properly. An attacker can use this input to redirect target users to a malicious domain/web page. This would result in expanding the potential to further attacks and malicious actions.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-43106"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-14T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A Header Injection vulnerability exists in Compass Plus TranzWare Online FIMI Web Interface Tranzware Online (TWO) 5.3.33.3 F38 and FIMI 4.2.19.4 25.The HTTP host header can be manipulated and cause the application to behave in unexpected ways. Any changes made to the header would just cause the request to be sent to a completely different Domain/IP address. This is due to that the server implicitly trusts the Host header, and fails to validate or escape it properly. An attacker can use this input to redirect target users to a malicious domain/web page. This would result in expanding the potential to further attacks and malicious actions.",
  "id": "GHSA-xhj6-r3m9-cx4x",
  "modified": "2022-02-24T00:01:11Z",
  "published": "2022-02-15T00:02:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43106"
    },
    {
      "type": "WEB",
      "url": "https://github.com/IthacaLabs/CompassPlus/tree/main/TranzWare%20Online%20FIMI_Version%204.2.19.4%2025_HHI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XHJH-PMCV-23JW

Vulnerability from github – Published: 2026-05-05 00:18 – Updated: 2026-05-05 00:18
VLAI
Summary
Axios: Null Byte Injection via Reverse-Encoding in AxiosURLSearchParams
Details

Vulnerability Disclosure: Null Byte Injection via Reverse-Encoding in AxiosURLSearchParams

Summary

The encode() function in lib/helpers/AxiosURLSearchParams.js contains a character mapping (charMap) at line 21 that reverses the safe percent-encoding of null bytes. After encodeURIComponent('\x00') correctly produces the safe sequence %00, the charMap entry '%00': '\x00' converts it back to a raw null byte.

This is a clear encoding defect: every other charMap entry encodes in the safe direction (literal → percent-encoded), while this single entry decodes in the opposite (dangerous) direction.

Severity: Low (CVSS 3.7) Affected Versions: All versions containing this charMap entry Vulnerable Component: lib/helpers/AxiosURLSearchParams.js:21

CWE

  • CWE-626: Null Byte Interaction Error (Poison Null Byte)
  • CWE-116: Improper Encoding or Escaping of Output

CVSS 3.1

Score: 3.7 (Low)

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

Metric Value Justification
Attack Vector Network Attacker controls input parameters remotely
Attack Complexity High Standard axios request flow (buildURL) uses its own encode function which does NOT have this bug. Only triggered via direct AxiosURLSearchParams.toString() without an encoder, or via custom paramsSerializer delegation
Privileges Required None No authentication needed
User Interaction None No user interaction required
Scope Unchanged Impact limited to HTTP request URL
Confidentiality None No confidentiality impact
Integrity Low Null byte in URL can cause truncation in C-based backends, but requires a vulnerable downstream parser
Availability None No availability impact

Vulnerable Code

File: lib/helpers/AxiosURLSearchParams.js, lines 13-26

function encode(str) {
  const charMap = {
    '!': '%21',     // literal → encoded (SAFE direction)
    "'": '%27',     // literal → encoded (SAFE direction)
    '(': '%28',     // literal → encoded (SAFE direction)
    ')': '%29',     // literal → encoded (SAFE direction)
    '~': '%7E',     // literal → encoded (SAFE direction)
    '%20': '+',     // standard transformation (SAFE)
    '%00': '\x00',  // LINE 21: encoded → raw null byte (UNSAFE direction!)
  };
  return encodeURIComponent(str).replace(/[!'()~]|%20|%00/g, function replacer(match) {
    return charMap[match];
  });
}

Why the Standard Flow Is NOT Affected

// buildURL.js:36 — uses its OWN encode function (lines 14-20), not AxiosURLSearchParams's
const _encode = (options && options.encode) || encode;  // buildURL's encode

// buildURL.js:53 — passes buildURL's encode to AxiosURLSearchParams
new AxiosURLSearchParams(params, _options).toString(_encode);  // external encoder used

// AxiosURLSearchParams.js:48 — when encoder is provided, internal encode is NOT used
const _encode = encoder ? function(value) { return encoder.call(this, value, encode); } : encode;
//                                                                              ^^^^^^
//                                           internal encode passed as 2nd arg but only used if
//                                           the external encoder explicitly delegates to it

Proof of Concept

import AxiosURLSearchParams from './lib/helpers/AxiosURLSearchParams.js';
import buildURL from './lib/helpers/buildURL.js';

// Test 1: Direct AxiosURLSearchParams (VULNERABLE path)
const params = new AxiosURLSearchParams({ file: 'test\x00.txt' });
const result = params.toString();  // NO encoder → uses internal encode with charMap
console.log('Direct toString():', JSON.stringify(result));
// Output: "file=test\u0000.txt" (contains raw null byte)
console.log('Hex:', Buffer.from(result).toString('hex'));
// Output: 66696c653d74657374002e747874  (00 = null byte)

// Test 2: Via buildURL (NOT vulnerable — standard axios flow)
const url = buildURL('http://example.com/api', { file: 'test\x00.txt' });
console.log('Via buildURL:', url);
// Output: http://example.com/api?file=test%00.txt  (%00 preserved safely)

Verified PoC Output

Direct toString(): "file=test\u0000.txt"
Contains raw null byte: true
Hex: 66696c653d74657374002e747874

Via buildURL: http://example.com/api?file=test%00.txt
Contains raw null byte: false
Contains safe %00: true

Impact Analysis

Primary impact is limited because the standard axios request flow is not affected. However:

  • Direct API users: Applications using AxiosURLSearchParams directly for custom serialization are affected
  • Custom paramsSerializer: A paramsSerializer.encode that delegates to the internal encoder triggers the bug
  • Code defect signal: The directional inconsistency in charMap is a clear coding error with no legitimate use case

If null bytes reach a downstream C-based parser, impacts include URL truncation, WAF bypass, and log injection.

Recommended Fix

Remove the %00 entry from charMap and update the regex:

function encode(str) {
  const charMap = {
    '!': '%21',
    "'": '%27',
    '(': '%28',
    ')': '%29',
    '~': '%7E',
    '%20': '+',
    // REMOVED: '%00': '\x00'
  };
  return encodeURIComponent(str).replace(/[!'()~]|%20/g, function replacer(match) {
    //                                           ^^^^ removed |%00
    return charMap[match];
  });
}

Resources

Timeline

Date Event
2026-04-15 Vulnerability discovered during source code audit
2026-04-16 Report revised: documented standard-flow limitation, corrected CVSS
TBD Report submitted to vendor via GitHub Security Advisory
Severity
3.7 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.15.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.31.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.31.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42040"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-626"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T00:18:03Z",
    "nvd_published_at": "2026-04-24T18:16:30Z",
    "severity": "LOW"
  },
  "details": "# Vulnerability Disclosure: Null Byte Injection via Reverse-Encoding in AxiosURLSearchParams\n\n## Summary\n\nThe `encode()` function in `lib/helpers/AxiosURLSearchParams.js` contains a character mapping (`charMap`) at line 21 that **reverses** the safe percent-encoding of null bytes. After `encodeURIComponent(\u0027\\x00\u0027)` correctly produces the safe sequence `%00`, the charMap entry `\u0027%00\u0027: \u0027\\x00\u0027` converts it back to a raw null byte.\n\nThis is a clear encoding defect: every other charMap entry encodes in the safe direction (literal \u2192 percent-encoded), while this single entry decodes in the opposite (dangerous) direction.\n\n**Severity:** Low (CVSS 3.7)\n**Affected Versions:** All versions containing this charMap entry\n**Vulnerable Component:** `lib/helpers/AxiosURLSearchParams.js:21`\n\n## CWE\n\n- **CWE-626:** Null Byte Interaction Error (Poison Null Byte)\n- **CWE-116:** Improper Encoding or Escaping of Output\n\n## CVSS 3.1\n\n**Score: 3.7 (Low)**\n\nVector: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N`\n\n| Metric | Value | Justification |\n|---|---|---|\n| Attack Vector | Network | Attacker controls input parameters remotely |\n| Attack Complexity | High | Standard axios request flow (`buildURL`) uses its own `encode` function which does NOT have this bug. Only triggered via direct `AxiosURLSearchParams.toString()` without an encoder, or via custom `paramsSerializer` delegation |\n| Privileges Required | None | No authentication needed |\n| User Interaction | None | No user interaction required |\n| Scope | Unchanged | Impact limited to HTTP request URL |\n| Confidentiality | None | No confidentiality impact |\n| Integrity | Low | Null byte in URL can cause truncation in C-based backends, but requires a vulnerable downstream parser |\n| Availability | None | No availability impact |\n\n## Vulnerable Code\n\n**File:** `lib/helpers/AxiosURLSearchParams.js`, lines 13-26\n\n```javascript\nfunction encode(str) {\n  const charMap = {\n    \u0027!\u0027: \u0027%21\u0027,     // literal \u2192 encoded (SAFE direction)\n    \"\u0027\": \u0027%27\u0027,     // literal \u2192 encoded (SAFE direction)\n    \u0027(\u0027: \u0027%28\u0027,     // literal \u2192 encoded (SAFE direction)\n    \u0027)\u0027: \u0027%29\u0027,     // literal \u2192 encoded (SAFE direction)\n    \u0027~\u0027: \u0027%7E\u0027,     // literal \u2192 encoded (SAFE direction)\n    \u0027%20\u0027: \u0027+\u0027,     // standard transformation (SAFE)\n    \u0027%00\u0027: \u0027\\x00\u0027,  // LINE 21: encoded \u2192 raw null byte (UNSAFE direction!)\n  };\n  return encodeURIComponent(str).replace(/[!\u0027()~]|%20|%00/g, function replacer(match) {\n    return charMap[match];\n  });\n}\n```\n\n### Why the Standard Flow Is NOT Affected\n\n```javascript\n// buildURL.js:36 \u2014 uses its OWN encode function (lines 14-20), not AxiosURLSearchParams\u0027s\nconst _encode = (options \u0026\u0026 options.encode) || encode;  // buildURL\u0027s encode\n\n// buildURL.js:53 \u2014 passes buildURL\u0027s encode to AxiosURLSearchParams\nnew AxiosURLSearchParams(params, _options).toString(_encode);  // external encoder used\n\n// AxiosURLSearchParams.js:48 \u2014 when encoder is provided, internal encode is NOT used\nconst _encode = encoder ? function(value) { return encoder.call(this, value, encode); } : encode;\n//                                                                              ^^^^^^\n//                                           internal encode passed as 2nd arg but only used if\n//                                           the external encoder explicitly delegates to it\n```\n\n## Proof of Concept\n\n```javascript\nimport AxiosURLSearchParams from \u0027./lib/helpers/AxiosURLSearchParams.js\u0027;\nimport buildURL from \u0027./lib/helpers/buildURL.js\u0027;\n\n// Test 1: Direct AxiosURLSearchParams (VULNERABLE path)\nconst params = new AxiosURLSearchParams({ file: \u0027test\\x00.txt\u0027 });\nconst result = params.toString();  // NO encoder \u2192 uses internal encode with charMap\nconsole.log(\u0027Direct toString():\u0027, JSON.stringify(result));\n// Output: \"file=test\\u0000.txt\" (contains raw null byte)\nconsole.log(\u0027Hex:\u0027, Buffer.from(result).toString(\u0027hex\u0027));\n// Output: 66696c653d74657374002e747874  (00 = null byte)\n\n// Test 2: Via buildURL (NOT vulnerable \u2014 standard axios flow)\nconst url = buildURL(\u0027http://example.com/api\u0027, { file: \u0027test\\x00.txt\u0027 });\nconsole.log(\u0027Via buildURL:\u0027, url);\n// Output: http://example.com/api?file=test%00.txt  (%00 preserved safely)\n```\n\n## Verified PoC Output\n\n```\nDirect toString(): \"file=test\\u0000.txt\"\nContains raw null byte: true\nHex: 66696c653d74657374002e747874\n\nVia buildURL: http://example.com/api?file=test%00.txt\nContains raw null byte: false\nContains safe %00: true\n```\n\n## Impact Analysis\n\n**Primary impact is limited** because the standard axios request flow is not affected. However:\n\n- **Direct API users:** Applications using `AxiosURLSearchParams` directly for custom serialization are affected\n- **Custom paramsSerializer:** A `paramsSerializer.encode` that delegates to the internal encoder triggers the bug\n- **Code defect signal:** The directional inconsistency in charMap is a clear coding error with no legitimate use case\n\nIf null bytes reach a downstream C-based parser, impacts include URL truncation, WAF bypass, and log injection.\n\n## Recommended Fix\n\nRemove the `%00` entry from charMap and update the regex:\n\n```javascript\nfunction encode(str) {\n  const charMap = {\n    \u0027!\u0027: \u0027%21\u0027,\n    \"\u0027\": \u0027%27\u0027,\n    \u0027(\u0027: \u0027%28\u0027,\n    \u0027)\u0027: \u0027%29\u0027,\n    \u0027~\u0027: \u0027%7E\u0027,\n    \u0027%20\u0027: \u0027+\u0027,\n    // REMOVED: \u0027%00\u0027: \u0027\\x00\u0027\n  };\n  return encodeURIComponent(str).replace(/[!\u0027()~]|%20/g, function replacer(match) {\n    //                                           ^^^^ removed |%00\n    return charMap[match];\n  });\n}\n```\n\n## Resources\n\n- [CWE-626: Null Byte Interaction Error](https://cwe.mitre.org/data/definitions/626.html)\n- [CWE-116: Improper Encoding or Escaping of Output](https://cwe.mitre.org/data/definitions/116.html)\n- [OWASP: Embedding Null Code](https://owasp.org/www-community/attacks/Embedding_Null_Code)\n- [Axios GitHub Repository](https://github.com/axios/axios)\n\n## Timeline\n\n| Date | Event |\n|---|---|\n| 2026-04-15 | Vulnerability discovered during source code audit |\n| 2026-04-16 | Report revised: documented standard-flow limitation, corrected CVSS |\n| TBD | Report submitted to vendor via GitHub Security Advisory |",
  "id": "GHSA-xhjh-pmcv-23jw",
  "modified": "2026-05-05T00:18:03Z",
  "published": "2026-05-05T00:18:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-xhjh-pmcv-23jw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42040"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Axios: Null Byte Injection via Reverse-Encoding in AxiosURLSearchParams"
}

GHSA-XHPH-75HG-J96M

Vulnerability from github – Published: 2024-05-21 12:30 – Updated: 2025-06-05 15:31
VLAI
Details

There exists a Denial of service vulnerability in Tink-cc in versions prior to 2.1.3.  * An adversary can crash binaries using the crypto::tink::JsonKeysetReader in tink-cc by providing an input that is not an encoded JSON object, but still a valid encoded JSON element, for example a number or an array. This will crash as Tink just assumes any valid JSON input will contain an object.

  • An adversary can crash binaries using the crypto::tink::JsonKeysetReader in tink-cc by providing an input containing many nested JSON objects. This may result in a stack overflow.

We recommend upgrading to version 2.1.3 or above

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
6.8 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/S:N/AU:Y/V:D/RE:L/U:Green
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-4420"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T12:15:08Z",
    "severity": "MODERATE"
  },
  "details": "There exists a Denial of service vulnerability in Tink-cc in versions prior to 2.1.3.\u00a0  *  An adversary can crash binaries using the crypto::tink::JsonKeysetReader in tink-cc by providing an input that is not an encoded JSON object, but still a valid encoded JSON element, for example a number or an array. This will crash as Tink just assumes any valid JSON input will contain an object.\n\n\n  *  An adversary can crash binaries using the crypto::tink::JsonKeysetReader in tink-cc by providing an input containing many nested JSON objects. This may result in a stack overflow.\n\n\nWe recommend upgrading to version 2.1.3 or above",
  "id": "GHSA-xhph-75hg-j96m",
  "modified": "2025-06-05T15:31:20Z",
  "published": "2024-05-21T12:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4420"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tink-crypto/tink-cc/issues/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:N/AU:Y/R:X/V:D/RE:L/U:Green",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-XJ2V-MGXG-MCM4

Vulnerability from github – Published: 2026-04-21 03:31 – Updated: 2026-07-08 03:30
VLAI
Details

** UNSUPPORTED WHEN ASSIGNED ** An improper encoding or escaping vulnerability in the CGI program of Zyxel WRE6505 v2 firmware version V1.00(ABDV.3)C0 could allow an adjacent attacker on the WLAN to cause a denial-of-service (DoS) condition in the web management interface by convincing an authenticated administrator to visit the “AP Select” page while a malformed SSID is present.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-6058"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-21T02:16:08Z",
    "severity": "MODERATE"
  },
  "details": "** UNSUPPORTED WHEN ASSIGNED ** An improper encoding or escaping vulnerability in the CGI program of Zyxel WRE6505 v2 firmware version V1.00(ABDV.3)C0 could allow an adjacent attacker on the WLAN to cause a denial-of-service (DoS) condition in the web management interface by convincing an authenticated administrator to visit the \u201cAP Select\u201d page while a malformed SSID is present.",
  "id": "GHSA-xj2v-mgxg-mcm4",
  "modified": "2026-07-08T03:30:25Z",
  "published": "2026-04-21T03:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6058"
    },
    {
      "type": "WEB",
      "url": "https://www.zyxel.com/global/en/support/end-of-life"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XJFW-5VV5-VJQ2

Vulnerability from github – Published: 2022-06-01 20:25 – Updated: 2022-06-01 20:25
VLAI
Summary
Cross-site Scripting in Filter Stream Converter Application in XWiki Platform
Details

Impact

We found a possible XSS vector in the Filter.FilterStreamDescriptorForm wiki page related to pretty much all the form fields printed in the home page of the application.

Patches

The issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, 13.10.3.

Workarounds

The easiest workaround is to edit the wiki page Filter.FilterStreamDescriptorForm (with wiki editor) and change the lines

          <input type="text" id="$descriptorId" name="$descriptorId" value="#if($request.get($descriptorId))$request.get($descriptorId)#else$descriptor.defaultValue#end"/>
        #else
          <input type="text" id="$descriptorId" name="$descriptorId"#if($request.get($descriptorId))value="$request.get($descriptorId)"#end/>

into

          <input type="text" id="$descriptorId" name="$descriptorId" value="#if($request.get($descriptorId))$escapetool.xml($request.get($descriptorId))#else$descriptor.defaultValue#end"/>
        #else
          <input type="text" id="$descriptorId" name="$descriptorId"#if($request.get($descriptorId))value="$escapetool.xml($request.get($descriptorId))"#end/>
Severity
7.4 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-filter-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.4.4"
            },
            {
              "fixed": "12.10.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-filter-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "13.0.0"
            },
            {
              "fixed": "13.4.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-filter-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "13.5.0"
            },
            {
              "fixed": "13.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-29258"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-01T20:25:54Z",
    "nvd_published_at": "2022-05-31T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nWe found a possible XSS vector in the `Filter.FilterStreamDescriptorForm` wiki page related to pretty much all the form fields printed in the home page of the application.\n\n### Patches\nThe issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, 13.10.3.\n\n### Workarounds\nThe easiest workaround is to edit the wiki page `Filter.FilterStreamDescriptorForm` (with wiki editor) and change the lines\n\n```\n          \u003cinput type=\"text\" id=\"$descriptorId\" name=\"$descriptorId\" value=\"#if($request.get($descriptorId))$request.get($descriptorId)#else$descriptor.defaultValue#end\"/\u003e\n        #else\n          \u003cinput type=\"text\" id=\"$descriptorId\" name=\"$descriptorId\"#if($request.get($descriptorId))value=\"$request.get($descriptorId)\"#end/\u003e\n```\n\ninto\n\n```\n          \u003cinput type=\"text\" id=\"$descriptorId\" name=\"$descriptorId\" value=\"#if($request.get($descriptorId))$escapetool.xml($request.get($descriptorId))#else$descriptor.defaultValue#end\"/\u003e\n        #else\n          \u003cinput type=\"text\" id=\"$descriptorId\" name=\"$descriptorId\"#if($request.get($descriptorId))value=\"$escapetool.xml($request.get($descriptorId))\"#end/\u003e\n```",
  "id": "GHSA-xjfw-5vv5-vjq2",
  "modified": "2022-06-01T20:25:54Z",
  "published": "2022-06-01T20:25:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-xjfw-5vv5-vjq2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29258"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/21906acb5ee2304552f56f9bbdbf8e7d368f7f3a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-19293"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Cross-site Scripting in Filter Stream Converter Application in XWiki Platform"
}
Mitigation MIT-4.3
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.
  • For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.
  • Alternately, use built-in functions, but consider using wrappers in case those functions are discovered to have a vulnerability.
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.
  • For example, stored procedures can enforce database query structure and reduce the likelihood of SQL injection.
Mitigation
Architecture and Design Implementation

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.

Mitigation
Architecture and Design

In some cases, input validation may be an important strategy when output encoding is not a complete solution. For example, you may be providing the same output that will be processed by multiple consumers that use different encodings or representations. In other cases, you may be required to allow user-supplied input to contain control information, such as limited HTML tags that support formatting in a wiki or bulletin board. When this type of requirement must be met, use an extremely strict allowlist to limit which control sequences can be used. Verify that the resulting syntactic structure is what you expect. Use your normal encoding methods for the remainder of the input.

Mitigation
Architecture and Design

Use input validation as a defense-in-depth measure to reduce the likelihood of output encoding errors (see CWE-20).

Mitigation
Requirements

Fully specify which encodings are required by components that will be communicating with each other.

Mitigation
Implementation

When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.

CAPEC-104: Cross Zone Scripting

An attacker is able to cause a victim to load content into their web-browser that bypasses security zone controls and gain access to increased privileges to execute scripting code or other web objects such as unsigned ActiveX controls or applets. This is a privilege elevation attack targeted at zone-based web-browser security.

CAPEC-73: User-Controlled Filename

An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.

CAPEC-81: Web Server Logs Tampering

Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.

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