Vulnerability Analysis

CVE-2026-42898: Microsoft Dynamics 365 On-Premises RCE — What It Is & How to Fix It

Executive Summary

CVE-2026-42898 is a code injection vulnerability in Microsoft Dynamics 365 (on-premises) that allows any low-privileged authenticated user to execute arbitrary code on the server over the network — no admin rights, no user interaction required. Patched in Microsoft's May 2026 Patch Tuesday (May 12, 2026) with a CVSS score of 9.9, this is the highest-severity vulnerability from that release cycle that demands customer-side patching. Because Dynamics 365 environments routinely integrate with identity providers, financial systems, and enterprise workflows, exploitation here can rapidly spiral into a full organizational breach.

1. What Is This Vulnerability?

CVE-2026-42898 is classified as Improper Control of Code Generation (CWE-94) — commonly known as code injection — in Microsoft Dynamics 365 On-Premises. The root cause lies in how Dynamics 365 handles serialized process session data: an authenticated user can craft and submit malicious session state objects that the server subsequently deserializes and executes without adequate validation.

In practical terms, the Dynamics CRM application stores process session state on a per-user basis. An attacker who can authenticate to the system — even with the lowest-privilege "read" account — can tamper with that session state in a way that causes the server to execute attacker-controlled code when it next processes the session. The code runs in the context of the Dynamics application service account, which typically has broad access to databases, connected line-of-business systems, and sometimes Active Directory.

Attack Vector

Property Value
Attack Vector Network
Attack Complexity Low
Privileges Required Low (any authenticated user)
User Interaction None
Scope Changed (can impact resources outside the vulnerable component)
Confidentiality / Integrity / Availability Impact High / High / High

The "Scope: Changed" designation is what pushes this to 9.9. It means a successful attacker is not confined to the CRM application's security boundary — they can potentially pivot into databases, integrated services, and adjacent systems from a single foothold.

Attack Walkthrough

  1. Attacker authenticates to Dynamics 365 with a low-privileged account (e.g., a regular sales user).
  2. Attacker intercepts or crafts a process session update request to the CRM backend API.
  3. Attacker injects a malicious payload into the serialized session state object — for example, a .NET deserialization gadget chain or a specially formatted expression in the CRM workflow engine.
  4. The Dynamics server deserializes and processes the session data without proper sanitization, executing the embedded payload.
  5. Arbitrary code runs on the server as the CRM service account.

Real-World Impact

While no confirmed in-the-wild exploitation has been reported as of this writing, the combination of low privilege requirement, no user interaction, and scope change makes this a high-priority target for ransomware operators and advanced persistent threat (APT) groups. Organizations running Dynamics 365 On-Premises that are interconnected with ERP systems, Active Directory, or financial databases face the greatest risk of lateral movement following initial compromise.

2. Who Is Affected?

Affected: Microsoft Dynamics 365 On-Premises (all supported versions prior to the May 12, 2026 security update).

Not affected:

  • Microsoft Dynamics 365 Online (cloud-hosted via Microsoft 365 / Azure) — Microsoft confirmed this variant is not vulnerable.
  • Organizations that have already applied the May 2026 Patch Tuesday cumulative updates.

Risk amplifiers:

  • Dynamics 365 servers exposed directly to intranet without WAF or reverse proxy.
  • Environments where the CRM service account has Domain Admin or DBA-level privileges.
  • Deployments integrated with Azure AD Connect, Exchange, SharePoint, or SQL Server.
  • Organizations where many internal users have basic Dynamics 365 login credentials (large sales/customer service teams).

3. How to Detect It (Testing)

Manual Testing Steps

  1. Enumerate your Dynamics 365 deployment type: Confirm whether you are running On-Premises or Online. Navigate to Settings → About in Dynamics 365 and check the version and deployment label. Online deployments are not vulnerable.

  2. Check the current build version: Compare your installed version against Microsoft's Security Update Guide for CVE-2026-42898. If your build predates the May 12, 2026 patch, you are vulnerable.

  3. Review service account privileges: Identify the account under which the Dynamics 365 application pool and backend services run (typically in IIS and Windows Services). Determine if this account has elevated AD or SQL privileges — this determines breach impact.

  4. Inspect session handling endpoints: Review IIS request logs (C:\inetpub\logs\LogFiles\) for unusual POST requests to Dynamics internal API endpoints (e.g., /XRMServices/, /api/data/), particularly from unexpected source IPs or at unusual hours.

  5. Check for anomalous process spawning: Use Sysmon or Windows Event Logging (Event ID 4688) to look for child processes unexpectedly spawned by the Dynamics application pool worker (w3wp.exe). Legitimate CRM operation does not typically spawn cmd.exe, powershell.exe, or wscript.exe as children of IIS.

Automated Scanning

