Microsoft’s Security Update Guide now lists CVE-2026-25645, a medium-severity flaw in Python Requests before 2.33.0 where
CVE-2026-25645 is the kind of vulnerability that modern risk systems are bad at narrating. It has a medium score, a local attack vector, and exploitation conditions that are constrained enough to keep it out of the “drop everything” category. Yet it touches Requests, one of the most widely deployed Python libraries in existence, and it sits near certificate verification, one of the most trust-sensitive parts of an HTTP stack.
The vulnerable function,
This is not the same thing as a remote code execution bug in a web-facing daemon. The attacker needs local foothold or write access to the relevant temporary directory, and successful exploitation depends on timing, environment, and how the application uses the utility. But in real enterprise systems, “local” is not a synonym for “irrelevant.” Shared build hosts, developer workstations, CI runners, application servers, and multi-user Unix-like environments are full of places where temporary-file assumptions become security boundaries by accident.
The fix landed in Requests 2.33.0, released on March 25, 2026. Requests 2.33.1 followed on March 30 with cleanup around tests related to the same CVE, while the release history makes clear that ordinary use of Requests is not the affected path. The affected surface is narrower: applications that call the utility function directly, and environments where predictable temp-file reuse can be turned into malicious replacement.
The vulnerable pattern in CVE-2026-25645 is familiar: derive a destination from a predictable name, check whether it exists, and reuse it if it does. That looks efficient from the perspective of a helper function. It avoids repeated extraction and gives callers a stable path. But from a security perspective, the existence check is the moment the function gives away authority.
A secure temp-file pattern usually depends on non-deterministic names, atomic creation, restrictive permissions, and validation of what was created. CVE-2026-25645 is a reminder that doing three of those things in adjacent code is not the same as doing them at the trust boundary. If a function is willing to believe that an existing temp file is the file it expected, it has made a security decision based on a filename.
That is especially uncomfortable in this case because the example most commonly associated with the bug is
That is exactly the kind of language that can lull organizations into skipping the fix. Security teams read “conditions beyond the attacker’s control” and mentally file the issue under “theoretical.” Development teams read “standard usage not affected” and assume their dependency scanner is being noisy. Operations teams see “local attacker” and conclude that the game is already over if someone is on the box.
All three reactions are understandable, and all three are incomplete. A local attacker with limited privileges is not the same as a root or administrator-level adversary. The whole point of privilege boundaries is that lower-privileged users, service accounts, compromised build steps, and sandboxed processes should not be able to steer higher-trust software into using attacker-supplied security material. If they can, the vulnerability is doing real work.
The most practical exploitation scenarios are not cinematic. They look like a compromised developer account on a shared workstation, a malicious job on a CI runner, a low-privileged shell on a build host, or a tenant with write access to a shared temporary directory. The attacker does not need to own the world. They need to know enough about the application’s startup path and filesystem behavior to place the right file in the right location before the trusted code arrives.
That design choice matters because widely used libraries have become de facto infrastructure. Requests is not just a package imported by developers who know they are using it; it is a transitive dependency pulled into automation scripts, vendor tools, cloud CLIs, internal dashboards, build pipelines, packaging utilities, and one-off administrative glue. When a utility function in such a library has a sharp edge, the blast radius is determined less by the maintainers’ intent than by the ecosystem’s creativity.
The Requests maintainers also drew a clear boundary around impact: default usage is not affected. This distinction should survive the scanner-to-ticket translation layer. If an application merely imports Requests and performs ordinary HTTP calls, CVE-2026-25645 is not automatically an exploitable condition. If an application directly calls
This is where mature vulnerability management earns its keep. The correct response is not to mark every Requests instance as equally dangerous, nor to dismiss the CVE because most apps are probably fine. It is to upgrade the dependency where feasible, then use application context to decide whether anything more urgent is required. That sounds dull because good security operations often sound dull. The alternative is noisy dashboards that teach engineers to ignore dependency alerts until the next disaster.
Windows has its own temporary directories, service accounts, scheduled tasks, developer shells, Python virtual environments, packaging tools, and build agents. It also has a long history of privilege-boundary bugs created when software trusts writable paths too much. The syntax changes; the principle does not. If a process running with greater trust consumes a file from a location writable by a lower-trust principal, the filesystem has become part of the attack surface.
The Windows angle is especially relevant because Python is everywhere in modern Windows administration. It runs in data pipelines, security tooling, provisioning scripts, test harnesses, ML workflows, cloud automation, and developer utilities. Many of those uses are invisible to traditional endpoint inventories. A server may not be “a Python server” in anyone’s CMDB, but it may still run Python every hour under Task Scheduler or a service wrapper.
Requests is also frequently bundled into larger tools, which means the vulnerable version may not be obvious from a global Python installation. A virtual environment can freeze an old version. A packaged executable can embed one. A vendor product can carry a dependency long after upstream has patched it. This is why “we upgraded pip packages on the server” is not the same as “we no longer have vulnerable Requests code in use.”
That distinction is important because it changes the remediation muscle. You are not hunting for an impostor package. You are not trying to decide whether a maintainer account was compromised. You are dealing with a design flaw in an authentic dependency that may have been present for years and may be invoked only by unusual code paths.
This is where SBOMs and dependency scanners help, but only to a point. They can tell you that Requests before 2.33.0 exists somewhere in your estate. They cannot, by themselves, tell you whether a particular application calls
The better organizations will use this CVE as a chance to ask sharper questions. Which Python applications run as privileged services? Which build agents reuse workspaces across users or jobs? Which packaged tools embed their own Python environments? Which scripts run from scheduled tasks under accounts broader than they need? CVE-2026-25645 may be medium severity, but the answers to those questions often uncover higher-value problems.
Certificate authority bundles are not ordinary configuration files. They define which issuers an application trusts when it verifies TLS connections. If an attacker can cause a higher-trust process to load a malicious CA bundle, the downstream impact can include accepting certificates that should not be trusted. In the right environment, that can turn a local preparation step into a broader integrity problem for outbound connections.
The advisory’s CVSS impact centers on integrity, not confidentiality or availability. That framing makes sense. The core risk is replacement: the application uses attacker-controlled material in place of legitimate material. Whether that leads to meaningful compromise depends on what the application does next, where it connects, and whether the attacker can also influence the network path or certificate presented.
This is where Microsoft’s “conditions beyond the attacker’s control” language becomes concrete. To turn malicious CA material into a useful attack, the adversary may need more than filesystem access. They may need to intercept traffic, influence DNS, control a proxy, or target an application that connects to attacker-controlled endpoints. But enterprise environments are full of proxy layers, service meshes, test endpoints, and internal certificate practices that make “network path influence” less exotic than it sounds.
Where upgrading is not immediately possible, the most relevant mitigation is to ensure the temporary directory used by the vulnerable process is not writable by untrusted users or lower-privileged contexts. That can mean setting
Developers should also search for direct use of
Administrators should resist the urge to solve this purely with endpoint cleanup scripts. Deleting stale temp files may reduce some opportunities, but it does not fix a race-prone or predictable trust pattern. If the application can still be convinced to reuse an attacker-created file, the vulnerability remains. The point is not to keep
The ownership question is deceptively hard. If Requests is in a product repository, the application team owns it. If it is in a container base image, the platform team may own it. If it is inside a vendor appliance or packaged executable, procurement and vendor management may own the escalation. If it is on a developer workstation, endpoint engineering may be involved. If it is in a CI runner image, DevOps owns the practical fix even if security opened the ticket.
This is why dependency risk has become an operational problem rather than just a development problem. A single library can exist in source code, images, virtual environments, notebooks, Lambda-style functions, MSI payloads, zipapps, and frozen executables. The same CVE can be a false alarm in one place and a meaningful privilege-boundary issue in another.
A good vulnerability program should therefore treat this CVE as a classification exercise. First, find Requests versions below 2.33.0. Second, determine whether the vulnerable function is called directly or whether the application packaging makes the certificate-path behavior relevant. Third, prioritize systems where lower-trust users or jobs can write to temp locations used by higher-trust processes. Fourth, upgrade or isolate. None of that is glamorous, but it is exactly the work that separates risk management from alert collection.
The harder question is whether downstream users can absorb the fix. Enterprises often talk about open-source risk as if it lives upstream, but the more stubborn risk lives in the gap between upstream release and downstream deployment. A patched Requests release does nothing for a frozen dependency in an internal tool that nobody has rebuilt since 2024. A clear advisory does nothing for a vendor package that does not expose its Python dependency inventory. A medium CVE can persist for years if no one owns the environment where it runs.
This is especially true in Windows-heavy estates where Python may be treated as a developer convenience rather than managed runtime infrastructure. If Python is installed casually, virtual environments are created ad hoc, and automation scripts are copied between servers, then library patching becomes archeology. Security teams cannot govern what the organization refuses to inventory.
The lesson is not that every Python script needs enterprise ceremony. The lesson is that scripts running with privilege, scripts handling certificates, scripts making network calls, and scripts participating in build or deployment paths are production software whether or not anyone calls them that. Requests is often present precisely in those places because it makes HTTP easy. Ease of use is a feature; invisibility is the liability.
CVE-2026-25645 will probably not become the next famous vulnerability with a logo, a soundtrack, and a week of executive briefings. It is too conditional for that, and Requests has already shipped the right fix. But the next wave of software security failures will look a lot like this: trusted libraries, obscure helper functions, temporary files, packaging shortcuts, and privilege boundaries nobody drew on purpose. The organizations that move fastest will not be the ones that panic over every medium CVE; they will be the ones that can see, patch, and isolate the quiet dependencies before attackers learn to compose them into something louder.
Source: MSRC Security Update Guide - Microsoft Security Response Center
extract_zipped_paths() can reuse predictable temporary files, allowing a local attacker to substitute malicious content under specific environmental conditions. The vulnerability is not a drive-by internet catastrophe, and that is precisely why it deserves attention. It lives in the quieter layer where trusted libraries, temporary directories, certificate bundles, and packaging assumptions meet. For Windows admins and developers, the lesson is less “panic about Requests” than “stop treating dependency utility functions as harmless plumbing.”
A Medium CVE With a Long Shadow
CVE-2026-25645 is the kind of vulnerability that modern risk systems are bad at narrating. It has a medium score, a local attack vector, and exploitation conditions that are constrained enough to keep it out of the “drop everything” category. Yet it touches Requests, one of the most widely deployed Python libraries in existence, and it sits near certificate verification, one of the most trust-sensitive parts of an HTTP stack.The vulnerable function,
requests.utils.extract_zipped_paths(), was designed as a utility for extracting paths from zip-based structures into a temporary location. Before Requests 2.33.0, the function could use a predictable filename in the system temporary directory and then reuse an existing file if it was already present. That behavior created the opening: if an attacker could pre-place a malicious file at the expected temporary path, a vulnerable application might use that file instead of the intended extracted content.This is not the same thing as a remote code execution bug in a web-facing daemon. The attacker needs local foothold or write access to the relevant temporary directory, and successful exploitation depends on timing, environment, and how the application uses the utility. But in real enterprise systems, “local” is not a synonym for “irrelevant.” Shared build hosts, developer workstations, CI runners, application servers, and multi-user Unix-like environments are full of places where temporary-file assumptions become security boundaries by accident.
The fix landed in Requests 2.33.0, released on March 25, 2026. Requests 2.33.1 followed on March 30 with cleanup around tests related to the same CVE, while the release history makes clear that ordinary use of Requests is not the affected path. The affected surface is narrower: applications that call the utility function directly, and environments where predictable temp-file reuse can be turned into malicious replacement.
The Bug Is Small Because the Assumption Was Big
Temporary directories have always been a trap for software that confuses convenience with ownership./tmp, %TEMP%, container scratch space, build-agent workspaces, and language runtime caches all invite developers to think of them as neutral ground. They are not. They are contested territory, often writable by more than one principal and frequently cleaned, reused, mounted, redirected, or inherited in ways that the application author never sees.The vulnerable pattern in CVE-2026-25645 is familiar: derive a destination from a predictable name, check whether it exists, and reuse it if it does. That looks efficient from the perspective of a helper function. It avoids repeated extraction and gives callers a stable path. But from a security perspective, the existence check is the moment the function gives away authority.
A secure temp-file pattern usually depends on non-deterministic names, atomic creation, restrictive permissions, and validation of what was created. CVE-2026-25645 is a reminder that doing three of those things in adjacent code is not the same as doing them at the trust boundary. If a function is willing to believe that an existing temp file is the file it expected, it has made a security decision based on a filename.
That is especially uncomfortable in this case because the example most commonly associated with the bug is
cacert.pem, the certificate authority bundle used in TLS verification paths. The advisory language is careful, and it should be: standard Requests usage is not affected, and the direct utility-call condition matters. Still, the symbolic weight is hard to miss. A library famous for making HTTP simple had to patch a helper path where the filesystem could be tricked into speaking for the network’s chain of trust.“Attack Complexity High” Is Not a Comfort Blanket
Microsoft’s description emphasizes that a successful attack depends on conditions beyond the attacker’s direct control. That phrasing is important. It means exploitation cannot simply be launched against any Requests-using application at will. An attacker may need knowledge of the target environment, influence over the temp directory, the ability to prepare the filesystem ahead of execution, or a position that lets them shape when the vulnerable component initializes.That is exactly the kind of language that can lull organizations into skipping the fix. Security teams read “conditions beyond the attacker’s control” and mentally file the issue under “theoretical.” Development teams read “standard usage not affected” and assume their dependency scanner is being noisy. Operations teams see “local attacker” and conclude that the game is already over if someone is on the box.
All three reactions are understandable, and all three are incomplete. A local attacker with limited privileges is not the same as a root or administrator-level adversary. The whole point of privilege boundaries is that lower-privileged users, service accounts, compromised build steps, and sandboxed processes should not be able to steer higher-trust software into using attacker-supplied security material. If they can, the vulnerability is doing real work.
The most practical exploitation scenarios are not cinematic. They look like a compromised developer account on a shared workstation, a malicious job on a CI runner, a low-privileged shell on a build host, or a tenant with write access to a shared temporary directory. The attacker does not need to own the world. They need to know enough about the application’s startup path and filesystem behavior to place the right file in the right location before the trusted code arrives.
The Requests Fix Shows Why Library Maintainers Now Patch Edges
Requests 2.33.0 changed the extraction behavior so the utility writes to a non-deterministic location, preventing straightforward malicious file replacement. That is the correct class of fix. It does not depend on telling users to clean/tmp more often, lock down every shared host perfectly, or audit every caller forever. It changes the primitive so the dangerous assumption disappears.That design choice matters because widely used libraries have become de facto infrastructure. Requests is not just a package imported by developers who know they are using it; it is a transitive dependency pulled into automation scripts, vendor tools, cloud CLIs, internal dashboards, build pipelines, packaging utilities, and one-off administrative glue. When a utility function in such a library has a sharp edge, the blast radius is determined less by the maintainers’ intent than by the ecosystem’s creativity.
The Requests maintainers also drew a clear boundary around impact: default usage is not affected. This distinction should survive the scanner-to-ticket translation layer. If an application merely imports Requests and performs ordinary HTTP calls, CVE-2026-25645 is not automatically an exploitable condition. If an application directly calls
extract_zipped_paths() or wraps Requests internals in unusual deployment modes, the risk deserves closer inspection.This is where mature vulnerability management earns its keep. The correct response is not to mark every Requests instance as equally dangerous, nor to dismiss the CVE because most apps are probably fine. It is to upgrade the dependency where feasible, then use application context to decide whether anything more urgent is required. That sounds dull because good security operations often sound dull. The alternative is noisy dashboards that teach engineers to ignore dependency alerts until the next disaster.
Windows Shops Should Not Ignore a Bug That Talks Like Unix
Much of the public technical description uses Unix-flavored language:/tmp, local attackers, predictable filenames, shared temporary directories. Windows administrators may be tempted to read that as someone else’s problem. That would be a mistake, not because the exploit mechanics are identical on every platform, but because the underlying pattern is platform-neutral.Windows has its own temporary directories, service accounts, scheduled tasks, developer shells, Python virtual environments, packaging tools, and build agents. It also has a long history of privilege-boundary bugs created when software trusts writable paths too much. The syntax changes; the principle does not. If a process running with greater trust consumes a file from a location writable by a lower-trust principal, the filesystem has become part of the attack surface.
The Windows angle is especially relevant because Python is everywhere in modern Windows administration. It runs in data pipelines, security tooling, provisioning scripts, test harnesses, ML workflows, cloud automation, and developer utilities. Many of those uses are invisible to traditional endpoint inventories. A server may not be “a Python server” in anyone’s CMDB, but it may still run Python every hour under Task Scheduler or a service wrapper.
Requests is also frequently bundled into larger tools, which means the vulnerable version may not be obvious from a global Python installation. A virtual environment can freeze an old version. A packaged executable can embed one. A vendor product can carry a dependency long after upstream has patched it. This is why “we upgraded pip packages on the server” is not the same as “we no longer have vulnerable Requests code in use.”
The Supply Chain Story Is Not Just About Malicious Packages
The last few years trained defenders to associate Python supply-chain risk with typosquatting, dependency confusion, malicious maintainers, poisoned packages, and compromised publishing credentials. Those are real problems. CVE-2026-25645 belongs to a quieter category: a legitimate, trusted package exposes a utility behavior that becomes unsafe in particular execution contexts.That distinction is important because it changes the remediation muscle. You are not hunting for an impostor package. You are not trying to decide whether a maintainer account was compromised. You are dealing with a design flaw in an authentic dependency that may have been present for years and may be invoked only by unusual code paths.
This is where SBOMs and dependency scanners help, but only to a point. They can tell you that Requests before 2.33.0 exists somewhere in your estate. They cannot, by themselves, tell you whether a particular application calls
extract_zipped_paths() directly, whether that application runs with elevated privileges, whether its temp directory is shared, or whether an attacker could pre-position a malicious file. For that, you need code search, runtime knowledge, and boring conversations between security and engineering.The better organizations will use this CVE as a chance to ask sharper questions. Which Python applications run as privileged services? Which build agents reuse workspaces across users or jobs? Which packaged tools embed their own Python environments? Which scripts run from scheduled tasks under accounts broader than they need? CVE-2026-25645 may be medium severity, but the answers to those questions often uncover higher-value problems.
Certificate Trust Makes Even a Narrow Bug Feel Larger
The Requests advisory notes thatextract_zipped_paths() is used by HTTPAdapter.cert_verify() to load a CA bundle in certain zipapp-style structures, often involving certifi. That does not mean every Requests HTTPS call is exposed. But it explains why security teams should read the vulnerability with more care than they would give to a random temp-file cleanup flaw.Certificate authority bundles are not ordinary configuration files. They define which issuers an application trusts when it verifies TLS connections. If an attacker can cause a higher-trust process to load a malicious CA bundle, the downstream impact can include accepting certificates that should not be trusted. In the right environment, that can turn a local preparation step into a broader integrity problem for outbound connections.
The advisory’s CVSS impact centers on integrity, not confidentiality or availability. That framing makes sense. The core risk is replacement: the application uses attacker-controlled material in place of legitimate material. Whether that leads to meaningful compromise depends on what the application does next, where it connects, and whether the attacker can also influence the network path or certificate presented.
This is where Microsoft’s “conditions beyond the attacker’s control” language becomes concrete. To turn malicious CA material into a useful attack, the adversary may need more than filesystem access. They may need to intercept traffic, influence DNS, control a proxy, or target an application that connects to attacker-controlled endpoints. But enterprise environments are full of proxy layers, service meshes, test endpoints, and internal certificate practices that make “network path influence” less exotic than it sounds.
The Mitigation Is Simple; The Inventory Is Not
The clean answer is to upgrade Requests to 2.33.0 or later. In many environments, that is a routine dependency bump. In others, it is a dependency-tree negotiation involving pinned versions, vendor constraints, packaged applications, and tests that nobody wants to touch. The fix is technically simple; proving you have applied it everywhere that matters is the hard part.Where upgrading is not immediately possible, the most relevant mitigation is to ensure the temporary directory used by the vulnerable process is not writable by untrusted users or lower-privileged contexts. That can mean setting
TMPDIR or equivalent environment variables to a restricted location, isolating service accounts, hardening CI runners, or avoiding shared temp locations for privileged Python processes. This is mitigation, not absolution. It reduces the conditions that make exploitation practical.Developers should also search for direct use of
extract_zipped_paths(). The Requests project says default usage is not affected, so the riskiest pattern is code that intentionally calls the utility. That code may be rare, but rare code paths often live in operational tooling, packaging wrappers, and internal libraries where security review is least formal.Administrators should resist the urge to solve this purely with endpoint cleanup scripts. Deleting stale temp files may reduce some opportunities, but it does not fix a race-prone or predictable trust pattern. If the application can still be convinced to reuse an attacker-created file, the vulnerability remains. The point is not to keep
/tmp tidy; it is to prevent untrusted writers from controlling trusted reads.Scanner Noise Becomes Useful Only When It Finds Ownership
CVE-2026-25645 will arrive in organizations through dependency scanners, GitHub advisories, vulnerability databases, MSRC feeds, distro trackers, vendor bulletins, and probably a few panicked Slack messages that overstate the exploitability. The organizations that handle it well will be the ones that can map a vulnerable package to an owner quickly. The ones that cannot will either overreact broadly or underreact indefinitely.The ownership question is deceptively hard. If Requests is in a product repository, the application team owns it. If it is in a container base image, the platform team may own it. If it is inside a vendor appliance or packaged executable, procurement and vendor management may own the escalation. If it is on a developer workstation, endpoint engineering may be involved. If it is in a CI runner image, DevOps owns the practical fix even if security opened the ticket.
This is why dependency risk has become an operational problem rather than just a development problem. A single library can exist in source code, images, virtual environments, notebooks, Lambda-style functions, MSI payloads, zipapps, and frozen executables. The same CVE can be a false alarm in one place and a meaningful privilege-boundary issue in another.
A good vulnerability program should therefore treat this CVE as a classification exercise. First, find Requests versions below 2.33.0. Second, determine whether the vulnerable function is called directly or whether the application packaging makes the certificate-path behavior relevant. Third, prioritize systems where lower-trust users or jobs can write to temp locations used by higher-trust processes. Fourth, upgrade or isolate. None of that is glamorous, but it is exactly the work that separates risk management from alert collection.
Open Source Did Its Job; Enterprises Still Have to Do Theirs
There is a familiar temptation to frame every open-source CVE as evidence that the commons is fragile. CVE-2026-25645 tells a more complicated story. A widely used project identified or accepted a vulnerability report, shipped a patch, documented the affected version boundary, and clarified the usage conditions. That is the open-source security process working, not failing.The harder question is whether downstream users can absorb the fix. Enterprises often talk about open-source risk as if it lives upstream, but the more stubborn risk lives in the gap between upstream release and downstream deployment. A patched Requests release does nothing for a frozen dependency in an internal tool that nobody has rebuilt since 2024. A clear advisory does nothing for a vendor package that does not expose its Python dependency inventory. A medium CVE can persist for years if no one owns the environment where it runs.
This is especially true in Windows-heavy estates where Python may be treated as a developer convenience rather than managed runtime infrastructure. If Python is installed casually, virtual environments are created ad hoc, and automation scripts are copied between servers, then library patching becomes archeology. Security teams cannot govern what the organization refuses to inventory.
The lesson is not that every Python script needs enterprise ceremony. The lesson is that scripts running with privilege, scripts handling certificates, scripts making network calls, and scripts participating in build or deployment paths are production software whether or not anyone calls them that. Requests is often present precisely in those places because it makes HTTP easy. Ease of use is a feature; invisibility is the liability.
The Patch Is the Easy Part of This Requests Story
The practical response to CVE-2026-25645 is refreshingly concrete, but the surrounding discipline is where organizations will either gain or lose ground. Treat it as a focused dependency update, then use the incident to improve how you reason about temp directories, privileged automation, and embedded Python.- Upgrade Requests to version 2.33.0 or later wherever you control the Python environment.
- Search codebases for direct calls to
requests.utils.extract_zipped_paths()and prioritize those applications for review. - Pay special attention to privileged services, build runners, scheduled tasks, and shared hosts where lower-trust users or jobs can write to temporary directories.
- If an immediate upgrade is blocked, configure the affected process to use a restricted temporary directory that untrusted users cannot pre-populate.
- Do not assume that ordinary Requests usage is exploitable, but do not assume that bundled tools, zipapps, or vendor packages follow ordinary usage.
- Use the CVE as a prompt to inventory embedded Python and frozen dependencies that your standard package-management tooling may miss.
CVE-2026-25645 will probably not become the next famous vulnerability with a logo, a soundtrack, and a week of executive briefings. It is too conditional for that, and Requests has already shipped the right fix. But the next wave of software security failures will look a lot like this: trusted libraries, obscure helper functions, temporary files, packaging shortcuts, and privilege boundaries nobody drew on purpose. The organizations that move fastest will not be the ones that panic over every medium CVE; they will be the ones that can see, patch, and isolate the quiet dependencies before attackers learn to compose them into something louder.
Source: MSRC Security Update Guide - Microsoft Security Response Center
