Ignite Global Support Home Start a conversation Sign in
Start a conversation
  1. DNN Corp. Customer Support
  2. DNN Articles
  3. Articles

Evoq 9.13.00: “XPath Injection” Scanner Finding on <code>MicrosoftAjax.js</code> (No CVE) and Expected HTTP 200/304 Responses

Overview

In Evoq 9.13.00, security scanners may flag an “XPath Injection” warning against the static JavaScript resource MicrosoftAjax.js, often with no CVE listed. This is commonly the result of pattern-based/static analysis of JavaScript content rather than evidence of an exploitable server-side injection path.

MicrosoftAjax.js is a legitimate Microsoft-provided ASP.NET AJAX client-side library and is expected to be served as a normal script resource, so HTTP 200 OK (or 304 Not Modified) is expected when the file exists; returning 404 or 500 for a valid required resource would be incorrect and can break site functionality.

Key Information

  • Impacted resource reported by scanners: MicrosoftAjax.js (client-served/static script resource).
  • Product/version referenced: Evoq 9.13.00.
  • Scanner output detail: Some tools report “XPath Injection” with no associated CVE.
  • Expected HTTP behavior (when the file exists):
    • 200 OK when the script is successfully served.
    • 304 Not Modified when caching headers apply and the client reuses a cached copy.
  • Why 404/500 is not expected for this case:
    • 404 Not Found is only appropriate when the resource truly does not exist at the requested path.
    • 500 Server Error indicates a server-side failure and is not an appropriate/secure “block response” for a valid existing static file.
    • Intentionally returning 404/500 for valid script resources can break normal site functionality.
  • Why “XPath Injection” is commonly a false positive here: XPath injection is primarily a server-side risk (untrusted input incorporated into server-side XPath queries). Serving a client-side JavaScript library does not, by itself, demonstrate an exploitable server-side injection path in DNN/Evoq.
  • Status/engineering notes: No defect confirmation, engineering escalation, or product fix/version change was identified based on the information provided.

Customer Impact

No application change is required solely because a scanner flags MicrosoftAjax.js for “XPath Injection” without demonstrating a server-side exploit path.

To make a definitive assessment for your specific environment (and determine whether a scanner exception is appropriate), collect the following and review what is actually being requested and returned:

  1. Scanner product name and version (for example: <scanner_vendor> <scanner_name> <scanner_version>).
  2. Exact scanner finding details, including:
    • the full flagged URL/path and any query string (for example: https://your_instance.domain.com/<path>/MicrosoftAjax.js?<query_string>)
    • a screenshot or exported finding output, if available
  3. Whether Telerik components are in use (including via third-party modules/extensions).
  4. HAR capture exported while loading the flagged URL, to confirm:
    • the actual request URL
    • the response status (200/304 vs 404)
    • the response body is the expected script content

Expected outcome: If the request is a normal static resource request for MicrosoftAjax.js and the response is the expected script content with HTTP 200/304, the scanner result is likely a false positive and can be handled via your organization’s exception/acceptance process.

Frequently Asked Questions

1. How can I tell if I’m seeing the same issue?
Your security tool flags “XPath Injection” (often without a CVE) and points to the JavaScript file MicrosoftAjax.js being served from your Evoq site, even though the request is a normal static script request.
2. Why doesn’t the site return HTTP 404 or 500 for requests to MicrosoftAjax.js?
If MicrosoftAjax.js exists at the requested path, the correct behavior is to serve it successfully (HTTP 200 OK) or indicate caching (HTTP 304 Not Modified). 404 is only appropriate when the resource does not exist, and 500 indicates a server error—neither is appropriate for a valid required script resource.
3. What information is needed to confirm whether the XPath Injection report is a false positive?
Collect: (1) scanner name/version, (2) the exact flagged URL/path including any query string plus a screenshot/export of the finding, (3) whether Telerik components are in use, and (4) a HAR capture while loading the flagged URL.
4. Does the presence of “XPath” patterns inside a JavaScript file prove a server-side XPath injection vulnerability?
No. Pattern-based/static scanning can flag keywords or constructs in JavaScript. XPath injection risk is primarily server-side (untrusted input used in server-side XPath queries), and a client-side library being served does not by itself prove an exploitable server-side injection path.
5. What should I do if the scanner vendor insists it is exploitable?
Provide the collected evidence (exact URL, HAR, and finding details) and request concrete validation from the vendor (for example, where the exploit would execute and under what conditions). If the report is strictly heuristic without a demonstrated exploit path, treat it as a likely false positive and handle it according to your organization’s exception/acceptance process.
Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Priyanka Bhotika

  2. Posted
  3. Updated

Comments