CVE-2024-35195: Azure Linux Attestation and Microsoft Product Scope

The short answer is: No — Azure Linux is not necessarily the only Microsoft product that could include the vulnerable Requests library; it is, however, the only Microsoft product Microsoft has publicly attested (via its CSAF/VEX outputs) as including the implicated Python Requests package for this CVE at the time of the advisory. That attestation is authoritative for the named product, but it is not an exclusive guarantee that other Microsoft artifacts cannot ship the same open‑source component. s://cve.circl.lu/vuln/msrc_cve-2024-35195)

Background / Overview​

CVE‑2024‑35195 is a medium‑severity vulnerability in the widely used Python HTTP library requests. Prior to the upstream fix, when a program used a long‑lived requests.Session and the first connection to a given origin was created with certificate verification disabled (verify=False), subsequent requests to that same origin could continue to be made without certificate verification for the life of the pooled connection. In other words, a deliberately or inadvertently disabled TLS check on the initial connection could persist across later requests that expected verification. This behavior was fixed in patched releases of Requests.
Microsoft’s public security advisory for CVE‑2024‑35195 includes the wording that “Azure Linux includes this open‑source library and is therefore potentially affected” and states Microsoft will update the CVE/VEX (CSAF) mapping if additional products are later identified. That concise sentence is a product‑scoped inventory attestation — it confirms Microsoft checked Azure Linux and found the component — but , imply that Azure Linux is the only Microsoft product that could contain the vulnerable code.

---

Why the wording matters: product attestation ≠ exclusivity​

Microsoft’s modern approach to supply‑chain transparency uses machine‑readable CSAF/VEX attestations to show, per product family, whether a given CVE maps to the vendor’s artifacts. That model is extremely useful because it provides deterministic, machine‑actionable answers for the product names Microsoft lists — but it also has operational limits.

• A CSAF/VEX attestation is the result of inventory work for the named product family. It proves Microsoft found the component inside the Azure Linux builds it inspected.
• It does not mean Microsoft has exhaustively scanned every Microsoft image, kernel binary, container base image, agent, or SDK in existence.
• Absenanother Microsoft product, the correct interpretation is “not yet attested”, not “not affected.” Treat non‑attested artifacts as unverified until Microsoft says otherwise or you verify locally.

This distinction is practical and important for defenders: Microsoft’s attestation for Azure Linux is a confirmed hit and must be addressed immediately for Azure Linux customers; but organizations that consume other Microsoft‑supplied artifacts — for example, customized VM images, Marketplace appliances, Windows Subsystem for Linux kernels, AKS node images, or internal images created from Microsoft components — should not assume those artifacts are automatically clean.

---

What the public trackers say about the flaw and the fix​

Multiple public vulnerability trackers and distribution advisories describe the same technical picture for CVE‑2024‑35195:

• The problem is in the Requests library’s session/connection pooling semantics: when a pooled connection is established with verify=False, the pool reuses that connection and the “no verification” property persists for the lifetime of that connection. This means subsequent requests may unintentionally bypass TLS verification.
• Upstream Requests authors released fixes; the advisory and trackers point to code changes and a pull request that address the connection reuse and verification semantics.
• The practical mitigations for unpatched environments include: upgrading Requests, avoiding verify=False on first session requests, or explicitly closing Session objects to flush pooled connections after any request that used verify=False.

A few distribution advisories also show how the fix propagated into Linux distros and packages — for example, the Amazon Linux advisories list patched packages and dates — demonstrating that distro maintainers incorporated fixes into their package trees. This is relevant to Azure Linux because Microsoft is in the same business of packaging upstream Python libraries into distribution images.

---

Does Microsoft ship Requests elsewhere? Why Azure Linux being named is not the whole story​

There are two separate questions to answer:

• Does Microsoft include the Requests library in other products or images?
• Does the presence of Requests in any given product necessarily mean that product is vulnerable?

