Common Weakness Enumeration

CWE-80

Allowed

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Abstraction: Variant · Status: Incomplete

The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters such as "<", ">", and "&" that could be interpreted as web-scripting elements when they are sent to a downstream component that processes web pages.

936 vulnerabilities reference this CWE, most recent first.

GHSA-33GV-FC78-QGF5

Vulnerability from github – Published: 2026-05-05 20:31 – Updated: 2026-05-13 16:24
VLAI
Summary
YAFNET has Unauthenticated Stored Second-Order XSS in Admin Event Log via Reflected `User-Agent` Header
Details

Description: Stored (second-order) Cross-Site Scripting (XSS) occurs when attacker-controlled input is persisted through one component of an application and later rendered, without proper sanitization or contextual output encoding, by a completely different component — often one that implicitly trusts the stored data. Because the dangerous sink is typically a privileged administrative interface, the payload executes in the browser of a high-value user (such as an administrator) and inherits their authenticated session. This class of issue is especially severe when the entry point is an HTTP header on an unauthenticated endpoint, since the attack surface extends to any anonymous attacker on the internet with no prerequisites.

Issue Details: The application's database logger (YAFNET.Core/Logger/DbLogger.cs) captures the incoming request's User-Agent header into a JObject, serializes it with JsonConvert, and stores the result in the EventLog.Description column whenever an event (e.g., an unhandled exception) is logged. The admin event-log page (YetAnotherForum.NET/Pages/Admin/EventLog.cshtml.cs) later deserializes that JSON in FormatStackTrace() and interpolates the UserAgent value directly into an HTML string with no encoding, and the Razor view EventLog.cshtml emits the result through @Html.Raw. Critically, the attacker does not need to be authenticated: the unauthenticated endpoint GET /api/Attachments/GetAttachment?attachmentId=2147483647 reliably triggers a server-side exception that is written to dbo.EventLog together with the attacker-controlled User-Agent. A single anonymous request such as curl -A "<img src=x onerror=alert('XSS')>" "http://<target>/api/Attachments/GetAttachment?attachmentId=2147483647" is sufficient to persist the payload, and when an administrator later visits /Admin/EventLog the malicious markup is rendered as live HTML in the admin's authenticated session.

Impact: An entirely unauthenticated attacker, with no account, no CSRF token, and no prior access, can stage JavaScript that will execute in an administrator's browser the next time the Event Log is viewed. Because the script runs in the admin's authenticated origin, it can perform any action the admin can: creating new administrative accounts, modifying site-wide settings, exfiltrating user data through admin-only endpoints. This effectively converts a single anonymous HTTP request into a full forum-takeover primitive, and the lack of any authentication requirement makes it exploitable at internet scale, including by automated scanners.

Likelihood: Exploitation requires only the ability to send a single HTTP request to a public, unauthenticated endpoint, which any anonymous attacker on the internet can do. Administrators routinely review the Event Log as part of normal operations, so payload delivery is highly probable with negligible attacker effort, making the overall likelihood very high.

Steps to Reproduce: - From an unauthenticated session (no cookies, no tokens), send the following request with a malicious User-Agent header: - curl.exe -sS -A "<img src=x onerror=alert('XSS')>" "http://yetanotherforum.internal:8080/api/Attachments/GetAttachment?attachmentId=2147483647" - Confirm the server returns an error response and that a row has been written to dbo.EventLog containing the attacker-controlled UserAgent value inside the JSON Description. - As an administrator (e.g., Superuser), navigate to /Admin/EventLog. - Observe that the rendered page contains the raw <img src=x onerror="alert('XSS')"> element inside the event's badge block, and that the onerror handler executes in the admin's authenticated session, confirming cross-session, cross-privilege script execution from an unauthenticated source.

