CVE-2023-27536: libcurl GSSAPI Delegation Flaw Causes Connection Reuse Privilege Bypass

A subtle connection-reuse bug in libcurl—tracked as CVE-2023-27536—exposed a real-world risk that the library could accidentally reuse an authenticated connection with higher GSSAPI/Kerberos delegation permissions for a subsequent transfer that should have been performed with lower permissions. The practical consequence is an authentication bypass: a later request might inherit the privileges of a prior one simply because the library’s connection-pooling logic omitted a necessary check for changes to the CURLOPT_GSSAPI_DELEGATION option, and several major vendors (including multiple Linux distributions) issued patches to mitigate the problem. Independent vulnerability trackers and the NVD all document the root cause as libcurl reusing pooled connections without checking the GSSAPI delegation setting.

---

Background / Overview​

libcurl is one of the most widely embedded networking libraries in the open-source ecosystem. It provides a generic URL transfer engine that many command-line tools, system packages, and applications depend on. Because libcurl supports advanced authentication flows such as Kerberos/GSSAPI (a.k.a. Negotiate), it also exposes surface area where misconfigured or improperly checked authentication options can cause privilege leakage between connections.
CVE-2023-27536 was publicly assigned after upstream maintainers and researchers discovered that libcurl versions earlier than 8.0.0 could reuse a connection from the connection pool even when the application had changed the CURLOPT_GSSAPI_DELEGATION option between transfers. In plain terms: if transfer A allowed credential delegation and transfer B did not, libcurl’s pool matching logic might nonetheless choose the same TCP/TLS connection and continue using the previously delegated security context—thereby giving the second transfer access it should not have. The NVD and multiple distribution advisories summarize the defect and recommend treating connection reuse as unsafe when the delegation option changes.
That technical failure is intentionally narrow but meaningful: it affects only GSSAPI-based authentication flows (Kerberos/krb5/Negotiate) where delegation semantics matter. The attack surface is situational—an attacker would need to influence or interleave transfers in a way that causes one transfer to run under a delegated security context and another to run on the same pooled connection where delegation is intended to be disabled. Because real systems can and do reuse connections for performance reasons, the vulnerability was treated seriously enough for multiple vendors and distributions to ship fixes. Advisories and patch notices across SUSE, Amazon Linux, Ubuntu, and others document the issue and the downstream package updates.

---

What Microsoft actually said — and what it means​

Microsoft’s MSRC entry for this CVE contains the concise phrase many customers have seen before: “Azure Linux includes this open‑source library and is therefore potentially affected.” That sentence is a product-level attestation: Microsoft has inventory-checked the Azure Linux images and confirmed the vulnerable upstream library is present in that product family. The text, however, is not a universal claim that Azure Linux is the only Microsoft product that could possibly inltiple internal and public analyses of Microsoft advisories have emphasized that Microsoft’s wording is an attestation of what Microsoft has checked and published, not an absolute exclusion of all other artifacts. In other words, Azure Linux is a confirmed carrier for the upstream component in Microsoft’s inventory work so far—other Microsoft artifacts remain subject to artifact-level verification.
Microsoft’s broader transparency program—its adoption of machine-readable CSAF advisories and VEX attestations—explicitly aims to remove ambiguity by providing deterministic, per-product statements of status (Not Affected, Under Investigation, Known Affected, Fixed). Microsoft announced the expansion of machine-readable VEX attestations in October 2025 as part of that transparency work; those attestations are the canonical mechanism Microsoft uses to expand or update product mappings for CVEs in a clear, automaft updates the CVE record or publishes additional VEX attestations naming other products, Azure Linux remains the only Microsoft product publicly listed for this particular CVE—but that public listing is a statement of current inventory, not a technical guarantee that no other Microsoft image, package, or binary includes libcurl and therefore could be affected.

---

Technical summary of CVE-2023-27536​

How the bug works​

• libcurl maintains a connection pool to improve throughput and reduce latency by reusing existing TCP/TLS connections for successive transfers to the same destination.
• Each connection in the pool is matched against a new transfer’s configuration before reuse. The match must ensure the connection’s existing security and protocol state is compatible with the new request’s requirements.
• In the affected libcurl versions (<8.0.0), the GSSAPI delegation setting (CURLOPT_GSSAPI_DELEGATION) was not considered during that match. If the option was changed between transfers, libcurl could still pick the older connection.
• If the older connection had been used with delegation enabled, the associated security context could remain usable for the follow-up transfer—granting it more privileges than intended.

