CVE-2026-55944 exposes Microsoft Dynamics NAV 2018 and Dynamics 365 Business Central on-premises servers to unauthenticated remote code execution through a specially crafted login request. Microsoft released the fix on July 14, 2026, rates the vulnerability Critical, and assigns it a CVSS 3.1 base score of 9.8 out of 10.
Detailed in Microsoft’s Security Update Guide and corroborated by the National Vulnerability Database, the flaw involves deserialization of untrusted data. A remote attacker needs neither valid credentials nor user interaction, making internet-reachable ERP servers the most urgent patching targets.
Microsoft has assessed exploitation as “More Likely,” according to Tenable’s July Patch Tuesday analysis. No active exploitation or public proof-of-concept code had been reported as of July 15, but that status should not be interpreted as permission to wait.
Microsoft says an attacker can exploit CVE-2026-55944 by sending a malicious login request to an affected Dynamics NAV or Business Central server. The vulnerable software then deserializes attacker-controlled data in a way that can lead to arbitrary code execution over the network.
The classification is CWE-502, Deserialization of Untrusted Data. Deserialization flaws become particularly dangerous when an application reconstructs complex objects from network input without strictly limiting which object types and operations are permitted.
The CVSS vector explains why the score reaches 9.8: the attack is network-accessible, requires low complexity, needs no privileges, and does not depend on a victim clicking or opening anything. Microsoft also assigns high potential impact to confidentiality, integrity, and availability, indicating that successful exploitation could compromise data, alter application behavior, or disrupt the affected service.
Qualys describes the attack path as a specially crafted login request, while the Dutch National Cyber Security Centre warns that Dynamics deployments frequently expose interfaces to the internet. That combination puts the vulnerable request handler close to the edge of many business networks rather than behind a chain of authenticated application workflows.
The likely result is not merely access to one Dynamics account. Remote code execution means the attacker may obtain the ability to run instructions within the security context of the affected server process. The practical reach from there depends on service-account permissions, network segmentation, stored credentials, database access, and any administrative tooling installed on the server.
Administrators should not conclude from that single entry that every Business Central deployment is safe. Microsoft’s title explicitly includes Business Central on-premises, while public vulnerability databases may still be processing or enriching the product data released on July 14.
This distinction matters because Microsoft’s ERP naming and version history span several generations. Dynamics NAV evolved into Dynamics 365 Business Central on-premises, and organizations may use internal inventory names, partner terminology, or legacy deployment records that do not match Microsoft’s current product labels.
The safest process is to identify the installed application version and build directly on each server, then compare it with the affected-product and security-update tables in Microsoft’s Security Update Guide. Asset searches based only on “Business Central” or only on “Dynamics NAV” risk missing systems catalogued under the other name.
NVD currently marks the record as awaiting enrichment. Microsoft, as the assigning authority, has nevertheless confirmed the vulnerability, supplied the technical weakness classification, published the attack vector, and released remediation information. In other words, the lack of a completed NVD analysis reflects database processing, not uncertainty about whether the flaw exists.
That also explains the vulnerability-confidence metric attached to the advisory. The issue is vendor-confirmed rather than based solely on an unverified researcher claim, and enough technical information is public to identify the vulnerable input path and underlying weakness. Exact exploit mechanics have not been published, but attackers already know that the login interface and unsafe deserialization are central to the bug.
That makes a compromised ERP application server useful both as a data target and as a foothold. Even when the Dynamics service account is not a domain administrator, it may hold database rights, access integration shares, communicate with middleware, or run scheduled jobs using credentials unavailable to ordinary users.
Administrators should therefore treat the update as more than routine application maintenance. The absence of authentication and user interaction substantially reduces the number of conditions an attacker must satisfy, while Microsoft’s “More Likely” assessment signals that practical exploitation is considered plausible.
Internet exposure should determine the first wave of remediation. Servers publishing Dynamics web services, APIs, client endpoints, or login interfaces through a firewall, reverse proxy, application delivery controller, or direct NAT rule warrant immediate review.
A reverse proxy is not automatically a mitigation. Unless it validates and rejects the malicious request structure involved in this vulnerability, it may simply relay the payload to the affected application service. Authentication imposed upstream could reduce exposure, but administrators should not substitute an assumed perimeter control for Microsoft’s security update.
Where an update cannot be installed immediately, temporary containment should focus on reducing who can reach the affected services. Restricting access to trusted networks or VPN clients, removing unnecessary public publishing rules, and applying narrowly scoped firewall controls can reduce attack surface while the application patch is tested.
Security teams should also increase monitoring around Dynamics login endpoints and the application server itself. Unexpected child processes, new services or scheduled tasks, unusual outbound connections, changes to application files, and abnormal SQL activity deserve investigation. A failed or unusual login request may be the delivery mechanism even though the attacker does not need a valid account.
That operational boundary is easy to miss in environments where Windows Server patching and ERP maintenance belong to different teams. Endpoint or server-management dashboards may show the operating system as compliant while the Dynamics application remains on an affected build.
Before deployment, administrators should inventory production servers, disaster-recovery nodes, test systems, integration servers, and old instances retained for reporting or historical access. A dormant NAV server can still present a viable entry point if its services remain running and reachable.
Testing should cover authentication, web clients, extensions, partner customizations, job queues, reporting, and database connectivity. Those checks are important for availability, but the severity of the flaw argues for a short test cycle rather than an extended deferral.
Organizations should record the pre-update and post-update Dynamics build numbers instead of relying only on a successful installer exit code. For NAV 2018, the initial CVE data establishes 11.0.50704.0 as the key corrected-version boundary; Business Central operators should use Microsoft’s product-specific update table for their release branch.
CVE-2026-55944 was not listed as actively exploited when Microsoft published it on July 14, 2026. The next meaningful milestone is whether exploit code or observed attacks emerge, but administrators running reachable NAV or Business Central on-premises services should aim to have the application update deployed before that status changes.
Detailed in Microsoft’s Security Update Guide and corroborated by the National Vulnerability Database, the flaw involves deserialization of untrusted data. A remote attacker needs neither valid credentials nor user interaction, making internet-reachable ERP servers the most urgent patching targets.
Microsoft has assessed exploitation as “More Likely,” according to Tenable’s July Patch Tuesday analysis. No active exploitation or public proof-of-concept code had been reported as of July 15, but that status should not be interpreted as permission to wait.
A Login Request Can Cross the Trust Boundary
Microsoft says an attacker can exploit CVE-2026-55944 by sending a malicious login request to an affected Dynamics NAV or Business Central server. The vulnerable software then deserializes attacker-controlled data in a way that can lead to arbitrary code execution over the network.The classification is CWE-502, Deserialization of Untrusted Data. Deserialization flaws become particularly dangerous when an application reconstructs complex objects from network input without strictly limiting which object types and operations are permitted.
The CVSS vector explains why the score reaches 9.8: the attack is network-accessible, requires low complexity, needs no privileges, and does not depend on a victim clicking or opening anything. Microsoft also assigns high potential impact to confidentiality, integrity, and availability, indicating that successful exploitation could compromise data, alter application behavior, or disrupt the affected service.
Qualys describes the attack path as a specially crafted login request, while the Dutch National Cyber Security Centre warns that Dynamics deployments frequently expose interfaces to the internet. That combination puts the vulnerable request handler close to the edge of many business networks rather than behind a chain of authenticated application workflows.
The likely result is not merely access to one Dynamics account. Remote code execution means the attacker may obtain the ability to run instructions within the security context of the affected server process. The practical reach from there depends on service-account permissions, network segmentation, stored credentials, database access, and any administrative tooling installed on the server.
The Public Product List Still Needs Careful Reading
The vulnerability’s Microsoft title covers both Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central on-premises. However, the initial public CVE record specifically identifies Microsoft Dynamics NAV 2018 versions earlier than 11.0.50704.0 as affected.Administrators should not conclude from that single entry that every Business Central deployment is safe. Microsoft’s title explicitly includes Business Central on-premises, while public vulnerability databases may still be processing or enriching the product data released on July 14.
This distinction matters because Microsoft’s ERP naming and version history span several generations. Dynamics NAV evolved into Dynamics 365 Business Central on-premises, and organizations may use internal inventory names, partner terminology, or legacy deployment records that do not match Microsoft’s current product labels.
The safest process is to identify the installed application version and build directly on each server, then compare it with the affected-product and security-update tables in Microsoft’s Security Update Guide. Asset searches based only on “Business Central” or only on “Dynamics NAV” risk missing systems catalogued under the other name.
NVD currently marks the record as awaiting enrichment. Microsoft, as the assigning authority, has nevertheless confirmed the vulnerability, supplied the technical weakness classification, published the attack vector, and released remediation information. In other words, the lack of a completed NVD analysis reflects database processing, not uncertainty about whether the flaw exists.
That also explains the vulnerability-confidence metric attached to the advisory. The issue is vendor-confirmed rather than based solely on an unverified researcher claim, and enough technical information is public to identify the vulnerable input path and underlying weakness. Exact exploit mechanics have not been published, but attackers already know that the login interface and unsafe deserialization are central to the bug.
ERP Exposure Raises the Cost of a Compromise
Dynamics NAV and Business Central servers occupy a sensitive position in enterprise environments. They commonly process financial records, customer and supplier information, inventory, purchasing, invoicing, and operational reporting, often while maintaining direct connectivity to SQL Server and other line-of-business systems.That makes a compromised ERP application server useful both as a data target and as a foothold. Even when the Dynamics service account is not a domain administrator, it may hold database rights, access integration shares, communicate with middleware, or run scheduled jobs using credentials unavailable to ordinary users.
Administrators should therefore treat the update as more than routine application maintenance. The absence of authentication and user interaction substantially reduces the number of conditions an attacker must satisfy, while Microsoft’s “More Likely” assessment signals that practical exploitation is considered plausible.
Internet exposure should determine the first wave of remediation. Servers publishing Dynamics web services, APIs, client endpoints, or login interfaces through a firewall, reverse proxy, application delivery controller, or direct NAT rule warrant immediate review.
A reverse proxy is not automatically a mitigation. Unless it validates and rejects the malicious request structure involved in this vulnerability, it may simply relay the payload to the affected application service. Authentication imposed upstream could reduce exposure, but administrators should not substitute an assumed perimeter control for Microsoft’s security update.
Where an update cannot be installed immediately, temporary containment should focus on reducing who can reach the affected services. Restricting access to trusted networks or VPN clients, removing unnecessary public publishing rules, and applying narrowly scoped firewall controls can reduce attack surface while the application patch is tested.
Security teams should also increase monitoring around Dynamics login endpoints and the application server itself. Unexpected child processes, new services or scheduled tasks, unusual outbound connections, changes to application files, and abnormal SQL activity deserve investigation. A failed or unusual login request may be the delivery mechanism even though the attacker does not need a valid account.
Patch Validation Must Include the Application Build
CVE-2026-55944 is an application vulnerability, so installing July’s Windows cumulative update alone does not establish protection. Dynamics administrators need to deploy the applicable NAV or Business Central security update and verify that the resulting application build is no longer vulnerable.That operational boundary is easy to miss in environments where Windows Server patching and ERP maintenance belong to different teams. Endpoint or server-management dashboards may show the operating system as compliant while the Dynamics application remains on an affected build.
Before deployment, administrators should inventory production servers, disaster-recovery nodes, test systems, integration servers, and old instances retained for reporting or historical access. A dormant NAV server can still present a viable entry point if its services remain running and reachable.
Testing should cover authentication, web clients, extensions, partner customizations, job queues, reporting, and database connectivity. Those checks are important for availability, but the severity of the flaw argues for a short test cycle rather than an extended deferral.
Organizations should record the pre-update and post-update Dynamics build numbers instead of relying only on a successful installer exit code. For NAV 2018, the initial CVE data establishes 11.0.50704.0 as the key corrected-version boundary; Business Central operators should use Microsoft’s product-specific update table for their release branch.
CVE-2026-55944 was not listed as actively exploited when Microsoft published it on July 14, 2026. The next meaningful milestone is whether exploit code or observed attacks emerge, but administrators running reachable NAV or Business Central on-premises services should aim to have the application update deployed before that status changes.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: www2.gov.bc.ca