image

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.0.4"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "YAFNET.Core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-beta01"
            },
            {
              "fixed": "4.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.2.11"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "YAFNET.Core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.2.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43938"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-79",
      "CWE-80"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T20:31:36Z",
    "nvd_published_at": "2026-05-12T15:16:15Z",
    "severity": "HIGH"
  },
  "details": "**Description:**\nStored (second-order) Cross-Site Scripting (XSS) occurs when attacker-controlled input is persisted through one component of an application and later rendered, without proper sanitization or contextual output encoding, by a completely different component \u2014 often one that implicitly trusts the stored data. Because the dangerous sink is typically a privileged administrative interface, the payload executes in the browser of a high-value user (such as an administrator) and inherits their authenticated session. This class of issue is especially severe when the entry point is an HTTP header on an unauthenticated endpoint, since the attack surface extends to any anonymous attacker on the internet with no prerequisites.\n\n**Issue Details:**\nThe application\u0027s database logger (`YAFNET.Core/Logger/DbLogger.cs`) captures the incoming request\u0027s `User-Agent` header into a `JObject`, serializes it with `JsonConvert`, and stores the result in the `EventLog.Description` column whenever an event (e.g., an unhandled exception) is logged. The admin event-log page (`YetAnotherForum.NET/Pages/Admin/EventLog.cshtml.cs`) later deserializes that JSON in `FormatStackTrace()` and interpolates the `UserAgent` value directly into an HTML string with no encoding, and the Razor view `EventLog.cshtml` emits the result through `@Html.Raw`. Critically, the attacker does not need to be authenticated: the unauthenticated endpoint `GET /api/Attachments/GetAttachment?attachmentId=2147483647` reliably triggers a server-side exception that is written to `dbo.EventLog` together with the attacker-controlled `User-Agent`. A single anonymous request such as `curl -A \"\u003cimg src=x onerror=alert(\u0027XSS\u0027)\u003e\" \"http://\u003ctarget\u003e/api/Attachments/GetAttachment?attachmentId=2147483647\"` is sufficient to persist the payload, and when an administrator later visits `/Admin/EventLog` the malicious markup is rendered as live HTML in the admin\u0027s authenticated session.\n\n**Impact:**\nAn entirely unauthenticated attacker, with no account, no CSRF token, and no prior access, can stage JavaScript that will execute in an administrator\u0027s browser the next time the Event Log is viewed. Because the script runs in the admin\u0027s authenticated origin, it can perform any action the admin can: creating new administrative accounts, modifying site-wide settings, exfiltrating user data through admin-only endpoints. This effectively converts a single anonymous HTTP request into a full forum-takeover primitive, and the lack of any authentication requirement makes it exploitable at internet scale, including by automated scanners.\n\n**Likelihood:**\nExploitation requires only the ability to send a single HTTP request to a public, unauthenticated endpoint, which any anonymous attacker on the internet can do. Administrators routinely review the Event Log as part of normal operations, so payload delivery is highly probable with negligible attacker effort, making the overall likelihood very high.\n\n**Steps to Reproduce:**\n- From an unauthenticated session (no cookies, no tokens), send the following request with a malicious `User-Agent` header:\n  - `curl.exe -sS -A \"\u003cimg src=x onerror=alert(\u0027XSS\u0027)\u003e\" \"http://yetanotherforum.internal:8080/api/Attachments/GetAttachment?attachmentId=2147483647\"`\n- Confirm the server returns an error response and that a row has been written to `dbo.EventLog` containing the attacker-controlled `UserAgent` value inside the JSON `Description`.\n- As an administrator (e.g., `Superuser`), navigate to `/Admin/EventLog`.\n- Observe that the rendered page contains the raw `\u003cimg src=x onerror=\"alert(\u0027XSS\u0027)\"\u003e` element inside the event\u0027s badge block, and that the `onerror` handler executes in the admin\u0027s authenticated session, confirming cross-session, cross-privilege script execution from an unauthenticated source.\n\n\u003cimg width=\"1193\" height=\"809\" alt=\"image\" src=\"https://github.com/user-attachments/assets/70c59ef2-8d31-435b-9a9d-338f753e58f8\" /\u003e",
  "id": "GHSA-33gv-fc78-qgf5",
  "modified": "2026-05-13T16:24:19Z",
  "published": "2026-05-05T20:31:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/YAFNET/YAFNET/security/advisories/GHSA-33gv-fc78-qgf5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43938"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/YAFNET/YAFNET"
    },
    {
      "type": "WEB",
      "url": "https://github.com/YAFNET/YAFNET/releases/tag/v3.2.12"
    },
    {
      "type": "WEB",
      "url": "https://github.com/YAFNET/YAFNET/releases/tag/v4.0.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "YAFNET has Unauthenticated Stored Second-Order XSS in Admin Event Log via Reflected `User-Agent` Header"
}

GHSA-33P4-8HXP-X9PP