This is not a remote code execution bug; it is an authentication/authorization bypass that can allow sensitive information to be inadvertently exposed or operations to be performed under an unintended identity. Several vulnerability trackers assigned a medium severity rating (for example, CVSS 3.x 5.9 in many entries) and distribution maintainers prioritized patching where libcurl is used in GSSAPI contexts.

Which code paths and configurations matter​

• The vulnerability is relevant only when libcurl is used for GSSAPI/Kerberos/Negotiate transfers.
• It matters only when the application modifies CURLOPT_GSSAPI_DELEGATION between transfers that might reuse the same connection.
• Applications that a) never use GSSAPI/Negotiate, or b) always set the same delegation policy for every transfer, are not exposed to the risk introduced by this specific bug.
• Systems that forcibly disable connection reuse (for example, via CURLOPT_FORBID_REUSE or policy-level connection closing) are not vulnerable to the reuse-path exploitation, although disabling reuse can have performance costs.

Multiple distribution advisories confirm the same triage and mitigation guidance: upgrade libcurl to a patched release, or apply a distribution package update that contains the fix.

---

Is Azure Linux the only Microsoft product that includes libcurl and is therefore potentially affected?​

Short, operational answer: No—Azure Linux is not necessarilyrude libcurl and be affected; it is the only Microsoft product Microsoft has publicly attested so far as including the upstream library for this CVE. That distinction matters deeply in the security operations context.

• When Microsoft writes “Azure Linux includes this open‑source library and is therefore potentially affected,” it means Microsoft has completed inventory checks for that product family and published an attestation for it. This is a positive action: it tells Azure Linux customers exactly what to patch and where to focus remediation. However, that wording is not a proof that no other Microsoft artifact includes the same library or could be affected; it simply reflects the scope of Microsoft’s published inventory at the time of the advisory.
• Historically Microsoft has expanded those mappings as its artifact scanning and VEX/CSAF attestation program matured—Microsoft’s published VEX program (announced in October 2025) is explicitly intended to make these mappings machine-readable and updateable. Until Microsoft publishes additional VEX attestations or updates the CVE’s product list, customers should treat Azure Linux as a confirmed carrier while also verifying other Microsoft-supplied artifacts in their environments.

In short: the statement on the MSRC page is authoritative for what Microsoft has checked, but it is not a technical proof of exclusivity. Customers should not interpret “only Azure Linux” as a guarantee that other Microsoft products are safe—inventory verification is required per product and per artifact.

---

Why this distinction matters for defenders and operators​

• Microsoft distributes software in many shapes: cloud images, Linux distro builds (Azure Linux), Windows components, application installers, agent binaries, containers, and more. A vulnerable upstream library can be present in multiple artifacts in ways that are easy to miss if you rely on a single product-level attestation.
• Attestation scope vs. artifact scope:
• A product-level attestation (e.g., “Azure Linux includes this library”) confirms an inventory check for that product family.
• An artifact-level verification (or VEX/CSAF attestation) is needed to determage, binary, container, or package in your estate includes the vulnerable component.
• Operational consequence:
• If you run Azure Linux images, treat Microsoft’s attestation as a direct operational call-to-action.
• If you run other Microsoft-distributed artifacts—Windows hosts with libcurl binaries, container images from Microsoft Container Registry, Edge/Teams builds, WSL kernels or distro images, or custom agents—you must perform artifact-level checks to determine whether they include the vulnerable libcurl version.

This is not academic: several historical advisories from Microsoft demonstrated the pattern of initially naming a single product as a confirmed carrier and later updating the CVE record when additional Microsoft artifacts were found to include the same vulnerable component. Until Microsoft updates the record, defenders should rely on their own harvest-and-verify process.

---

How to verify whether your Microsoft-supplied artifacts are affected​

Below are pragmatic steps to discover and remediate possible exposure across a mixed environment.

