CVE-2026-49172 exposes the Windows FTP Service to unauthenticated remote code execution through a heap-based buffer overflow, making July’s Windows security updates a priority for any organization still operating Microsoft FTP servers. The flaw carries a CVSS 3.1 score of 9.8, requires no user interaction or existing account, and can be reached over the network.
Microsoft disclosed and patched the vulnerability on July 14, 2026, through the Microsoft Security Response Center. The CVE record describes an unauthorized attacker sending network traffic that triggers memory corruption in the Windows FTP Service, potentially allowing attacker-controlled code to run on the target.
Despite that attack profile, Microsoft rates CVE-2026-49172 as Important rather than Critical. The Zero Day Initiative highlighted the mismatch in its July 2026 security update review, noting that this FTP flaw, an MSMQ vulnerability, and a Remote Desktop Client vulnerability all received 9.8 scores without Microsoft’s top severity label.
There was no indication at publication time that CVE-2026-49172 was being actively exploited or that public exploit code was available. That reduces the immediate evidence of attack activity, but it does not soften the technical path: a network-accessible service, low attack complexity, no privileges, no user interaction, and potential compromise of confidentiality, integrity, and availability.
Microsoft lists a broad range of supported Windows releases as affected, including Windows 10, Windows 11, Windows Server 2019, Windows Server 2022, and Windows Server 2025. The practical exposure is narrower because the vulnerable component is the Windows FTP Service, an optional Internet Information Services role service rather than something every Windows machine actively runs.
That distinction matters when administrators assess an inventory. A Windows Server 2025 machine may appear in the affected-product table, but it is not necessarily reachable through this vulnerability if the FTP Server role is absent or the service is disabled. Conversely, an old FTP endpoint that has quietly survived several infrastructure migrations could be one of the most exposed Windows systems on the network.
Administrators can use Server Manager, Windows Admin Center, PowerShell, configuration-management data, or vulnerability scanners to identify machines with the IIS FTP components installed. On Windows Server, a quick PowerShell inventory can begin with:
That check should be paired with service, listener, and firewall inspection rather than treated as proof of exposure by itself. Teams should determine whether FTP is running, which interfaces it listens on, whether TCP port 21 is reachable, how passive-mode data ports are configured, and whether a load balancer or network address translation rule publishes the service externally.
The most urgent systems are those accepting FTP connections from the internet, partner networks, guest segments, or other partially trusted zones. Internal-only FTP servers still deserve prompt updates because compromised workstations, unmanaged devices, and malicious insiders may provide the network position needed to attack them.
Microsoft has not published enough protocol-level detail to identify the exact FTP command, parsing path, or request sequence involved. Administrators therefore should not assume that authentication, FTPS encryption, or a particular FTP workflow blocks exploitation unless Microsoft explicitly documents such a restriction.
The CVSS vector reflects the dangerous baseline: network attack vector, low complexity, no privileges required, and no user interaction. A successful attack could potentially execute code in the security context of the affected service, although Microsoft’s public material does not yet detail the resulting process privileges or post-exploitation constraints.
The absence of those implementation details is also a reason not to build narrow intrusion-prevention signatures around guesses. Network controls can reduce exposure, but the security update is the authoritative fix. Any detection rule based only on unusual FTP commands may miss a working exploit once researchers or attackers reverse-engineer the patch.
Internet-facing Windows FTP servers should be patched or taken offline first. If an update cannot be installed immediately, restricting access to known source addresses, placing the endpoint behind a VPN, or disabling the FTP service will provide stronger interim protection than relying on monitoring alone.
The Windows 10 situation requires particular care. General support for Windows 10 version 22H2 ended on October 14, 2025, but some devices may continue receiving security fixes through eligible servicing programs, while Windows 10 Enterprise LTSC releases follow different timelines. Seeing a fixed build in vulnerability data does not mean every unsupported PC is automatically entitled to receive it.
Installation should be verified through build numbers, update-management compliance reports, or direct KB detection. A successful deployment record from Windows Server Update Services, Microsoft Intune, Configuration Manager, or another patch platform is useful, but the endpoint’s installed update and post-reboot build remain the stronger evidence.
Administrators should also test July’s cumulative updates against networking software that depends on legacy Transport Driver Interface behavior. Microsoft says the July 14 updates enforce TDI transport registration requirements, which may cause applications using unregistered third-party transports to stop working. That compatibility concern justifies testing but should not become an excuse to leave a reachable FTP service unpatched.
CVE-2026-49172 offers a useful reason to challenge those inherited deployments. Where possible, teams should replace plain FTP with a supported transfer design such as SFTP, HTTPS-based exchange, managed file transfer, or tightly controlled cloud storage. FTPS protects credentials and content in transit, but it still uses the Windows FTP Service and should not be mistaken for a vulnerability mitigation unless Microsoft says otherwise.
Logs from IIS FTP sites, Windows Firewall, perimeter devices, intrusion-detection systems, and endpoint security products should be retained and reviewed for abnormal connection bursts, malformed sessions, repeated command failures, service crashes, or unexpected child processes associated with the FTP service. Because the precise exploit traffic is not publicly documented, defenders should look for behavioral anomalies rather than one supposedly definitive request pattern.
For servers that no longer need FTP, removing the role is preferable to merely closing an external firewall rule. For those that must keep it, the July 14 cumulative update, a confirmed fixed build, a restart where required, and restricted network reachability form the minimum defensible response.
CVE-2026-49172 was not identified as a zero-day under active attack when Microsoft published it, but its 9.8 score leaves little room for complacency. The next meaningful milestone will be whether public technical analysis or exploitation appears after researchers compare the patched and unpatched Windows FTP binaries; administrators should complete that comparison on their own networks first, by locating every active FTP endpoint and moving it onto the fixed July 2026 build.
Microsoft disclosed and patched the vulnerability on July 14, 2026, through the Microsoft Security Response Center. The CVE record describes an unauthorized attacker sending network traffic that triggers memory corruption in the Windows FTP Service, potentially allowing attacker-controlled code to run on the target.
Despite that attack profile, Microsoft rates CVE-2026-49172 as Important rather than Critical. The Zero Day Initiative highlighted the mismatch in its July 2026 security update review, noting that this FTP flaw, an MSMQ vulnerability, and a Remote Desktop Client vulnerability all received 9.8 scores without Microsoft’s top severity label.
There was no indication at publication time that CVE-2026-49172 was being actively exploited or that public exploit code was available. That reduces the immediate evidence of attack activity, but it does not soften the technical path: a network-accessible service, low attack complexity, no privileges, no user interaction, and potential compromise of confidentiality, integrity, and availability.
The FTP Role Turns an OS-Wide Listing Into a Server-Specific Risk
Microsoft lists a broad range of supported Windows releases as affected, including Windows 10, Windows 11, Windows Server 2019, Windows Server 2022, and Windows Server 2025. The practical exposure is narrower because the vulnerable component is the Windows FTP Service, an optional Internet Information Services role service rather than something every Windows machine actively runs.That distinction matters when administrators assess an inventory. A Windows Server 2025 machine may appear in the affected-product table, but it is not necessarily reachable through this vulnerability if the FTP Server role is absent or the service is disabled. Conversely, an old FTP endpoint that has quietly survived several infrastructure migrations could be one of the most exposed Windows systems on the network.
Administrators can use Server Manager, Windows Admin Center, PowerShell, configuration-management data, or vulnerability scanners to identify machines with the IIS FTP components installed. On Windows Server, a quick PowerShell inventory can begin with:
Get-WindowsFeature Web-Ftp-Server, Web-Ftp-Service, Web-Ftp-ExtThat check should be paired with service, listener, and firewall inspection rather than treated as proof of exposure by itself. Teams should determine whether FTP is running, which interfaces it listens on, whether TCP port 21 is reachable, how passive-mode data ports are configured, and whether a load balancer or network address translation rule publishes the service externally.
The most urgent systems are those accepting FTP connections from the internet, partner networks, guest segments, or other partially trusted zones. Internal-only FTP servers still deserve prompt updates because compromised workstations, unmanaged devices, and malicious insiders may provide the network position needed to attack them.
A Heap Overflow With a Straight Network Path
The CVE record identifies CWE-122, a heap-based buffer overflow. In broad terms, the service can mishandle attacker-controlled data in a way that writes beyond an allocated region of heap memory, potentially corrupting adjacent objects or control information.Microsoft has not published enough protocol-level detail to identify the exact FTP command, parsing path, or request sequence involved. Administrators therefore should not assume that authentication, FTPS encryption, or a particular FTP workflow blocks exploitation unless Microsoft explicitly documents such a restriction.
The CVSS vector reflects the dangerous baseline: network attack vector, low complexity, no privileges required, and no user interaction. A successful attack could potentially execute code in the security context of the affected service, although Microsoft’s public material does not yet detail the resulting process privileges or post-exploitation constraints.
The absence of those implementation details is also a reason not to build narrow intrusion-prevention signatures around guesses. Network controls can reduce exposure, but the security update is the authoritative fix. Any detection rule based only on unusual FTP commands may miss a working exploit once researchers or attackers reverse-engineer the patch.
Internet-facing Windows FTP servers should be patched or taken offline first. If an update cannot be installed immediately, restricting access to known source addresses, placing the endpoint behind a VPN, or disabling the FTP service will provide stronger interim protection than relying on monitoring alone.
July Updates Establish the Fixed Build Baseline
The corrected builds vary by Windows release. Microsoft’s affected-version data places the security boundary at the July 14 builds, including:- Windows 10 versions 21H2 and 22H2 are corrected at builds 19044.7548 and 19045.7548.
- Windows 11 version 23H2 is corrected at build 22631.7376 through KB5099414.
- Windows 11 versions 24H2 and 25H2 are corrected at builds 26100.8875 and 26200.8875.
- Windows Server 2019 is corrected at build 17763.9020.
- Windows Server 2022 is corrected at build 20348.5386.
- Windows Server 2025 is corrected at build 26100.33158 through KB5099536.
The Windows 10 situation requires particular care. General support for Windows 10 version 22H2 ended on October 14, 2025, but some devices may continue receiving security fixes through eligible servicing programs, while Windows 10 Enterprise LTSC releases follow different timelines. Seeing a fixed build in vulnerability data does not mean every unsupported PC is automatically entitled to receive it.
Installation should be verified through build numbers, update-management compliance reports, or direct KB detection. A successful deployment record from Windows Server Update Services, Microsoft Intune, Configuration Manager, or another patch platform is useful, but the endpoint’s installed update and post-reboot build remain the stronger evidence.
Administrators should also test July’s cumulative updates against networking software that depends on legacy Transport Driver Interface behavior. Microsoft says the July 14 updates enforce TDI transport registration requirements, which may cause applications using unregistered third-party transports to stop working. That compatibility concern justifies testing but should not become an excuse to leave a reachable FTP service unpatched.
FTP’s Age Does Not Make It Harmless
FTP often persists because it is embedded in scanners, manufacturing systems, scheduled batch transfers, website publishing processes, or vendor integrations that nobody wants to disturb. Those same characteristics create weak ownership, broad firewall rules, static credentials, and servers that are patched less consistently than domain controllers or public web applications.CVE-2026-49172 offers a useful reason to challenge those inherited deployments. Where possible, teams should replace plain FTP with a supported transfer design such as SFTP, HTTPS-based exchange, managed file transfer, or tightly controlled cloud storage. FTPS protects credentials and content in transit, but it still uses the Windows FTP Service and should not be mistaken for a vulnerability mitigation unless Microsoft says otherwise.
Logs from IIS FTP sites, Windows Firewall, perimeter devices, intrusion-detection systems, and endpoint security products should be retained and reviewed for abnormal connection bursts, malformed sessions, repeated command failures, service crashes, or unexpected child processes associated with the FTP service. Because the precise exploit traffic is not publicly documented, defenders should look for behavioral anomalies rather than one supposedly definitive request pattern.
For servers that no longer need FTP, removing the role is preferable to merely closing an external firewall rule. For those that must keep it, the July 14 cumulative update, a confirmed fixed build, a restart where required, and restricted network reachability form the minimum defensible response.
CVE-2026-49172 was not identified as a zero-day under active attack when Microsoft published it, but its 9.8 score leaves little room for complacency. The next meaningful milestone will be whether public technical analysis or exploitation appears after researchers compare the patched and unpatched Windows FTP binaries; administrators should complete that comparison on their own networks first, by locating every active FTP endpoint and moving it onto the fixed July 2026 build.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