Vulnerability from github – Published: 2025-04-04 18:31 – Updated: 2025-04-04 18:31
VLAI
Details

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in Nikita Advanced WordPress Backgrounds allows Code Injection. This issue affects Advanced WordPress Backgrounds: from n/a through 1.12.4.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-32200"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-80"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-04T16:15:30Z",
    "severity": "MODERATE"
  },
  "details": "Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in Nikita Advanced WordPress Backgrounds allows Code Injection. This issue affects Advanced WordPress Backgrounds: from n/a through 1.12.4.",
  "id": "GHSA-33p4-8hxp-x9pp",
  "modified": "2025-04-04T18:31:01Z",
  "published": "2025-04-04T18:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32200"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/advanced-backgrounds/vulnerability/wordpress-advanced-wordpress-backgrounds-plugin-1-12-4-content-injection-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-34GM-QFWW-6GWM

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

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in WpMultiStoreLocator WP Multi Store Locator allows Reflected XSS. This issue affects WP Multi Store Locator: from n/a through 2.4.7.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-24680"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79",
      "CWE-80"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-27T15:15:15Z",
    "severity": "HIGH"
  },
  "details": "Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in WpMultiStoreLocator WP Multi Store Locator allows Reflected XSS. This issue affects WP Multi Store Locator: from n/a through 2.4.7.",
  "id": "GHSA-34gm-qfww-6gwm",
  "modified": "2026-04-01T18:33:29Z",
  "published": "2025-01-27T15:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24680"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/wp-multi-store-locator/vulnerability/wordpress-wp-multi-store-locator-plugin-2-4-7-cross-site-scripting-xss-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-35F3-PG38-486F

Vulnerability from github – Published: 2026-07-09 21:00 – Updated: 2026-07-09 21:00
VLAI
Summary
YesWiki Vulnerable to Reflected XSS via Unescaped Archived-Revision `time` Parameter in `handlers/page/show.php`
Details

Summary

YesWiki's archived-revision view reflects the time GET parameter into a hidden HTML input in handlers/page/show.php without escaping. Because MySQL coerces malformed DATETIME strings, an attacker can append HTML or JavaScript to a valid archived revision timestamp, still load that archived revision, and execute arbitrary JavaScript in the victim's browser.

The vulnerable form is only rendered when the victim can both read and edit the target page. In restricted deployments this requires a victim with read and write access to that page. On a default doryphore 4.6.5 install, public pages such as PagePrincipale were editable anonymously during validation, so the issue can also affect unauthenticated visitors in that configuration.

Details

The request routing path uses the user-controlled time parameter to load a specific page revision. In includes/YesWiki.php around Run() line 1223, the request is routed through:

$this->SetPage($this->LoadPage($tag, isset($_REQUEST['time']) ? $_REQUEST['time'] : ''));

LoadPage() delegates to PageManager::getOne() in includes/services/PageManager.php around line 75, which builds a SQL predicate directly from the supplied revision time:

$timeQuery = $time ? "time = '{$this->dbService->escape($time)}'" : "latest = 'Y'";

If the loaded page is an archived revision (latest == 'N') and the current user has write access, handlers/page/show.php around lines 43-49 renders an edit form for that archived revision and copies $_GET['time'] into a hidden input without htmlspecialchars():

$time = isset($_GET['time']) ? $_GET['time'] : '';
echo $this->FormOpen(testUrlInIframe() ? 'editiframe' : 'edit', '', 'get');
<input type="hidden" name="time" value="<?php echo $time; ?>" />

That sink is reachable only when all of the following are true:

  1. The target page has at least one archived revision.
  2. The victim can read the target page.
  3. The victim can write the target page, because the archived revision edit form is rendered only inside the if ($this->HasAccess('write')) branch.

In practice, the payload must begin with a real archived revision timestamp. A completely invalid time value does not reach the archived branch because YesWiki only updates the current page object when the revision lookup returns a non-empty row.

During local validation on the official doryphore 4.6.5 package, the exploit worked because MySQL accepted a malformed timestamp string as matching an existing archived revision row. For example, the following expression was coerced to the stored revision time:

CAST(CONCAT('2026-05-24 04:30:00', CHAR(34), CHAR(62), CHAR(60), 'script', CHAR(62), 'alert(1)', CHAR(60), '/script', CHAR(62)) AS DATETIME)

and the corresponding query predicate still matched the archived row:

WHERE time = '2026-05-24 04:30:00"><script>alert(1)</script>'