• Inventory first (artifact-level):
• Identify images and binaries that might embed libcurl. Typical places: Linux system packages (rpm/dpkg), containers, WSL distributions, and application installations.
• For Windows endpoints, search for curl/libcurl DLLs in system directories (System32, SysWOW64) and examine vendor-supplied application folders. A useful starting command on Linux: check the package manager’s installed curl/libcurl packages and versions (for example, rpm -q curl or apt list --installed | grep curl). On Windows, query file-version information for curl/libcurl DLLs and check vendor advisories for bundled versions. (Vendor-specific guidance will vary; Microsoft’s Q&A threads show customers asking about curl/libcurl versions found in Windows images and Microsoft responding that updates and timelines are product-specific.)
• Use vendor-provided machine-readable attestations where available:
• Subscribe to Microsoft’s CSAF/VEX feeds if you rely on Microsoft artifacts; these feeds are intended to give deterministic product-by-CVE status and will be updated if Microsoft discovers additional carriers. Microsoft announced this capability to increase transparency and reduce uncertainty; use it as a primary signal to supplement your artifact scanning.
• Scan artifacts with SBOM and binary-scanning tools:
• If you maintain Software Bill of Materials (SBOMs) for your images, cross-check them for libcurl versions < 8.0.0.
• For binaries and containers, run a dependency scanner that can detect libcurl usage and report exact versions.
• Prioritize remediation by exposure:
• Public-facing services or services that accept untrusted inputs and use GSSAPI/Kerberos are higher priority.
• Internal-only services that do not use GSSAPI or always enforce identical delegation settings are lower priority.
• Patch or mitigate:
• Apply vendor-supplied patches: distribution patches that upgrade libcurl or backport the fix are the primary remediation. Many Linux distributors released updates quickly after the CVE disclosure.
• If you cannot patch immediately, consider disabling connection reuse for affected components (CURLOPT_FORBID_REUSE or similar) or explicitly control delegation settings so they never vary across transfers that might reuse a connection.

---

Recommended remediation & mitigation checklist​

• Patch: upgrade libcurl to the patched version provided by your distribution or the upstream libcurl release that contains the fix. Distribution advisories (Ubuntu, SUSE, Amazon Linux, Red Hat, etc.) document the exact package updates and should be followed.
• Application hardening:
• Audit applications that use libcurl for Negotiate/Kerberos/GSSAPI authentication.
• Where feasible, avoid changing CURLOPT_GSSAPI_DELEGATION between successive transfers to the same destination.
• If you must change delegation semantics, use connection-close semantics between transfers, or explicitly forbid reuse for that transfer.
• Monitoring and detection:
• Add telemetry to identify unexpected successful transfers under delegated contexts.
• Instrument server-side logs to detect anomalous sequences where a low-privilege request is served on a connection that previously carried delegated operations.
• Vendor coordination:
• Subscribe to Microsoft’s security update feeds and CSAF/VEX outputs for pdates.
• Engage application vendors if you find libcurl is embedded inside third-party binaries; require them to patch or provide a mitigation timeline.

---

Strengths, limitations, and risk analysis​

Strengths​

• The bug is narrow and well-defined: it affects a specific connection-match logic path and a specific option (CURLOPT_GSSAPI_DELEGATION). This makes detection, proof-of-concept reasoning, and mitigation achievable without wholesale redesign.
• Most mainstream Linux distributions and many vendors quickly distributed patches and mitigations. Multiple distribution advisories and upstream documentation provide clear guidance about patched package versions.
• Microsoft’s adoption of machine-readable VEX/CSAF attestations improves transparency and creates a mechanism for deterministic mapping of CVEs to Microsoft artifacts going forward. That program reduces ambiguity for customers who can consume those feeds.

Limitations and risks​

• Product-scoped attestation is not the same as full artifact coverage. When Microsoft states that “Azure Linux includes this open-source library and is therefore potentially affected,” it is confirming the inventory for Azure Linux—not asserting exclusivity across all Microsoft offerings. Customers cannot assume an advisory’s absence of other product mentions is a guarantee of safety for other artifacts. That is a practical and persistent risk in modern supply chain security.
• The library’s ubiquity increases blast radius. libcurl is embedded in many packages and applications; unpatched instances can hide inside vendor-supplied agents, containers, or binaries that are not directly managed by distribution package managers.
• Detection is non-trivial. Exploitation depends on transfer sequencing, delegation usage, and connection reuse patterns that may be rare in typical telemetry. As such, absence of detected incidents does not mean absence of exposure.
• Operational mitigations (like disabling reuse) are sometimes impractical because they affect performance and connection economies, so many operators will prefer patching to workarounds. However, in the short term, targeted mitigations such as forbidding reuse for GSSAPI flows can be a practical control.

