CVE-2026-33103: Dynamics 365 On-Premises Local Info Disclosure Risk (CVSS 5.5)

Microsoft has added a new Dynamics 365 on-premises vulnerability to its security roster, and the early signals point to a local information disclosure flaw with a medium CVSS score of 5.5. The issue, tracked as CVE-2026-33103, is described as an improper access control problem that could let an authorized attacker disclose sensitive information from a local system. At this stage, the public technical detail is limited, but the advisory footprint is enough to put administrators of on-premises Dynamics deployments on alert. (cvefeed.io)

Background​

Microsoft Dynamics 365 on-premises has long lived in a different security and servicing world than its cloud counterpart. Organizations that still run it are often doing so because of regulatory constraints, deep integrations, or a desire to keep data and application logic inside their own environment. That makes any access-control flaw especially important, because on-premises deployments usually sit closer to internal identities, service accounts, and data stores than cloud tenants do.
The new CVE lands in a product line that Microsoft has committed to support for years to come. Microsoft’s lifecycle guidance says Dynamics 365 for Customer Engagement Apps, version 9.x (on-premises update) remains in support through January 12, 2027 for Mainstream Support and January 9, 2029 for Extended Support. That matters because customers still have a patch path, but it also means many enterprises will remain exposed to the operational burden of securing a legacy on-premises stack for the foreseeable future.
The practical risk profile of on-premises Dynamics has changed over time. In the cloud era, a lot of organizations assume the hard security problems have shifted to the provider. On-premises customer engagement environments break that assumption: the enterprise still owns authentication, segmentation, host hardening, backup hygiene, and patch timing. An information disclosure issue in this setting may not sound dramatic at first glance, but it can become a stepping stone for credential theft, lateral movement, or internal reconnaissance.
Microsoft has historically issued multiple security fixes for Dynamics 365 on-premises, including earlier disclosure and bypass issues, which reinforces a recurring pattern: this is a product family that remains attractive to attackers precisely because many deployments are not internet-native, yet are still deeply connected to business-critical data. The combination of older architecture, privileged integrations, and long-lived internal trust relationships makes quiet bugs disproportionately valuable. That context is why even a medium-severity CVE deserves careful attention.

---

What Microsoft Says So Far​

The current public description for CVE-2026-33103 is brief but meaningful. cvefeed’s listing, which points back to Microsoft’s advisory page, says “Improper access control in Microsoft Dynamics 365 (on-premises) allows an authorized attacker to disclose information locally.” The vulnerability is also tagged to CWE-284: Improper Access Control, which places it squarely in the category of authorization failures rather than memory corruption or remote code execution. (cvefeed.io)
That wording matters. It suggests the attack does not depend on brute-force exploitation over the network or a user-click phishing chain. Instead, the threat model is a user who already has some level of access on the system and can misuse that access to obtain information they should not be able to see. In other words, the problem is not necessarily entry; it is boundary enforcement once the attacker is already inside the trust perimeter. (cvefeed.io)

Why “authorized attacker” matters​

The phrase authorized attacker often makes readers underestimate the impact, but in enterprise environments it should do the opposite. A low-privileged account, service operator, support user, or compromised internal workstation can still be enough to make a local flaw dangerous. If the disclosed data includes session material, tokens, customer records, configuration values, or identity-linked metadata, the downstream consequences can extend well beyond one application instance. (cvefeed.io)
The CVSS vector published alongside the CVE is AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, which translates to a local attack vector, low complexity, low privileges required, no user interaction, unchanged scope, and a high confidentiality impact with no direct integrity or availability impact. That profile is classic for a data exposure issue: the danger is what can be read, not what can be altered or broken. (cvefeed.io)

• Local attack vector means the attacker needs a foothold on the system or equivalent local access.
• Low privileges required means the bar is not high once the attacker is inside.
• High confidentiality impact means the leak could be materially sensitive.
• No user interaction means the exploit path is operational rather than social.
• No integrity or availability impact means defenders may miss it if they only watch for disruption. (cvefeed.io)

What we do not know yet​

