Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
.NET NuGet

GHSA-8rq5-wwpp-fmj2

HIGH

GHSA-8rq5-wwpp-fmj2 is a high-severity (CVSS 7.3) Cross-site Scripting (XSS) vulnerability in YAFNET.Core. O3 Security confirms whether GHSA-8rq5-wwpp-fmj2 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

YAFNET has Stored XSS in Forum Thread Posts/Replies that Allows Arbitrary JavaScript Execution for All Thread Viewers

Also known asCVE-2026-43939
Published
May 5, 2026
Updated
May 13, 2026
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed

Blast Radius

2 pkgs affected
.NETYAFNET.Core.NETYAFNET.Core

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.

Description

Description: Stored Cross-Site Scripting (XSS) occurs when user-supplied input is persisted by the application and later rendered in another user's browser without proper sanitization or contextual output encoding. When the vulnerable sink is a high-traffic surface such as a public forum thread, the payload executes in the browser of every user who visits the page, maximizing both reach and impact. Any JavaScript injected through such a sink runs under the application's origin and inherits the privileges of whichever user happens to view the affected content.

Issue Details: The thread posting and reply feature accepts user-supplied content that is stored server-side and later rendered back into the thread page without adequate HTML sanitization or contextual output encoding. Submitting a post or reply containing "><img src=x onerror=prompt(0)> causes the payload to break out of the surrounding HTML context and inject a fully attacker-controlled <img> element whose onerror handler fires automatically as soon as the broken image reference fails to load. Because posts and replies are visible to every user who visits the thread, authenticated or otherwise, the injected JavaScript executes in each viewer's browser the moment the page renders, with no additional interaction required.

Impact: An attacker with a standard forum account can execute arbitrary JavaScript in the browser of every user who loads the affected thread, including moderators and administrators. This enables session/auth-cookie theft, account takeover through same-origin state-changing requests, forced privileged actions if an administrator views the thread, credential phishing via injected login overlays, forum defacement, cryptominer or malware delivery, and mass redirection of viewers to attacker-controlled sites. Because the payload triggers automatically on page load rather than requiring hover or click interaction, a single malicious post can compromise a large number of users very quickly.

Likelihood: Exploitation requires only a registered account with permission to post or reply, which is available to every forum member by default. Once posted, the payload fires automatically for any visitor who opens the thread, requiring zero victim interaction and making the overall likelihood high.

Steps to Reproduce:

  • Log in to the forum as any low-privileged user (Attacker).
  • Navigate to any thread where posting or replying is allowed, or create a new thread.
  • In the post/reply body, submit the payload: "><img src=x onerror=prompt(0)>
  • Publish the post or reply.
  • Log in as a different user (e.g., Admin) or visit the thread in a separate browser session.
  • Open the thread page, the injected <img> fails to load and the onerror handler fires, producing a prompt(0) dialog and confirming arbitrary JavaScript execution in the viewer's session context.
<img width="1127" height="745" alt="image" src="https://github.com/user-attachments/assets/b93442ea-1d8e-4079-ab4f-e52d41d110f3" />

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
.NETNuGetYAFNET.Core4.0.0-beta01&&< 4.0.54.0.5
.NETNuGetYAFNET.Coreall versions3.2.12

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for YAFNET.Core. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update YAFNET.Core to 4.0.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8rq5-wwpp-fmj2 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-8rq5-wwpp-fmj2 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-8rq5-wwpp-fmj2. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

**Description:** Stored Cross-Site Scripting (XSS) occurs when user-supplied input is persisted by the application and later rendered in another user's browser without proper sanitization or contextual output encoding. When the vulnerable sink is a high-traffic surface such as a public forum thread, the payload executes in the browser of every user who visits the page, maximizing both reach and impact. Any JavaScript injected through such a sink runs under the application's origin and inherits the privileges of whichever user happens to view the affected content. **Issue Details:** The thread
O3 Security · Impact-Aware SCA

Is GHSA-8rq5-wwpp-fmj2 in your dependencies?

O3 detects GHSA-8rq5-wwpp-fmj2 across NuGet dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.