On (1): Microsoft builds, packages, and ships a very wide variety of Linux‑based artifacts: Azure Linux images, CBL‑Mariner derivatives, marketplace images, container base images, VM images, telemetry/management agents, and more. Many of those artifacts either include Python runtimes or are built from base images that include common Python packages. As a result, the same upstream package — in this case python‑requests — can and does appear in multiple Microsoft artifacts. Microsoft’s CSAF/VEX record for this CVE explicitly lists Azure Linux 3.0 and CBL‑Mariner 2.0 packages under the product tree in later revisions, showing that the vendor‑side inventory process found python‑requests in those product builds. That record also shows Microsoft will update the product mapping as they discover more carriers.
On (2): Presence ≠ exploitability in every scenario. The vulnerability requires a specific usage pattern: a session‑pooled connection created with verify=False that is later reused for requests that expected verification. If an artifact includes Requests but the code does not create sessions in that way or never toggles verify=False on first connection, the immediate risk to confidentiality and integrity may be low. However, large codebases, automation scripts, build pipelines, and third‑party Python packages can all inadvertently create the required pattern, so an inventory that finds python‑requests is an operational flag worth triage.

---

Evidence: what Microsoft’s CSAF/VEX and public trackers show​

• Microsoft’s CSAF/VEX JSON for this CVE lists Azure Linux 3.0 (and later revisions add CBL‑Mariner entries) as a known affected product/component, and Microsoft’s advisory language makes clear it will update the CVE mapping if additional Microsoft products are identified. That machine‑readable mapping is the authoritative vendor view for the named products.
• Independent vulnerability trackers (GitLab Advisory, OpenCVE, Safety, Wiz and others) consistently state the technical root caage range (requests < 2.32.0 initially; trackers note later fixed versions and packaging changes), and recommend upgrading or workarounds. Those trackers also document distro package updates and remediation paths.
• WindowsForum and security‑community explainers emphasize the operational model Microsoft used: Azure Linux was audited and attested first as part of a phased VEX rollout; that rollout reduces ambiguity for Azure Linux customers but does not imply Microsoft’s entire product catalogue has been scanned yet. Treat attested products as confirmed and everything else as “not yet verified.”

---

Practical guidance for defenders and Microsoft customers​

If you consume Microsoft artifacts, run Azure workloads, or maintain mixed estates that include Microsoft‑published images, follow these prioritized steps.

1. Prioritize Azure Linux artifacts (if you run them)​

• Microsoft explicitly attested Azure Linux as a product that includes python‑requests for this CVE; treat that as a confirmed in‑scope finding and apply patches immediately for Azure Linux images and nodes.

2. Inventory everywhere else (don’t rely on silence)​

• Treat non‑attested Microsoft artifacts as unverified, not innocent. Search your estate for evidence of python‑requests or embedded Python runtimes:
• For packages: use your distro package manager (rpm -qa / dpkg -l) to find python‑requests packages.
• For Python virtualenvs / containers: run pip list, pip freeze or inspect image layers for /usr/lib/python*/site-packages/requests.
• For Windows artifacts that include Python (agents, developer tools, internal automation): search for bundled vendor Python packages inside installer bundles or extracted image file systems.
• If an artifact includes requests older than the fixed version, tag it for triage.

3. Patch or mitigate​

• Upgrade to a fixed Requests release as upstream recommended; trackers and distro maintainers show the fix landed in the Requests project and in distribution packages. Note that early Requests releases around the fix were adjusted in the release timeline; consult your distro vendor package advisories for the correct patched package for that distribution.
• If you cannot immediately upgrade, avoid making the first session request with verify=False. This is a practical but brittle mitigation.
• Where verify=False is unavoidable for certain hosts, ensure you close the Session after such a request to ensure the connection pool does not retain a non‑verifying connection across requests. That is a recommended temporary workaround until you can apply the upstream fix.

4. Improve detection and reduce blast radius​

• Add aCI pipelines that scan built images and packages for python‑requests versions and flag ones older than the patched threshold.
• For long‑running services, rotate Sessions or connection pools after a configuration change that tightens TLS verification.
• Use runtime instrumentation or network monitoring to detect suspicious TLS flows (for example, unexpected downgrades or lack of certificate validation) if feasible.

5. Use SBOMs and vendor VEX outputs​

• MSRC’s CSAF/VEX outputs are invaluable for determining Microsoft’s own inventory work. If Microsoft has attested a product (e.g., Azure Linux), use that VEX mapping to prioritize patches.
• Maintain your own SBOMs for images, containers, and packaged binaries so you can answer “which components do we ship?” without waiting for vendor attestations. Vendor VEX is helpful, but it is complementary to — not a replacement for — your internal artifact inventory.

---

Attack surface, exploitability, and realistic risk scenarios​

