Most vulnerability disclosures read like press releases. This one is a work log. In February 2026 I was an IT operations apprentice at Velferdsetaten, Oslo Kommune, and I found a CVSS 8.8 remote code execution vulnerability affecting roughly 14% of the organisation’s managed Windows fleet. This chapter documents exactly how I found it, how I quantified the exposure, and what happened when I escalated — including a second finding that emerged as a side effect of the investigation.
What CVE-2026-20841 actually is
CVE-2026-20841 is a Remote Code Execution (RCE) vulnerability in Windows Notepad, patched in Microsoft’s February 2026 Patch Tuesday. It was assigned a CVSS base score of 8.8.
Before going further, it’s worth understanding what those numbers mean, because “CVSS 8.8” gets thrown around without explanation.
Notepad being the vulnerable component is the detail that makes this interesting from a fleet exposure standpoint. Notepad is installed on every Windows machine by default and cannot be removed through normal means. There is no configuration that disables it. This means the exposure surface is not opt-in — every unpatched Windows endpoint is vulnerable, regardless of how that endpoint is configured or what role it serves.
The patch arrived in the February 2026 Patch Tuesday rollup. The fixed version is Notepad 11.2510 and above. Any device running an earlier version is vulnerable.
Why Intune can answer “how many are vulnerable”
The traditional answer to “how many of our endpoints are running a vulnerable version of X” involves either a dedicated vulnerability scanner (Qualys, Tenable, Rapid7) or a manual audit. Neither was available to me. What I did have was read access to Intune, which Oslo Kommune uses to manage its Windows fleet.
Intune has a feature called Discovered Apps. It lives at Apps → Monitor → Discovered Apps in the Intune portal. It aggregates software inventory data reported by the Intune management agent running on each enrolled device. For every application installed on any managed endpoint, it shows the application name, version, and a device count.
The query is simple: search Discovered Apps for “Notepad”, find the version distribution, and sum the device counts for any version below 11.2510.
The result: approximately 3,239 devices across the ~23,500 managed Windows endpoints in Oslo Kommune’s fleet were running a vulnerable version of Notepad. That is roughly 13.8% of the managed fleet.
The limits of this methodology
Discovered Apps is a useful signal, not a ground truth. Understanding where it breaks is important before trusting it in a real escalation.
It only covers enrolled devices. Intune manages devices that have been enrolled in MDM (Mobile Device Management). Any machine that has not been enrolled — old hardware, non-domain-joined machines, test environments — is invisible to this query.
Reporting latency. The Intune agent syncs on a schedule, not in real time. A device that was patched yesterday may still show the old version in Discovered Apps until the next sync cycle completes. For patch assessment this is usually acceptable (the concern is unpatched devices, not freshly patched ones), but the count should be understood as a point-in-time snapshot with some lag.
It cannot see what it was not told about. Discovered Apps aggregates what the agent reports. If the agent itself is outdated, not running, or has a reporting gap, the device may appear partially or not at all.
Version strings are not always consistent. Some applications report version strings inconsistently across builds or distribution channels. Notepad is a Microsoft inbox application with predictable versioning, so this was not an issue here — but it matters for third-party applications.
The second finding
While investigating the CVE, I noticed something unrelated to Notepad. My Intune access — granted for the purposes of IT operations at Velferdsetaten — appeared to surface device data from endpoints belonging to other etat (agencies) within Oslo Kommune, not just Velferdsetaten.
In a properly segmented Intune environment, role assignments are scoped to specific device groups. An operator at Velferdsetaten should see Velferdsetaten devices. Seeing records from other agencies suggests either that the scope was intentionally broad (possible in a shared-services model, but worth verifying) or that the RBAC (Role-Based Access Control) boundary was misconfigured.
I flagged this to the EMM (Enterprise Mobility Management) team as an observation rather than a confirmed finding. The distinction matters: I could see data I was not certain I should see, but I could not determine from my position whether this was intentional design or misconfiguration. The appropriate action was to escalate the observation and let the team with full context make that determination.
Escalation: emergency change vs. standard change
After documenting both findings, I escalated to my immediate supervisor and to the EMM team, with a copy to Sopra Steria (the managed service provider responsible for patch management). The CVE finding triggered a discussion about whether to pursue a hasteendring (emergency change) or route through the standard change process.
This is a common tension in operational security and it is worth understanding why.
A standard change process exists to prevent rushed, poorly tested changes from causing outages. In a large fleet like Oslo Kommune’s, a misconfigured patch rollout can take down thousands of machines simultaneously. The change process — documented change request, change advisory board review, scheduled deployment window — exists precisely to prevent this. It is not bureaucracy for its own sake.
An emergency change bypasses parts of that process on the grounds that the risk of not acting immediately exceeds the risk of acting without full review. For a CVSS 8.8 RCE on an internet-accessible component, a reasonable argument exists for the emergency path. For a CVSS 8.8 on a component that requires local network access and user interaction — which shifts the realistic exploitation risk considerably downward — the standard process may be adequate.
The EMM team and Sopra Steria assessed the patch as compatible with the standard change process given the network topology of Oslo Kommune’s fleet — the attack vector was not publicly exposed in a way that created immediate exploitation risk. Patch deployment was scheduled accordingly.
What generalises from this
The Intune Discovered Apps approach is not specific to this CVE. Any time a Patch Tuesday advisory identifies a vulnerable version of an application that ships with Windows or is widely deployed across a managed fleet, the same query applies:
- Open Discovered Apps in Intune
- Search for the affected application
- Identify the fixed version from the advisory
- Sum device counts for all versions below the threshold
- Export the device list for targeted remediation if count is significant
The ceiling on this approach is Intune’s coverage — it only knows about enrolled devices. For anything outside MDM enrollment, a dedicated scanner is necessary. But for organisations already managing their fleet through Intune, this is a zero-additional-tooling path to exposure quantification that most practitioners overlook because they think of Intune as a deployment tool rather than an inventory tool.
The RBAC observation generalises differently. Any time you are granted access to a management platform — Intune, Azure, a cloud console — it is worth spending ten minutes examining whether your access scope matches what you were told it would be. Misconfigured RBAC boundaries are common, usually unintentional, and often go unnoticed for long periods because nobody checks. Noticing and reporting is not overstepping; it is the job.