Microsoft’s public advisory page is referenced by the CVE listing, but the available public text is still sparse. We do not yet have a detailed exploit narrative, affected build range, or specific data type that can be disclosed. That uncertainty is important: the lack of public exploit details is not the same thing as low risk; it often just means the vendor has kept the description intentionally narrow while the patch cycle begins. (cvefeed.io)

---

Severity and Exploitability​

The assigned CVSS 5.5 score places CVE-2026-33103 in the medium range, but that should not be read as “minor.” In enterprise security, medium issues often turn into major incidents when they are embedded in privileged internal systems. An information disclosure bug in a CRM or customer engagement platform can expose contact data, ticket history, account relationships, API secrets, or operational notes that attackers can later use elsewhere. (cvefeed.io)
The exploitability profile also matters. Because the vector is local and requires low privileges, this is the kind of issue that becomes more relevant after an attacker has already established a foothold. That means the vulnerability may show up in post-compromise activity, not necessarily as the first stage of intrusion. In practical terms, it is a persistence-and-escalation enabler for an intruder already moving through the environment. (cvefeed.io)

Why confidentiality-only bugs are still serious​

Confidentiality-only vulnerabilities are sometimes dismissed because they do not directly crash servers or corrupt records. That is a mistake. In a CRM system, confidential data can be operational gold: customer identities, internal workflows, notes about incidents, and business context that can be weaponized in later social engineering. A leak from a single on-premises instance may therefore create a broader trust failure than its CVSS number suggests. (cvefeed.io)
There is also a defensive visibility problem. When a vulnerability has no immediate availability impact, it may not produce a noisy alert trail. Organizations that have invested heavily in uptime monitoring may still miss subtle disclosure activity if they do not track access anomalies, privilege misuse, or unusual local session behavior. That asymmetry is one reason quiet bugs often linger longer in production than more obvious ones. (cvefeed.io)

• Medium severity does not mean low business impact.
• Local privilege requirements do not guarantee low real-world risk.
• Confidentiality leaks often aid later-stage intrusion.
• Application-layer issues can evade traditional uptime monitoring.
• Internal trust models are the weak point in many on-prem environments. (cvefeed.io)

The present exploit landscape​

At the time the public listings were surfaced, neither cvefeed nor Feedly showed evidence of a public proof of concept or confirmed exploitation. Feedly specifically notes there is no evidence of a public proof-of-concept and no evidence of exploitation at the moment. That is reassuring, but only in the narrowest sense; early CVE lifecycle gaps often close quickly once researchers and vulnerability brokers have a chance to inspect the vendor advisory. (feedly.com)

---

Why Dynamics 365 On-Premises Remains a Risk Magnet​

Dynamics 365 on-premises persists because some organizations simply cannot move everything to the cloud. That can be due to data residency, legacy customizations, hybrid identity design, or compliance obligations. Those same reasons also create a defensive burden: every exception to cloud standardization reintroduces variability, and variability is where security mistakes tend to accumulate.
The broader market trend has been to push business applications into hosted or managed models, where Microsoft and other vendors can patch at scale. Yet the remaining on-premises cohort is often the hardest to secure because it includes older customizations, bespoke integrations, and organizations that patch only after validation windows. In that environment, an information disclosure bug can survive longer than it should simply because the deployment is important enough to hesitate on, but old enough to be brittle.

Internal trust assumptions are the real target​

Most on-premises enterprise applications rely on a generous trust model. Administrators, service accounts, and internal users often have more access than they strictly need because the system was designed around productivity first. Improper access control vulnerabilities abuse that philosophy by finding cracks between intended authorization boundaries and the actual code path. (cvefeed.io)
This is why the vulnerability class is important. CWE-284 is not a random label; it is a clue that the issue likely lies in how identity, role, or object-level permission checks are enforced. Bugs in this family can be subtle, because they may only appear under certain roles, UI paths, or server-side execution contexts. That makes them harder to catch in ordinary functional testing. (cvefeed.io)

• On-premises deployments carry higher configuration variance.
• Legacy customizations can complicate patch validation.
• Internal privilege models are often overbroad.
• Authorization bugs are harder to detect than crashes.
• Object-level leaks can persist in niche workflows. (cvefeed.io)