Nessus / Tenable.io

  • Plugin search: Dynamics 365 CVE-2026-42898
  • Run a credentialed authenticated scan against your Dynamics server, targeting the Microsoft Dynamics plugin family.
  • Expected output: "Remote Code Execution — patch missing" if unpatched.

Qualys VMDR

  • QID for Microsoft May 2026 Patch Tuesday should flag CVE-2026-42898 under the Microsoft Dynamics 365 detection category.
  • Run an authenticated Windows scan against the host.

Microsoft Defender for Identity / Microsoft Sentinel

  • Create an analytics rule to alert on process creation events where ParentProcessName contains w3wp.exe and NewProcessName matches suspicious executables (cmd.exe, powershell.exe, mshta.exe, wscript.exe, cscript.exe).

Sysinternals Sysmon (Detection Rule):

<RuleGroup name="CRM_RCE_Detection" groupRelation="and">
  <ProcessCreate onmatch="include">
    <ParentImage condition="contains">w3wp.exe</ParentImage>
    <Image condition="contains any">cmd.exe;powershell.exe;wscript.exe;mshta.exe</Image>
  </ProcessCreate>
</RuleGroup>

Code Review Checklist

For development teams maintaining Dynamics 365 customizations or plugins:

  • Review all custom workflow activities and plugins for use of BinaryFormatter, SoapFormatter, or other insecure .NET deserializers — replace with System.Text.Json or DataContractSerializer with known-type lists.
  • Audit custom API endpoints that accept session or context objects as input — ensure they validate and whitelist acceptable types.
  • Confirm that no custom code passes unvalidated user-controlled strings into Process.Start(), Assembly.Load(), Activator.CreateInstance(), or similar reflection/execution APIs.
  • Verify that the Dynamics application pool identity follows the principle of least privilege (dedicated low-privilege service account, not NETWORK SERVICE or LocalSystem).

4. How to Fix It (Mitigation)

Step-by-Step Remediation

  1. Apply the May 2026 Patch Tuesday update immediately. Download the cumulative update for your specific Dynamics 365 On-Premises version from the Microsoft Update Catalog or through Windows Server Update Services (WSUS). The MSRC advisory for CVE-2026-42898 links directly to the applicable KB articles.

  2. Validate update installation. After applying the patch, confirm the updated version string in Settings → About in Dynamics 365 matches or exceeds the version listed in the MSRC advisory.

  3. Restart affected services. Restart the Dynamics 365 IIS application pool and associated Windows services (e.g., Microsoft Dynamics CRM Asynchronous Processing Service, Microsoft Dynamics CRM Sandbox Processing Service) to ensure the patched binaries are loaded.

  4. Audit and reduce service account privileges. Before or immediately after patching, verify the Dynamics service account does not hold excess privileges. Restrict to the minimum required: local service rights on the CRM server, read/write to the CRM databases only, no domain admin rights.

  5. Deploy network segmentation. If patching cannot happen within 24 hours, immediately place the Dynamics 365 server behind a network access control layer that restricts authenticated access to known internal IP ranges only. Block direct internet exposure.

  6. Enable WAF rules for CRM API endpoints. Deploy or update Web Application Firewall policies to inspect traffic to /XRMServices/, /api/data/, and other Dynamics API paths. Block requests containing known deserialization gadget patterns or anomalous payloads.

  7. Test in staging, then push to production. Apply the patch in a staging environment that mirrors your production configuration, run your standard Dynamics 365 functional test suite, confirm no regressions, then promote to production.

Code Fix Example

Vulnerable pattern (insecure deserialization in a custom Dynamics plugin):

// VULNERABLE: Using BinaryFormatter on user-controlled data
BinaryFormatter formatter = new BinaryFormatter();
using (MemoryStream ms = new MemoryStream(sessionData))
{
    var obj = formatter.Deserialize(ms); // Attacker can inject malicious object
    ProcessSessionState(obj);
}

Fixed pattern (safe deserialization):

// SAFE: Use DataContractSerializer with explicitly known types
var knownTypes = new List<Type> { typeof(SessionState), typeof(WorkflowContext) };
var serializer = new DataContractSerializer(typeof(SessionState), knownTypes);
using (MemoryStream ms = new MemoryStream(sessionData))
{
    // Only accepted known types will deserialize — unknown payloads throw exception
    var obj = (SessionState)serializer.ReadObject(ms);
    ProcessSessionState(obj);
}