This means a payload can begin with a valid archived revision timestamp, still resolve to the archived revision, and then be reflected unescaped into the hidden HTML field.

For comparison, tools/bazar/handlers/page/show__.php around lines 13-14 escapes the same time value with htmlspecialchars(), which shows that the core handler's behavior is inconsistent and unsafe.

This issue maps to CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').

PoC

  1. Set up a vulnerable YesWiki instance. This was validated locally on the official doryphore 4.6.5 release.
  2. Use a target page that has at least one archived revision. Any page with revision history is sufficient.
  3. Confirm the victim has the rights needed to reach the vulnerable sink:
  4. The victim must have read access to the page.
  5. The victim must have write access to the page.
  6. On the default validation install, these rights were available anonymously on public pages such as PagePrincipale, so no login was required in that configuration.
  7. Identify the timestamp of an archived revision. In the validated setup, an archived PagePrincipale revision existed at 2026-05-24 04:30:00.
  8. Send the victim a crafted URL that starts with that valid archived revision timestamp and then appends an attribute-breaking payload:
http://127.0.0.1:8085/PagePrincipale?time=2026-05-24%2004:30:00%22%3E%3Cscript%3Ealert(1)%3C/script%3E%3Cinput%20value=%22
  1. Open the URL in a browser as a victim who has the required read and write rights.
  2. Observe that YesWiki still loads the archived revision view and displays the archived-revision warning block, proving the malformed time value matched the stored archived revision.
  3. Inspect the returned HTML. The response contains the injected payload inside the hidden form field:
<input type="hidden" name="time" value="2026-05-24 04:30:00"><script>alert(1)</script><input value="" />
  1. The browser executes the injected JavaScript in the YesWiki origin. A simple payload such as alert(1) demonstrates code execution; a real payload could read browser-accessible data or perform actions in the victim's session.

image

Impact

This is a reflected XSS vulnerability in the archived-revision workflow.

The practical access model is:

  • The attacker only needs to send a crafted link.
  • The victim must have read and write access to the target page.
  • The target page must have at least one archived revision.
  • On deployments where anonymous visitors can edit public pages, the issue can be exploited against unauthenticated visitors as well.