Enterprise vs. consumer exposure​

This is not a consumer PC bug, so the impact model is different. Enterprises should think about tenant-like internal segmentation, while consumers should think about whether their data might sit behind a business that still runs Dynamics locally. The latter matters because a vulnerability in a vendor’s on-premises CRM can still expose customer information even if end users never install the software themselves. (cvefeed.io)

---

Patch and Response Posture​

The first priority for defenders is simple: identify whether any internal instance is running a vulnerable Dynamics 365 on-premises build and confirm whether Microsoft’s April 14, 2026 security update has been applied. Feedly’s listing states that patches are available and that affected systems should be brought to version 9.1.0044.0015 or later. That specific version target is an operationally useful clue even before broader advisory details arrive. (feedly.com)
Because the issue is local and authorization-related, patching should be paired with access review. Organizations should not assume the absence of network exposure means the risk is contained. A compromised internal account, a jump host, or a contractor laptop can all become local attack platforms, so least privilege and endpoint control remain part of the remediation story. (feedly.com)

Practical remediation sequence​

A disciplined response to this sort of vulnerability usually follows a short, repeatable sequence. First verify the affected build; then deploy the vendor fix; then audit local access paths and admin roles; and finally look for unusual reads or exports around sensitive Dynamics objects. That order matters because the patch removes the bug, but the audit helps determine whether someone may already have abused it. (feedly.com)

• Inventory all Dynamics 365 on-premises instances.
• Verify the exact build and patch level.
• Apply Microsoft’s April 14, 2026 update.
• Restrict local access to only required personnel.
• Review low-privilege account activity for anomalies.
• Check whether any sensitive records were accessed unusually. (feedly.com)

Why patching alone is not enough​

Patch management closes the known hole, but access-control flaws deserve post-patch review because they often reveal a larger policy weakness. If a low-privilege account could read sensitive data through an unintended path, then the privilege model may be too broad elsewhere too. Security teams should treat the CVE as a trigger for broader authorization hygiene, not a one-off maintenance ticket. (cvefeed.io)

---

What the CVE Suggests About Microsoft’s Security Story​

The release of CVE-2026-33103 also says something broader about Microsoft’s enterprise software estate. Even as the company pushes customers toward cloud services, it must continue servicing and securing long-tail on-premises products that remain deeply embedded in business operations. That makes the security burden dual-track: cloud offerings must stay hardened, while legacy on-premises systems must remain patchable and comprehensible.
The Dynamics 365 family has seen recurring security advisories over the years, and that pattern is not unusual for mature enterprise platforms. Complex business logic, backward compatibility, and customized deployments create a large attack surface that is difficult to eliminate entirely. When a vendor keeps shipping security fixes for the same product line over multiple years, it is a sign of both ongoing support and continuing structural complexity.

Competitive implications​

For Microsoft’s rivals, this vulnerability reinforces a familiar sales argument: cloud-managed services can standardize patching and reduce local exposure. But that argument is only persuasive if the customer can actually migrate, and many cannot do so quickly. In the meantime, the existence of another on-premises disclosure flaw may strengthen the case for modernization projects, security budget approvals, and application rationalization.

The subtle cost of legacy continuity​

There is a hidden cost to continuity. Every extra year an on-premises platform remains in service increases the odds that customers will encounter a patch window, a config drift, or a security exception they did not expect. That is not a criticism of Microsoft alone; it is the natural consequence of keeping mission-critical software alive across long product cycles. Still, the security math gets harder with each year of operational dependence.

• Long-lived enterprise software accumulates configuration debt.
• Security fix cadence becomes dependent on local operations.
• Hybrid environments widen the trust boundary.
• Modernization pressure increases after every notable CVE.
• Vendor support does not eliminate customer responsibility.

---

Threat Hunting Considerations​

