CVE-2026-35422 is a Microsoft-listed Windows TCP/IP Driver security feature bypass vulnerability disclosed through the MSRC Security Update Guide, affecting the Windows networking stack and requiring administrators to treat the flaw as a confirmed platform security issue rather than a speculative research note. The important word here is not merely TCP/IP, although that will rightly get every network defender’s attention. It is bypass, because bypass bugs are where security architecture quietly loses its guarantees. Microsoft may not be saying this is the next wormable Windows network disaster, but it is saying enough for patch teams to move it out of the “interesting CVE” pile and into the operational queue.
That does not automatically make every TCP/IP CVE catastrophic. Microsoft has disclosed networking-stack vulnerabilities across many years with very different exploitability profiles: some require local subnet positioning, some depend on unusual packet conditions, some are denial-of-service issues, and some are the kind of remote code execution bugs that cause emergency change boards to convene before lunch. The label alone is not the whole story.
CVE-2026-35422 is framed as a security feature bypass, which is a more subtle category than remote code execution or elevation of privilege. A bypass usually means the attacker is not gaining arbitrary code execution directly from the bug itself. Instead, the attacker may be able to defeat a protection that Windows or an administrator expected to hold the line.
That distinction matters because bypass vulnerabilities are easy to underrate. They often sound less dramatic than memory corruption, but they can turn a blocked attack chain into a working one. In mature intrusions, the bypass is often the hinge rather than the headline.
That is why these CVEs generate a different kind of risk than a single vulnerable application. If a browser bug is patched, the browser is patched. If a networking-layer security feature can be bypassed, the impact may depend heavily on how a particular environment uses Windows networking controls. The same CVE can be a low-drama patch item in one enterprise and a serious architectural concern in another.
Microsoft’s advisory language around such flaws tends to be compact, sometimes frustratingly so. The company often provides enough information to classify impact, affected products, and update availability without giving attackers a procedural recipe. That leaves defenders in the familiar Patch Tuesday position of making decisions under partial visibility.
The correct response is not panic. It is prioritization. A TCP/IP driver bypass deserves attention precisely because it lives below most of the software inventory that organizations spend their time cataloging.
That metric is important because disclosures come in different states of maturity. Sometimes a vendor confirms a bug and ships a fix with little public technical detail. Sometimes a researcher publishes enough analysis to map the vulnerable code path. Sometimes exploit code appears before defenders have even finished reading the advisory. Those are very different risk worlds.
For CVE-2026-35422, the fact that it appears in the MSRC Security Update Guide is itself a strong signal that Microsoft has accepted the vulnerability as real. That does not mean all technical details are public. In fact, the absence of granular public mechanics can be deliberate, particularly when the affected component is as sensitive as the Windows networking stack.
The security lesson is that confidence cuts both ways. High confidence in the existence of a vulnerability increases urgency for defenders. High availability of technical detail increases opportunity for attackers. When both are high, patch windows compress. When the vulnerability is confirmed but the details remain sparse, defenders should not mistake silence for safety.
That makes ownership messy. The Windows team may own cumulative updates. The network team may own IPsec, firewall policy, and segmentation. The security operations team may own detection. The infrastructure team may own server maintenance windows. A bypass in the TCP/IP driver does not care about the org chart.
The practical question is not only “Are the affected systems patched?” It is also “Which systems depend on the security feature that might be bypassed?” That is harder to answer. Many organizations can produce a list of Windows versions within minutes, but far fewer can quickly identify where Windows network-layer protections are materially part of a security boundary.
This is where good asset context beats raw CVE counting. A domain controller, VPN-adjacent server, management jump host, Hyper-V host, or internet-facing Windows service may deserve faster treatment than a lightly used kiosk, even if both receive the same severity label. The driver is the same; the blast radius is not.
TCP/IP driver updates can be operationally sensitive because they affect core networking behavior. Administrators tend to be cautious around anything that touches the stack responsible for routing, filtering, name resolution side effects, VPN compatibility, clustering, and storage connectivity. That caution is rational, but it should not become indefinite delay.
The right approach is a staged rollout with an unusually sharp eye on network-dependent workloads. Pilot on representative client and server builds. Include systems with VPN clients, endpoint firewall policies, packet inspection agents, virtual switches, NIC teaming, storage networking, and DirectAccess or IPsec-style configurations if those exist in the estate. Then move quickly once telemetry is clean.
The assurance problem continues after installation. Windows cumulative updates can fail, defer, roll back, or sit pending reboot. A vulnerability in the networking stack is exactly the kind of issue where “deployed” and “effective” must not be confused. A machine that has downloaded the update but not rebooted may still be in the old risk state.
The TCP/IP stack is involved in many of those assumptions. It is not just moving packets; it is participating in how Windows interprets, accepts, rejects, filters, and hands traffic to higher layers. A flaw there can undermine controls that administrators consider settled.
This is especially relevant in hybrid environments. Windows servers may sit behind cloud load balancers, software-defined network policies, host firewalls, VPN concentrators, third-party endpoint agents, and identity-aware proxies. That stack of controls can create a comforting diagram. But packet handling still terminates somewhere, and on Windows systems, the OS networking stack remains a critical part of the trust chain.
The uncomfortable truth is that some organizations will not know whether CVE-2026-35422 threatens a meaningful security boundary until they review their own architecture. That is not a Microsoft-specific problem. It is the natural consequence of layering security controls over decades of operating system and network evolution.
There are reasons for that restraint. Detailed exploit notes can accelerate attacker development, especially in foundational components such as tcpip.sys. Microsoft also has to publish at scale across dozens or hundreds of CVEs in a monthly cycle. Precision is hard when the intended audience ranges from home users to national-scale enterprises.
Still, sparse advisories shift work onto defenders. Security teams must infer risk from category, component, attack vector, affected products, exploitability assessment, and whatever external research appears. That inference is where mistakes happen. A bypass can be dismissed because it is not RCE; a network-stack issue can be overhyped because it sounds like the next Blaster or WannaCry.
The more disciplined reading is in the middle. CVE-2026-35422 should be treated as a confirmed flaw in a high-value Windows component with potentially meaningful defensive implications, but not described beyond the evidence available. That is the difference between sober urgency and vulnerability theater.
That accumulated compatibility is both a strength and a liability. Mature networking code is battle-tested, but it is also expected to handle an extraordinary range of traffic patterns and configurations. Small assumptions in packet parsing, state transitions, filtering, or encapsulation can become security-relevant years after the original design decision.
Security feature bypass bugs often emerge from exactly that complexity. The issue may not be that a programmer forgot security entirely. It may be that two features interact in a way no one expected, or that a protective check applies in one path but not another. In a network stack, there are many paths.
That is why defenders should resist simplistic narratives. “How did Microsoft miss this?” is less useful than “Which controls did we assume were absolute, and how quickly can we recover when one is not?” Mature security programs are built around the second question.
The first tier should include internet-facing Windows systems, remote access infrastructure, systems that enforce or depend on host-level network controls, and servers whose compromise would expand attacker reach. Even if the bypass does not provide direct code execution, weakening a network security feature on a high-value host is not a theoretical problem.
The second tier should include broadly deployed Windows clients, especially laptops that roam across untrusted networks. A corporate desktop behind layered office controls may have one risk profile. A Windows laptop moving between home networks, airports, hotels, and customer sites has another. Networking flaws follow the device.
The third tier is the long tail: lab systems, rarely used servers, offline images, golden images, and disaster recovery environments. These are easy to forget, and they are exactly where old vulnerabilities linger. If CVE-2026-35422 is patched only in the live fleet but not in build media or recovery baselines, the organization has merely postponed rediscovery.
That does not mean home users should disable network features randomly or follow speculative mitigation advice from social media. Networking is easy to break and hard to troubleshoot. A bad workaround can cause more immediate harm than the vulnerability itself.
Users who run Windows as a gaming machine, media server, home lab host, or small-business file server should pay particular attention to updates that remain pending reboot. The icon that says a restart is required is not a decorative suggestion. Kernel and driver fixes generally need the system to complete the update cycle before protection is actually in place.
Small businesses should treat this like an ordinary but important patch-management event. Confirm that managed Windows devices are updating, check that servers have rebooted, and avoid assuming that consumer-grade routers or antivirus products fully compensate for an OS networking-stack flaw.
That process is harder for some vulnerabilities than others, and Microsoft’s engineering changes may not make exploitation obvious. But the general pattern is well established. Patch release starts a clock, especially for widely deployed components.
This is another reason the confidence metric matters. A confirmed vendor fix narrows the search space for anyone performing patch diffing. The advisory may not explain the root cause, but the update contains clues. For defenders, the time between disclosure and broad exploitation is not guaranteed, and it is not evenly distributed across CVEs.
Security teams should therefore avoid waiting for proof-of-concept code before acting on foundational Windows components. By the time a reliable public proof of concept appears, the patching race has already moved into a less favorable phase.
That does not mean defenders are blind. Network telemetry, Windows event logs, EDR signals, firewall logs, and authentication traces may all show suspicious downstream behavior. But those are often second-order indicators. They may reveal what an attacker did after a bypass, not the bypass itself.
This distinction is crucial for incident response. If a security control was bypassed, the logs from that control may not tell the full story. Investigators may need to correlate unusual connection patterns, authentication attempts, policy exceptions, and endpoint behavior across multiple sources. A missing block event is not proof that nothing happened.
For most enterprises, prevention through patching will be more reliable than detection through signatures. That may sound unsatisfying, but it is the practical reality of operating-system network-layer flaws.
That is why vulnerability programs that rank issues only by standalone impact can miss the point. A bypass with a moderate score may be more useful to an attacker than a theoretically severe bug that is difficult to reach. Context turns severity into risk.
Windows administrators have seen this movie before. Mark-of-the-Web bypasses, SmartScreen bypasses, authentication coercion bugs, and driver flaws often become more serious when paired with social engineering, credential theft, or another code execution primitive. The bypass is the door wedge.
For TCP/IP, that chain-based thinking is especially important. Network-layer behavior influences what systems can talk, how they talk, and which protections mediate the conversation. If one of those mediators fails, the attacker’s next step may become easier even if the CVE itself does not finish the job.
For readers managing mixed fleets, the operational posture should be straightforward:
Source: MSRC Security Update Guide - Microsoft Security Response Center
Microsoft’s Quietest Bugs Often Sit in the Loudest Part of Windows
The Windows TCP/IP driver is not an obscure corner of the operating system. It is one of the basic pieces of plumbing that lets every Windows client and server speak to the rest of the world, from domain controllers and file servers to laptops on hotel Wi-Fi. When a vulnerability lands in that layer, administrators do not have the luxury of treating it like a niche application flaw that can be isolated to a forgotten workstation.That does not automatically make every TCP/IP CVE catastrophic. Microsoft has disclosed networking-stack vulnerabilities across many years with very different exploitability profiles: some require local subnet positioning, some depend on unusual packet conditions, some are denial-of-service issues, and some are the kind of remote code execution bugs that cause emergency change boards to convene before lunch. The label alone is not the whole story.
CVE-2026-35422 is framed as a security feature bypass, which is a more subtle category than remote code execution or elevation of privilege. A bypass usually means the attacker is not gaining arbitrary code execution directly from the bug itself. Instead, the attacker may be able to defeat a protection that Windows or an administrator expected to hold the line.
That distinction matters because bypass vulnerabilities are easy to underrate. They often sound less dramatic than memory corruption, but they can turn a blocked attack chain into a working one. In mature intrusions, the bypass is often the hinge rather than the headline.
Security Feature Bypass Is the Category Attackers Love to Chain
The modern Windows security model is layered. Firewalls, IPsec policies, network isolation, authentication boundaries, exploit mitigations, and endpoint controls all assume that lower layers behave predictably. A security feature bypass in the TCP/IP driver should be read in that context: not as “an attacker owns the box with one packet,” but as “one of the assumptions around network defense may not be as strong as advertised.”That is why these CVEs generate a different kind of risk than a single vulnerable application. If a browser bug is patched, the browser is patched. If a networking-layer security feature can be bypassed, the impact may depend heavily on how a particular environment uses Windows networking controls. The same CVE can be a low-drama patch item in one enterprise and a serious architectural concern in another.
Microsoft’s advisory language around such flaws tends to be compact, sometimes frustratingly so. The company often provides enough information to classify impact, affected products, and update availability without giving attackers a procedural recipe. That leaves defenders in the familiar Patch Tuesday position of making decisions under partial visibility.
The correct response is not panic. It is prioritization. A TCP/IP driver bypass deserves attention precisely because it lives below most of the software inventory that organizations spend their time cataloging.
The Exploitability Signal Is About Confidence, Not Curiosity
The user-supplied MSRC text points to one of the more misunderstood parts of vulnerability scoring: the metric that measures confidence in the existence of the vulnerability and the credibility of known technical details. This is not a popularity contest for researchers or a measure of how many blog posts exist. It is a way of asking how solid the vulnerability information is, and how much an attacker can plausibly learn from what is already public.That metric is important because disclosures come in different states of maturity. Sometimes a vendor confirms a bug and ships a fix with little public technical detail. Sometimes a researcher publishes enough analysis to map the vulnerable code path. Sometimes exploit code appears before defenders have even finished reading the advisory. Those are very different risk worlds.
For CVE-2026-35422, the fact that it appears in the MSRC Security Update Guide is itself a strong signal that Microsoft has accepted the vulnerability as real. That does not mean all technical details are public. In fact, the absence of granular public mechanics can be deliberate, particularly when the affected component is as sensitive as the Windows networking stack.
The security lesson is that confidence cuts both ways. High confidence in the existence of a vulnerability increases urgency for defenders. High availability of technical detail increases opportunity for attackers. When both are high, patch windows compress. When the vulnerability is confirmed but the details remain sparse, defenders should not mistake silence for safety.
TCP/IP Bugs Collapse the Distance Between Endpoint and Network
One reason Windows TCP/IP vulnerabilities get attention is that they sit at the boundary between host security and network security. Endpoint teams think in terms of device state, patch level, and EDR coverage. Network teams think in terms of segmentation, packet flow, access control, and exposure. A TCP/IP driver flaw belongs to both teams at once.That makes ownership messy. The Windows team may own cumulative updates. The network team may own IPsec, firewall policy, and segmentation. The security operations team may own detection. The infrastructure team may own server maintenance windows. A bypass in the TCP/IP driver does not care about the org chart.
The practical question is not only “Are the affected systems patched?” It is also “Which systems depend on the security feature that might be bypassed?” That is harder to answer. Many organizations can produce a list of Windows versions within minutes, but far fewer can quickly identify where Windows network-layer protections are materially part of a security boundary.
This is where good asset context beats raw CVE counting. A domain controller, VPN-adjacent server, management jump host, Hyper-V host, or internet-facing Windows service may deserve faster treatment than a lightly used kiosk, even if both receive the same severity label. The driver is the same; the blast radius is not.
The Patch Is Simple; The Assurance Problem Is Not
For most Windows environments, remediation will mean applying the relevant Microsoft security update through Windows Update, Windows Server Update Services, Microsoft Configuration Manager, Intune, or another patch platform. That part is familiar. The hard part is proving that the update reached the systems where this vulnerability matters most.TCP/IP driver updates can be operationally sensitive because they affect core networking behavior. Administrators tend to be cautious around anything that touches the stack responsible for routing, filtering, name resolution side effects, VPN compatibility, clustering, and storage connectivity. That caution is rational, but it should not become indefinite delay.
The right approach is a staged rollout with an unusually sharp eye on network-dependent workloads. Pilot on representative client and server builds. Include systems with VPN clients, endpoint firewall policies, packet inspection agents, virtual switches, NIC teaming, storage networking, and DirectAccess or IPsec-style configurations if those exist in the estate. Then move quickly once telemetry is clean.
The assurance problem continues after installation. Windows cumulative updates can fail, defer, roll back, or sit pending reboot. A vulnerability in the networking stack is exactly the kind of issue where “deployed” and “effective” must not be confused. A machine that has downloaded the update but not rebooted may still be in the old risk state.
Security Features Are Only Boundaries If You Know Where They Are
Security feature bypass vulnerabilities are uncomfortable because they force organizations to admit that many “boundaries” are really assumptions. A firewall rule is a boundary if it is enforced consistently. A network isolation policy is a boundary if traffic cannot slip around it. An authentication or encapsulation mechanism is a boundary if the implementation holds under hostile conditions.The TCP/IP stack is involved in many of those assumptions. It is not just moving packets; it is participating in how Windows interprets, accepts, rejects, filters, and hands traffic to higher layers. A flaw there can undermine controls that administrators consider settled.
This is especially relevant in hybrid environments. Windows servers may sit behind cloud load balancers, software-defined network policies, host firewalls, VPN concentrators, third-party endpoint agents, and identity-aware proxies. That stack of controls can create a comforting diagram. But packet handling still terminates somewhere, and on Windows systems, the OS networking stack remains a critical part of the trust chain.
The uncomfortable truth is that some organizations will not know whether CVE-2026-35422 threatens a meaningful security boundary until they review their own architecture. That is not a Microsoft-specific problem. It is the natural consequence of layering security controls over decades of operating system and network evolution.
Sparse Advisories Are a Defensive Burden, Not a Vendor Excuse
Microsoft’s modern Security Update Guide is designed for machine-readable triage as much as human explanation. It is better than the old days in some ways: CVEs are centralized, product impact is structured, and exploitability details are easier to compare across a monthly release. But for administrators trying to understand operational risk, the advisory format can still feel like reading a weather report that says “storm likely” without naming the neighborhood.There are reasons for that restraint. Detailed exploit notes can accelerate attacker development, especially in foundational components such as tcpip.sys. Microsoft also has to publish at scale across dozens or hundreds of CVEs in a monthly cycle. Precision is hard when the intended audience ranges from home users to national-scale enterprises.
Still, sparse advisories shift work onto defenders. Security teams must infer risk from category, component, attack vector, affected products, exploitability assessment, and whatever external research appears. That inference is where mistakes happen. A bypass can be dismissed because it is not RCE; a network-stack issue can be overhyped because it sounds like the next Blaster or WannaCry.
The more disciplined reading is in the middle. CVE-2026-35422 should be treated as a confirmed flaw in a high-value Windows component with potentially meaningful defensive implications, but not described beyond the evidence available. That is the difference between sober urgency and vulnerability theater.
The Windows Networking Stack Has a Long Institutional Memory
Windows networking has carried enterprise computing through several eras: LAN-first domains, VPN-heavy remote work, cloud management, zero trust overlays, and now AI-era endpoint telemetry. The same broad stack has had to support legacy applications, modern encryption, virtualization, containers, wireless roaming, and every strange middlebox an enterprise can buy.That accumulated compatibility is both a strength and a liability. Mature networking code is battle-tested, but it is also expected to handle an extraordinary range of traffic patterns and configurations. Small assumptions in packet parsing, state transitions, filtering, or encapsulation can become security-relevant years after the original design decision.
Security feature bypass bugs often emerge from exactly that complexity. The issue may not be that a programmer forgot security entirely. It may be that two features interact in a way no one expected, or that a protective check applies in one path but not another. In a network stack, there are many paths.
That is why defenders should resist simplistic narratives. “How did Microsoft miss this?” is less useful than “Which controls did we assume were absolute, and how quickly can we recover when one is not?” Mature security programs are built around the second question.
Where Enterprise IT Should Put This in the Queue
Patch prioritization is never just about severity labels. It is about exposure, exploitability, business criticality, compensating controls, and time. CVE-2026-35422 belongs above routine application bugs in many environments because the affected component is foundational and the vulnerability class can assist attack chains.The first tier should include internet-facing Windows systems, remote access infrastructure, systems that enforce or depend on host-level network controls, and servers whose compromise would expand attacker reach. Even if the bypass does not provide direct code execution, weakening a network security feature on a high-value host is not a theoretical problem.
The second tier should include broadly deployed Windows clients, especially laptops that roam across untrusted networks. A corporate desktop behind layered office controls may have one risk profile. A Windows laptop moving between home networks, airports, hotels, and customer sites has another. Networking flaws follow the device.
The third tier is the long tail: lab systems, rarely used servers, offline images, golden images, and disaster recovery environments. These are easy to forget, and they are exactly where old vulnerabilities linger. If CVE-2026-35422 is patched only in the live fleet but not in build media or recovery baselines, the organization has merely postponed rediscovery.
Home Users Should Patch, But Not Self-Diagnose the Stack
For Windows enthusiasts and home users, the guidance is simpler: install the relevant Windows security update and reboot. There is little value in trying to determine whether a particular home configuration depends on the affected security feature. The TCP/IP driver is part of the operating system, and the safe path is to take the fix.That does not mean home users should disable network features randomly or follow speculative mitigation advice from social media. Networking is easy to break and hard to troubleshoot. A bad workaround can cause more immediate harm than the vulnerability itself.
Users who run Windows as a gaming machine, media server, home lab host, or small-business file server should pay particular attention to updates that remain pending reboot. The icon that says a restart is required is not a decorative suggestion. Kernel and driver fixes generally need the system to complete the update cycle before protection is actually in place.
Small businesses should treat this like an ordinary but important patch-management event. Confirm that managed Windows devices are updating, check that servers have rebooted, and avoid assuming that consumer-grade routers or antivirus products fully compensate for an OS networking-stack flaw.
Attackers Do Not Need Every Detail on Day One
One of the more dangerous myths in vulnerability management is that a lack of public exploit code means a lack of attacker interest. In reality, attackers often work backward from patches. Once a security update ships, skilled researchers and adversaries can compare old and new binaries, identify changed code paths, and begin reconstructing the bug.That process is harder for some vulnerabilities than others, and Microsoft’s engineering changes may not make exploitation obvious. But the general pattern is well established. Patch release starts a clock, especially for widely deployed components.
This is another reason the confidence metric matters. A confirmed vendor fix narrows the search space for anyone performing patch diffing. The advisory may not explain the root cause, but the update contains clues. For defenders, the time between disclosure and broad exploitation is not guaranteed, and it is not evenly distributed across CVEs.
Security teams should therefore avoid waiting for proof-of-concept code before acting on foundational Windows components. By the time a reliable public proof of concept appears, the patching race has already moved into a less favorable phase.
Detection Will Be Harder Than Deployment
Many organizations like to ask whether they can detect exploitation before they patch. For a TCP/IP driver security feature bypass, that is the wrong primary strategy. Low-level network behavior may not produce clean, high-confidence logs, and the whole point of a bypass is that expected security enforcement may not happen in the expected way.That does not mean defenders are blind. Network telemetry, Windows event logs, EDR signals, firewall logs, and authentication traces may all show suspicious downstream behavior. But those are often second-order indicators. They may reveal what an attacker did after a bypass, not the bypass itself.
This distinction is crucial for incident response. If a security control was bypassed, the logs from that control may not tell the full story. Investigators may need to correlate unusual connection patterns, authentication attempts, policy exceptions, and endpoint behavior across multiple sources. A missing block event is not proof that nothing happened.
For most enterprises, prevention through patching will be more reliable than detection through signatures. That may sound unsatisfying, but it is the practical reality of operating-system network-layer flaws.
The Real Risk Is the Chain, Not the Single CVE
CVE-2026-35422 should be viewed as part of the larger pattern of Windows security in 2026: attackers do not need one perfect vulnerability when they can combine several imperfect ones. A security feature bypass can help with initial access, lateral movement, credential exposure, policy evasion, or exploitation of a second bug. Its value is often relational.That is why vulnerability programs that rank issues only by standalone impact can miss the point. A bypass with a moderate score may be more useful to an attacker than a theoretically severe bug that is difficult to reach. Context turns severity into risk.
Windows administrators have seen this movie before. Mark-of-the-Web bypasses, SmartScreen bypasses, authentication coercion bugs, and driver flaws often become more serious when paired with social engineering, credential theft, or another code execution primitive. The bypass is the door wedge.
For TCP/IP, that chain-based thinking is especially important. Network-layer behavior influences what systems can talk, how they talk, and which protections mediate the conversation. If one of those mediators fails, the attacker’s next step may become easier even if the CVE itself does not finish the job.
The Practical Read for WindowsForum Readers
CVE-2026-35422 is not a vulnerability to sensationalize, but it is also not one to bury under the monthly patch pile. Its importance comes from the combination of a confirmed Microsoft advisory, a foundational Windows component, and a vulnerability class that can weaken assumptions defenders rely on. That combination is enough to justify prompt action.For readers managing mixed fleets, the operational posture should be straightforward:
- Inventory Windows systems that are exposed to untrusted networks or that enforce important network security boundaries.
- Prioritize patching and rebooting servers, remote access systems, domain infrastructure, management hosts, and roaming endpoints.
- Validate that cumulative updates completed successfully rather than merely being offered, downloaded, or staged.
- Review whether host firewall, IPsec, VPN, or segmentation assumptions depend on Windows network-layer behavior.
- Watch for credible follow-up research, but do not wait for public exploit code before deploying the fix.
- Update golden images, recovery media, and offline templates so the vulnerability does not reappear during rebuilds.
Source: MSRC Security Update Guide - Microsoft Security Response Center