An attacker may be able to:

  • Execute arbitrary JavaScript in the victim's browser.
  • Steal browser-accessible sensitive data.
  • Perform actions as the victim inside YesWiki.
  • Abuse the trusted YesWiki origin for phishing, UI redressing, or follow-on attacks.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "yeswiki/yeswiki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "fixed": "4.6.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52773"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-80"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T21:00:55Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nYesWiki\u0027s archived-revision view reflects the `time` `GET` parameter into a hidden HTML input in `handlers/page/show.php` without escaping. Because MySQL coerces malformed `DATETIME` strings, an attacker can append HTML or JavaScript to a valid archived revision timestamp, still load that archived revision, and execute arbitrary JavaScript in the victim\u0027s browser.\n\nThe vulnerable form is only rendered when the victim can both read and edit the target page. In restricted deployments this requires a victim with `read` and `write` access to that page. On a default `doryphore 4.6.5` install, public pages such as `PagePrincipale` were editable anonymously during validation, so the issue can also affect unauthenticated visitors in that configuration.\n\n### Details\nThe request routing path uses the user-controlled `time` parameter to load a specific page revision. In `includes/YesWiki.php` around `Run()` line `1223`, the request is routed through:\n\n```php\n$this-\u003eSetPage($this-\u003eLoadPage($tag, isset($_REQUEST[\u0027time\u0027]) ? $_REQUEST[\u0027time\u0027] : \u0027\u0027));\n```\n\n`LoadPage()` delegates to `PageManager::getOne()` in `includes/services/PageManager.php` around line `75`, which builds a SQL predicate directly from the supplied revision time:\n\n```php\n$timeQuery = $time ? \"time = \u0027{$this-\u003edbService-\u003eescape($time)}\u0027\" : \"latest = \u0027Y\u0027\";\n```\n\nIf the loaded page is an archived revision (`latest == \u0027N\u0027`) and the current user has `write` access, `handlers/page/show.php` around lines `43-49` renders an edit form for that archived revision and copies `$_GET[\u0027time\u0027]` into a hidden input without `htmlspecialchars()`:\n\n```php\n$time = isset($_GET[\u0027time\u0027]) ? $_GET[\u0027time\u0027] : \u0027\u0027;\necho $this-\u003eFormOpen(testUrlInIframe() ? \u0027editiframe\u0027 : \u0027edit\u0027, \u0027\u0027, \u0027get\u0027);\n\u003cinput type=\"hidden\" name=\"time\" value=\"\u003c?php echo $time; ?\u003e\" /\u003e\n```\n\nThat sink is reachable only when all of the following are true:\n\n1. The target page has at least one archived revision.\n2. The victim can `read` the target page.\n3. The victim can `write` the target page, because the archived revision edit form is rendered only inside the `if ($this-\u003eHasAccess(\u0027write\u0027))` branch.\n\nIn practice, the payload must begin with a real archived revision timestamp. A completely invalid `time` value does not reach the archived branch because YesWiki only updates the current page object when the revision lookup returns a non-empty row.\n\nDuring local validation on the official `doryphore 4.6.5` package, the exploit worked because MySQL accepted a malformed timestamp string as matching an existing archived revision row. For example, the following expression was coerced to the stored revision time:\n\n```sql\nCAST(CONCAT(\u00272026-05-24 04:30:00\u0027, CHAR(34), CHAR(62), CHAR(60), \u0027script\u0027, CHAR(62), \u0027alert(1)\u0027, CHAR(60), \u0027/script\u0027, CHAR(62)) AS DATETIME)\n```\n\nand the corresponding query predicate still matched the archived row:\n\n```sql\nWHERE time = \u00272026-05-24 04:30:00\"\u003e\u003cscript\u003ealert(1)\u003c/script\u003e\u0027\n```\n\nThis means a payload can begin with a valid archived revision timestamp, still resolve to the archived revision, and then be reflected unescaped into the hidden HTML field.\n\nFor comparison, `tools/bazar/handlers/page/show__.php` around lines `13-14` escapes the same `time` value with `htmlspecialchars()`, which shows that the core handler\u0027s behavior is inconsistent and unsafe.\n\nThis issue maps to **CWE-79: Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027)**.\n\n### PoC\n1. Set up a vulnerable YesWiki instance. This was validated locally on the official `doryphore 4.6.5` release.\n2. Use a target page that has at least one archived revision. Any page with revision history is sufficient.\n3. Confirm the victim has the rights needed to reach the vulnerable sink:\n   - The victim must have `read` access to the page.\n   - The victim must have `write` access to the page.\n   - On the default validation install, these rights were available anonymously on public pages such as `PagePrincipale`, so no login was required in that configuration.\n4. Identify the timestamp of an archived revision. In the validated setup, an archived `PagePrincipale` revision existed at `2026-05-24 04:30:00`.\n5. Send the victim a crafted URL that starts with that valid archived revision timestamp and then appends an attribute-breaking payload:\n\n```text\nhttp://127.0.0.1:8085/PagePrincipale?time=2026-05-24%2004:30:00%22%3E%3Cscript%3Ealert(1)%3C/script%3E%3Cinput%20value=%22\n```\n\n6. Open the URL in a browser as a victim who has the required `read` and `write` rights.\n7. Observe that YesWiki still loads the archived revision view and displays the archived-revision warning block, proving the malformed `time` value matched the stored archived revision.\n8. Inspect the returned HTML. The response contains the injected payload inside the hidden form field:\n\n```html\n\u003cinput type=\"hidden\" name=\"time\" value=\"2026-05-24 04:30:00\"\u003e\u003cscript\u003ealert(1)\u003c/script\u003e\u003cinput value=\"\" /\u003e\n```\n\n9. The browser executes the injected JavaScript in the YesWiki origin. A simple payload such as `alert(1)` demonstrates code execution; a real payload could read browser-accessible data or perform actions in the victim\u0027s session.\n\n\u003cimg width=\"1600\" height=\"829\" alt=\"image\" src=\"https://github.com/user-attachments/assets/d0b85a7c-2213-4459-908c-969934f06358\" /\u003e\n\n### Impact\nThis is a **reflected XSS** vulnerability in the archived-revision workflow.\n\nThe practical access model is:\n\n- The attacker only needs to send a crafted link.\n- The victim must have `read` and `write` access to the target page.\n- The target page must have at least one archived revision.\n- On deployments where anonymous visitors can edit public pages, the issue can be exploited against unauthenticated visitors as well.\n\nAn attacker may be able to:\n\n- Execute arbitrary JavaScript in the victim\u0027s browser.\n- Steal browser-accessible sensitive data.\n- Perform actions as the victim inside YesWiki.\n- Abuse the trusted YesWiki origin for phishing, UI redressing, or follow-on attacks.",
  "id": "GHSA-35f3-pg38-486f",
  "modified": "2026-07-09T21:00:55Z",
  "published": "2026-07-09T21:00:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/YesWiki/yeswiki/security/advisories/GHSA-35f3-pg38-486f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/YesWiki/yeswiki/commit/35ad9c2bb6cd338198b37c1f745e24bc302a3560"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/YesWiki/yeswiki"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "YesWiki Vulnerable to Reflected XSS via Unescaped Archived-Revision `time` Parameter in `handlers/page/show.php`"
}