Even without public exploit evidence, defenders should think about what abuse would look like if this flaw were targeted internally. An attacker who already has local access may attempt to enumerate data beyond their normal role, access administrative or diagnostic interfaces, or extract records from views that are normally filtered by business logic. In a CRM context, small anomalies can matter more than large ones. (cvefeed.io)
Log correlation is especially valuable here. Access by low-privilege accounts outside normal work hours, repeated navigation through sensitive object types, and atypical export patterns can all be indicators that someone is probing for data exposure opportunities. Because this CVE is not an availability event, the threat hunt should focus on who read what rather than what broke. (feedly.com)

What defenders should examine​

Security and operations teams should concentrate on authorization-sensitive telemetry first. That includes application logs, identity provider events, endpoint access logs, and any export or report-generation trails associated with Dynamics. If the organization has centralized logging, this is a good time to check whether those sources are actually being retained long enough to answer retrospective questions. (feedly.com)

• Low-privilege user sessions during unusual hours.
• Repeated access attempts to restricted records.
• Unexpected report generation or bulk export activity.
• Access from jump hosts or service workstations.
• Any correlated change in identity or endpoint posture. (feedly.com)

Hunting limitations​

There is also a practical limitation: if the bug only leaks data through a subtle application path, telemetry may be incomplete. Many enterprises log authentication events more reliably than object-level reads, and that gap can leave blind spots. For that reason, post-patch validation should include a review of logging completeness, not just a search for active exploitation. (cvefeed.io)

---

Strengths and Opportunities​

The good news is that this CVE appears to be straightforward to manage if organizations act quickly. Microsoft has already published the advisory entry, the issue is not described as remotely exploitable, and the available public guidance points to a patchable release path. For security teams that maintain disciplined asset inventories, this is exactly the kind of issue where process maturity pays off. (cvefeed.io)

• The vulnerability is publicly identified with a clear CVE.
• Microsoft has provided a patch path.
• The attack is local, not openly remote.
• There is no public proof-of-concept evidence yet.
• The CVSS profile makes prioritization easier.
• This is a good moment to review least-privilege design.
• The issue can help justify modernization planning. (feedly.com)

Risks and Concerns​

The downside is that local disclosure flaws often hide in plain sight after patch day, especially in environments where internal access is broad and logging is incomplete. Because the CVE emphasizes confidentiality rather than integrity or availability, some teams may underreact until they realize what data was actually exposed. That is exactly the kind of assumption adversaries rely on. (cvefeed.io)

• Internal users may be overtrusted by default.
• Service accounts can amplify local access.
• Sensitive CRM data can be operationally and legally material.
• Patch delays are common in customized on-prem environments.
• Confidentiality leaks can seed later-stage compromise.
• Monitoring stacks may miss object-level disclosure.
• Legacy complexity makes root-cause review slower. (cvefeed.io)

---

Looking Ahead​

The next few days will tell us whether CVE-2026-33103 stays a quiet medium-severity disclosure or becomes a more consequential enterprise issue. The deciding factors will be whether Microsoft publishes richer technical detail, whether researchers identify a viable abuse pattern, and whether any incident responders begin reporting suspicious access in live environments. For now, the safe assumption is that this deserves prompt patching and a measured hunt for anomalous internal activity. (cvefeed.io)
Organizations that still run Dynamics 365 on-premises should treat this as a reminder that support status is not the same thing as low risk. Even supported legacy platforms can carry authorization defects that matter a great deal once an attacker is inside the network. The real lesson is not that on-premises software is doomed; it is that on-premises software demands more discipline than many teams budget for.
Watch for these developments:

• A fuller Microsoft advisory with more detail on affected builds.
• Any update to the patch target or remediation guidance.
• Evidence of proof-of-concept code or exploitation discussion.
• Security vendor write-ups that clarify likely abuse paths.
• Internal logs showing suspicious low-privilege access patterns. (cvefeed.io)

CVE-2026-33103 is not the kind of vulnerability that dominates headlines with a dramatic remote exploit or a flashy wormable chain. But that is precisely why it matters: it sits in the quieter category of flaws that can still expose sensitive business data, undermine trust, and create downstream security problems long after the initial patch lands. For defenders, the right response is not alarmism; it is fast remediation, careful validation, and a fresh look at who can really read what inside the Dynamics environment.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center