---

Practical examples and guidance for common environments​

If you run Azure Linux images​

• Treat Microsoft’s attestation as a confirmed hit: check your Azure Linux images for the patched package and follow the update guidance published for the distribution. Microsoft’s product-level statement specifically calls out Azure Linux as a product that includes the vulnerable library—address those images immediately.

If you run Windows servers or Microsoft-provided Windows software​

• Do not aequals “not affected.” Microsoft may not have finished inventorying every artifact; check the specific binaries (System32, SysWOW64) or application folders and consult the vendor’s guidance and update channels. Community and Microsoft Q&A threads show customers asking about libcurl versions in Windows, and responses indicate update timing is product-specific—so verify per product. ([learn.microsoft.coosoft.com/en-us/answers/questions/3846002/curl-and-libcurl-vulnerability)

If you run containers (including Microsoft container images)​

• Scan container images for libcurl instances and apply patched images. If you depend on third-party containers that include libcurl, require vendors to provide patched images or rebuild images with updated base packages.

---

Cross-referencing and verification​

This analysis cross-checks multiple independent sources for the key technical claims:

• The NVD entry for CVE-2023-27536 documents the root cause and affected versions.
• Distribution advisories (Ubuntu, SUSE, Amazon Linux) and public vulnerability trackers corroborate the vulnerability description, the affected libcurl versions (<8.0.0), and the mitigation strategy of upgrading to patched packages.
• Analytic write-ups and vulnerability databases explain the exploitation scenario and the recommended temporary mitigations (disable reuse, forbid reuse when delegation changes).
• Microsoft’s machine-readable VEX/CSAF program and the company’s public attestation practice clarify why Azure Linux was named and how Microsoft intends to update CVE mappings going forward. Customers should consume VEX feeds and the Security Update Guide for authoritative, product-scoped attestation updates.

Where claims about Microsoft’s wording or scope are not explicit on the MSRC web page (which uses a web app interface), Microsoft’s public advisories and documentation plus the company’s VEX program text make the meaning and intent clear: attestations are product-scoped and can be extended when additional carriers are identified. This is an important operational nuance that is sometimes overlooked.

---

Final recommendations for administrators and security teams​

• Treat Microsoft’s Azure Linux attestation as an actionable confirmation for Azure h or apply the updated Azure Linux packages as recommended.
• Do not interpret the absence of other Microsoft product names in the MSRC CVE entry as a guarantee of safety for those products. Instead, perform artifact-level inventory and scanning across your estate (Windows images, container images, application bundles, WSL, agents).
• Subscribe to and automate ingestion of vendor CSAF/VEX feeds where possible (Microsoft’s VEX is an important source for product-specific status).
• For immediate mitigation in systems where you cannot patch quickly: consider forbidding connection reuse for transfers where delegation semantics might vary, or enforce consistent delegation settings across transfers. These are stopgap measures and not substitutes for applying the vendor patch.
• Maintain telemetry on authentication flows and anomalous use of delegated credentials—if a lower-privilege request returns data typically associated with a delegated identity, treat it as a possible indicator of misuse or an artifact of connection reuse.

---

Conclusion​

CVE-2023-27536 is an example of how a small omission in a connection-matching check can translate into an authentication bypass in real deployments. The vulnerability was real, documented across multiple independent sources, and patched by upstream libcurl and by distribution maintainers. Microsoft’s statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate and operationally useful for Azure Linux users, but it is not a technical guarantee that no other Microsoft product is affected. Microsoft’s VEX/CSAF attestations are explicitly designed to remove this ambiguity over time, and customers should use those machine-readable signals plus artifact-level scanning to determine their true exposure.
The practical path forward for defenders is clear: patch where available, verify artifact inventories (don’t rely solely on product-level wording), and use short-term mitigations when patching cannot be performed immediately. That combination of patching, verification, and temporary mitigation will contain the risk while supply-chain transparency mechanisms (CSAF/VEX) mature and broaden their coverage across complex software ecosystems.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center