GHSA-36CF-MQ32-6X43

Vulnerability from github – Published: 2024-06-13 15:30 – Updated: 2024-06-13 15:30
VLAI
Details

Verint - CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-36395"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-80"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-13T13:15:49Z",
    "severity": "MODERATE"
  },
  "details": "Verint - CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)",
  "id": "GHSA-36cf-mq32-6x43",
  "modified": "2024-06-13T15:30:35Z",
  "published": "2024-06-13T15:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36395"
    },
    {
      "type": "WEB",
      "url": "https://www.gov.il/en/Departments/faq/cve_advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-36F2-V56Q-6V2J

Vulnerability from github – Published: 2024-03-27 06:30 – Updated: 2024-08-06 18:30
VLAI
Details

An issue was discovered on Supermicro X11SSM-F, X11SAE-F, and X11SSE-F 1.66 devices. An attacker could exploit an XSS issue that affects Internet Explorer 11 on Windows.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-40290"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79",
      "CWE-80"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-27T04:15:10Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered on Supermicro X11SSM-F, X11SAE-F, and X11SSE-F 1.66 devices. An attacker could exploit an XSS issue that affects Internet Explorer 11 on Windows.",
  "id": "GHSA-36f2-v56q-6v2j",
  "modified": "2024-08-06T18:30:49Z",
  "published": "2024-03-27T06:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40290"
    },
    {
      "type": "WEB",
      "url": "https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023"
    },
    {
      "type": "WEB",
      "url": "https://www.supermicro.com/en/support/security_center#%21advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-36HH-HPJF-WC4X

Vulnerability from github – Published: 2026-04-08 09:31 – Updated: 2026-04-14 15:30
VLAI
Details

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in kutethemes DukaMarket dukamarket allows Code Injection.This issue affects DukaMarket: from n/a through <= 1.3.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-39628"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-80"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-08T09:16:33Z",
    "severity": "MODERATE"
  },
  "details": "Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in kutethemes DukaMarket dukamarket allows Code Injection.This issue affects DukaMarket: from n/a through \u003c= 1.3.0.",
  "id": "GHSA-36hh-hpjf-wc4x",
  "modified": "2026-04-14T15:30:29Z",
  "published": "2026-04-08T09:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39628"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Theme/dukamarket/vulnerability/wordpress-dukamarket-theme-1-3-0-arbitrary-shortcode-execution-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-36HP-4X3G-PHRG

Vulnerability from github – Published: 2022-05-01 18:13 – Updated: 2023-09-22 21:05
VLAI
Summary
Apache Tomcat's CookieExample Vulnerable to XSS
Details

Multiple cross-site scripting (XSS) vulnerabilities in examples/servlet/CookieExample in Apache Tomcat 3.3 through 3.3.2 allow remote attackers to inject arbitrary web script or HTML via the (1) Name or (2) Value field, related to error messages.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.3.0"
            },
            {
              "last_affected": "3.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2007-3384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-80"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-22T21:05:24Z",
    "nvd_published_at": "2007-08-08T01:17:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple cross-site scripting (XSS) vulnerabilities in `examples/servlet/CookieExample` in Apache Tomcat 3.3 through 3.3.2 allow remote attackers to inject arbitrary web script or HTML via the (1) Name or (2) Value field, related to error messages.",
  "id": "GHSA-36hp-4x3g-phrg",
  "modified": "2023-09-22T21:05:24Z",
  "published": "2022-05-01T18:13:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-3384"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20070824135030/http://securityreason.com/securityalert/2971"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20071117100258/http://securitytracker.com/alerts/2007/Aug/1018503.html"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20170323011513/http://www.securityfocus.com/bid/25174"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20201207035111/http://www.securityfocus.com/archive/1/475321/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://tomcat.apache.org/security-3.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Apache Tomcat\u0027s CookieExample Vulnerable to XSS"
}