CVE‑2024‑35195 is particularly concerning because it affects TLS verification — a fundamental security property — and misuse can lead to man‑in‑the‑middle (MITM) risk. However, exploitation requires a specific set of conditions:

• The vulnerable Requests version must be present in the runtime environment.
• The application must use a requests.Session that reuses pooled connections to the same origin.
• The first connection to that origin must be created with verify=False (or equivalent behavior, such as a patched global SSLContext that disables verification).
• An attacker must be able to intercept or influence the network traffic to the target origin if they want to perform a classic MITM. In some analyses the exploit vector is considered local or dependent on environment (for example, when the attacker has some level of control over the environment or network). Trackers have reported differing CVSS details, but most list the complexity as moderate and the confidentiality/integrity impact as high if an attacker can exploit it.

In short: the vulnerability is serious where the conditions exist, but it is not a simple unauthenticated remote exploit that works against all deplolies where automation scripts, CI jobs, or agents use sessions and sometimes deliberately bypass verification (for example in integration testing or when talking to a lab server), and those same sessions are later used against production endpoints.

---

Critical analysis: strengths and gaps in Microsoft’s approach​

Microsoft’s move to publish CSAF/VEX attestations is a strong positive stepnsparency. A few important strengths and caveats:

• Strengths
• Machine‑readable attestations let customers automate triage: if Microsoft lists a product as “known affected” or “fixed,” defenders can integrate that signal directly into patch orchestration. This reduces uncertainty for the named product families.
• Clear wording — Microsoft’s advisory language deliberately limits claims to the product the company inspected, which avoids overpromising. That precision is operationally useful for both vendors and customers.
• Gaps and risks
• Phased rollouts leave windowed uncertainty. Large vendors cannot inventory every artifact instantaneously. A VEX entry that names Azure Linux as a known carrier is an immediate signal for that product — but other Microsoft artifacts remain “not yet attested” during the phased rollout. Customers who assume “not named = not affected” risk missing vulnerable instances.
• Hidden carriers in images and bundles. Microsoft publishes many images that include layers or binaries assembled from upstream components. A python‑requests package can be bundled in unexpected places (container images, nested virtualenvs inside installers, or agent bundles). Unless those are scanned, they remain invisible to a product‑level attestation.
• Operational friction around fixes. Upstream fix releases and downstream distro packaging can be non‑linear (e.g., initial fix releases being yanked, versions advanced, distro packaging differences). That can cause confusion about which patched package version to install; customers must rely on vendor advisories or distro package metadata to choose the correct patched package. Trackers and distro advisories show that packaged fixes landed in multiple distributions at different times and sometimes with different package version numbers.

---

Recommended actions for Microsoft (vendor-side recommendations)​

While Microsoft’s CSAF/VEX pilot and product attestations are valuable, these steps would strengthen customer protection:

• Expand attestation coverage to more product families with a prioritized rollout for artifacts that are widely consumed (containers, marketplace images, telemetry agents).
• Publish clear mapping of package names and exact patched package versions that customers should install per product. This reduces the fragmentation caused by differing distro package names and versioning.
• Provide guidance and tooling examples for large customers to scan Microsoft images quickly for vulnerable packagted SBOM extraction examples for Azure Marketplace images and container SKUs).
• Where feasible, proactively scan published artifacts for common interpreters and bundled packages (Python, Node, Java) and publish a higher‑level index of commonly embedded open‑source packages that can be searched programmatically.

---

Conclusion​

Microsoft’s public statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate and important: it confirms a vendor‑side inventory result for a named product and gives Azure Linux customers a clear remediation path. However, that statement is a product‑scoped attestation, not a blanket exclusion of other Microsoft products. The correct operational takeaway is:

• Treat Azure Linux as a confirmed carrier and patch it urgently.
• Treat other Microsoft artifacts as unverified until either Microsoft publishes an attestation for them or you verify locally — do not assume they are unaffected simply because they are not named.
• Use SBOMs, automated image scanning, and the practical mitigations (upgrade Requests, avoid verify=False on the first session request, close Sessions when needed) to reduce your exposure while vendor‑specific patches propagate.

If you operate in mixed‑cloud or multi‑vendor environments, a small but disciplined investment in per‑artifact inventory and automated image scanning will pay dividends: it turns vendor attestations from a helpful guide into a complete security posture that you can act on immediately.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center