Configuration Hardening

  • IIS Application Pool Identity: Set to a dedicated CRM_SVC domain account with no interactive logon rights (Deny log on locally GPO).
  • Disable unnecessary Dynamics modules: In IIS, disable any Dynamics application extensions not in active use.
  • Enable Windows Defender Credential Guard: Prevents credential extraction from LSASS if the service account is compromised.
  • SQL Server: Use SQL Server contained database users for the CRM databases rather than domain accounts — limits AD-connected lateral movement.
  • TLS only: Ensure Dynamics 365 IIS bindings are HTTPS-only; disable HTTP bindings to prevent plaintext session interception.

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: Authenticate as a low-privileged Dynamics user and perform normal CRM workflow operations (create/update/close a record, run a custom workflow). Confirm all operations complete successfully with the patch applied.
  • Scenario B: Use a network proxy (Burp Suite in a controlled lab environment) to submit a crafted session state payload to the Dynamics API endpoint. Confirm the server returns a 400 Bad Request or throws a validation error — and does not execute any code.
  • Scenario C: Run your organization's existing Dynamics 365 regression test suite (UAT scripts). Confirm that all existing business functionality is unaffected by the patch.

Security Test Cases

Test Case 1: Verify the vulnerability is patched

  • Precondition: Patch applied and services restarted.
  • Steps: Submit a POST request to /XRMServices/2011/Organization.svc with a known deserialization gadget payload (e.g., a ysoserial.net generated ObjectDataProvider chain) as the session body.
  • Expected Result: Server returns an HTTP 400 or 500 error without executing the payload. No child processes spawned from w3wp.exe.

Test Case 2: Verify authenticated low-privilege access cannot escalate

  • Precondition: Patch applied. Test account with minimal "Read" role in Dynamics.
  • Steps: Attempt to POST modified session data to CRM process APIs.
  • Expected Result: Server rejects the modified data, returns an authorization or validation error.

Test Case 3: Confirm no service degradation

  • Precondition: Patch applied.
  • Steps: Execute full Dynamics 365 functional smoke test — login, record creation, workflow execution, report generation, integration calls.
  • Expected Result: All operations complete normally with no errors.

Automated Security Test (PowerShell — safe validation probe)

# Safe probe: sends benign but structurally anomalous session payload
# Run this from an internal network test host against a patched server
$uri = "https://<your-dynamics-host>/XRMServices/2011/Organization.svc"
$headers = @{
    "Content-Type" = "application/soap+xml"
    "Authorization" = "Bearer <valid_low_priv_token>"
}
$anomalousBody = "<s:Envelope xmlns:s='http://schemas.xmlsoap.org/soap/envelope/'><s:Body><INVALID_SESSION_INJECTION/></s:Body></s:Envelope>"

try {
    $response = Invoke-WebRequest -Uri $uri -Method POST -Headers $headers -Body $anomalousBody -ErrorAction Stop
    Write-Output "Unexpected 2xx response — investigate further: $($response.StatusCode)"
} catch {
    Write-Output "Expected rejection received: $($_.Exception.Response.StatusCode) — patch appears effective."
}

6. Prevention & Hardening

Best Practices

  • Patch cadence discipline: Subscribe to the Microsoft Security Update Guide RSS feed and treat Critical/CVSS 9.0+ on enterprise software as a 24-48 hour patching SLA. For Dynamics 365 On-Premises, maintain a tested patch pipeline so cumulative updates can be deployed within this window.
  • Least privilege service accounts: Enforce a strict policy that application service accounts (IIS app pools, Windows services) never hold Domain Admin, SQL sysadmin, or Global Admin roles. Audit these quarterly.
  • Network micro-segmentation: CRM servers should only be reachable from known internal IP ranges or VPN-gated connections. No direct internet exposure of Dynamics API endpoints.
  • Authenticated access auditing: Enable and retain Dynamics 365 audit logs (Settings → Auditing). Configure alerts for unusual off-hours logins, bulk record reads, or API calls from unexpected IPs.
  • Zero-trust internal network posture: Treat internal authenticated requests to sensitive APIs (like CRM session endpoints) with the same skepticism as external traffic — apply WAF inspection, rate limiting, and anomaly detection.
  • Dependency inventory: Maintain an up-to-date inventory of all Dynamics 365 plugins, custom workflow activities, and third-party integrations. Each represents an attack surface that needs independent security review.

Monitoring & Detection

To detect active exploitation attempts, configure the following alerts in your SIEM (Sentinel, Splunk, Elastic):

Alert 1: Suspicious child process from IIS

EventID == 4688 AND ParentProcessName CONTAINS "w3wp.exe"
  AND NewProcessName MATCHES (cmd.exe|powershell.exe|wscript.exe|mshta.exe|certutil.exe|bitsadmin.exe)

Alert 2: Unusual Dynamics API POST volume

  • Baseline normal API call rates per user per hour. Alert on users exceeding 3x baseline, especially to /XRMServices/ or /api/data/ endpoints.

Alert 3: Service account logon anomaly

  • Alert on any interactive logon (Event ID 4624, Logon Type 2 or 10) by the Dynamics CRM service account — service accounts should never log in interactively.

Alert 4: New process network connection from CRM host

  • Alert on outbound network connections from the Dynamics server to external IPs initiated by non-Dynamics processes — potential indicator of post-exploitation C2 beaconing.

References

Latest from the blog

See all →