GHSA-36J9-FP7F-7F7M

Vulnerability from github – Published: 2025-02-03 21:31 – Updated: 2025-02-12 21:31
VLAI
Details

Cross-Site Scripting (XSS) vulnerability in Roundcube Webmail 1.6.9 allows remote authenticated users to upload a malicious file as an email attachment, leading to the triggering of the XSS by visiting the SENT session.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-57004"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-80"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-03T19:15:12Z",
    "severity": "MODERATE"
  },
  "details": "Cross-Site Scripting (XSS) vulnerability in Roundcube Webmail 1.6.9 allows remote authenticated users to upload a malicious file as an email attachment, leading to the triggering of the XSS by visiting the SENT session.",
  "id": "GHSA-36j9-fp7f-7f7m",
  "modified": "2025-02-12T21:31:51Z",
  "published": "2025-02-03T21:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57004"
    },
    {
      "type": "WEB",
      "url": "https://github.com/riya98241/CVE/blob/main/CVE-2024-57004"
    },
    {
      "type": "WEB",
      "url": "https://github.com/roundcube/roundcubemail/releases/tag/1.6.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-37FC-XJQ7-FF6P

Vulnerability from github – Published: 2023-07-06 21:14 – Updated: 2024-04-04 05:38
VLAI
Details

The setMediaSource function on the amzn.thin.pl service does not sanitize the "source" parameter allowing for arbitrary javascript code to be run

This issue affects:

Amazon Fire TV Stick 3rd gen versions prior to 6.2.9.5. Insignia TV with FireOS versions prior to 7.6.3.3.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-1384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79",
      "CWE-80"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-03T13:15:09Z",
    "severity": "MODERATE"
  },
  "details": "The setMediaSource function on the amzn.thin.pl service does not sanitize the \"source\" parameter allowing for arbitrary javascript code to be run\n\nThis issue affects:\n\nAmazon Fire TV Stick 3rd gen\u00a0versions prior to 6.2.9.5.\nInsignia TV with FireOS\u00a0versions prior to 7.6.3.3.",
  "id": "GHSA-37fc-xjq7-ff6p",
  "modified": "2024-04-04T05:38:51Z",
  "published": "2023-07-06T21:14:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1384"
    },
    {
      "type": "WEB",
      "url": "https://www.bitdefender.com/blog/labs/vulnerabilities-identified-amazon-fire-tv-stick-insignia-fire-os-tv-series"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Implementation

Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.

Mitigation MIT-30.1
Implementation

Strategy: Output Encoding

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

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

Mitigation MIT-31
Implementation

Strategy: Attack Surface Reduction

To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XmlHttpRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.

CAPEC-18: XSS Targeting Non-Script Elements

This attack is a form of Cross-Site Scripting (XSS) where malicious scripts are embedded in elements that are not expected to host scripts such as image tags (<img>), comments in XML documents (< !-CDATA->), etc. These tags may not be subject to the same input validation, output validation, and other content filtering and checking routines, so this can create an opportunity for an adversary to tunnel through the application's elements and launch a XSS attack through other elements. As with all remote attacks, it is important to differentiate the ability to launch an attack (such as probing an internal network for unpatched servers) and the ability of the remote adversary to collect and interpret the output of said attack.

CAPEC-193: PHP Remote File Inclusion

In this pattern the adversary is able to load and execute arbitrary code remotely available from the application. This is usually accomplished through an insecurely configured PHP runtime environment and an improperly sanitized "include" or "require" call, which the user can then control to point to any web-accessible file. This allows adversaries to hijack the targeted application and force it to execute their own instructions.

CAPEC-32: XSS Through HTTP Query Strings

An adversary embeds malicious script code in the parameters of an HTTP query string and convinces a victim to submit the HTTP request that contains the query string to a vulnerable web application. The web application then procedes to use the values parameters without properly validation them first and generates the HTML code that will be executed by the victim's browser.

CAPEC-86: XSS Through HTTP Headers

An adversary exploits web applications that generate web content, such as links in a HTML page, based on unvalidated or improperly validated data submitted by other actors. XSS in HTTP Headers attacks target the HTTP headers which are hidden from most users and may not be validated by web applications.