CVE-2023-27535: libcurl FTP Connection Reuse Risk and Azure Linux Attestation

CVE-2023-27535 exposed a subtle but meaningful weakness in libcurl’s FTP connection reuse logic that could allow a follow‑up transfer to run with the wrong credentials; Microsoft’s public advisory names Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” but that product‑level attestation is not a technical guarantee that no other Microsoft artifact ships the same library or could be affected.

Background / Overview​

libcurl is one of the most widely embedded network libraries in modern software. It provides protocol support (HTTP, HTTPS, FTP, SFTP and many more) and is used directly by the curl command‑line tool and embedded inside countless applications as a library (libcurl). The design choice that makes libcurl fast — keeping sockets alive and reusing connections from an internal connection pool — is the same behavior that created the risk exploited by CVE‑2023‑27535.
In short, the problem is this: libcurl reused a previously opened FTP connection even when a subsequent transfer had changed configuration options that could change the effective authentication context (for example the FTP account used, an alternative username, SSL/CCC flags, or whether SSL was used at all). Because the connection‑matching logic omitted several FTP‑specific options from its equality checks, two different logical sessions could be treated as identical and share the same connection — which sometimes meant the second transfer would run using the first transfer’s authentication context. The curl project fixed the bug in the 8.0.0 release.
Why that matters: if an application performs multiple FTP transfers (to the same host/port) under different credentials or security modes, a reused connection carrying the wrong credentials can expose files or allow unintended actions under a different identity. Unlike some remote code execution or memory corruption bugs, the risk here is about privilege and data access resulting from incorrect authentication handling.

---

The technical root cause (concise)​

• libcurl maintains a connection cache to avoid the overhead of establishing new TCP/TLS sessions for each transfer.
• When preparing a new transfer, libcurl compares the requested options with each cached connection; if it finds a match it will reuse the connection.
• For FTP the matching logic failed to consider several options that materially affect authentication and session behavior: CURLOPT_FTP_ACCOUNT, CURLOPT_FTP_ALTERNATIVE_TO_USER, CURLOPT_FTP_SSL_CCC, and CURLOPT_USE_SSL.
• Because those options were omitted, connections matched too broadly and could be reused when they should not have been, producing an authentication bypass by misapplied reuse.

---

Scope: what versions and where it was fixed​

• Affected upstream libcurl versions: curl 7.13.0 through 7.88.1 (the project recorded the issue and released the coordinated fix in curl 8.0.0 on March 20, 2023).
• Distributions and vendors released their own advisories and patches; major Linux distributions issued errata and updated the libcurl/curl packages. Example vendor advisories and distribution packages list and patch status were published by NVD, Ubuntu, Red Hat derivatives, and others.

Patch → Validate: the only truly reliable remediation is to run a patched libcurl (upstream >= 8.0.0 or the distro equivalent backport). Many distributors provided fixes packaged into their curl/libcurl releases; operators should confirm the actual libcurl binary or library version in each runtime and apply vendor patches where available.

---

What Microsoft publicly stated — and how to read it​

Microsoft’s public CVE entries sometimes use a concise pattern of wording that reads:
“Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability. If impact to additional products is identified, we will update the CVE to reflect this.”
That formulation is an authoritative, product‑level attestation that Microsoft has inspected Azure Linux images and found the upstream component there. It is not an explicit technical statement that no other Microsoft product contains the same upstream library. In practical terms, Azure Linux is a confirmed carrier for the implicated upstream component; other Microsoft products that ship their own images, binaries, or bundled third‑party components may or may not contain the same vulnerable libcurl — and those artifacts require independent verification.
Two practical implications of that wording:

• For customers running Azure Linux images, Microsoft’s attestation is an explicit signal to prioritize remediation for those instances, and it is authoritative for that product family.
• For customers running other Microsoft software (including Windows, managed agents, SDKs, or marketplace images)xplicit mention does not equal safety; you must verify artifact contents or wait for Microsoft to expand the mapping via their CSAF/VEX attestations or CVE page updates. Microsoft has also committed to publishing machine‑readable VEX/CSAF mappings and to update them when further products are identified.

---

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

Short answer: No — Azure Linux is the only Microsoft product that Microsoft has publicly attested (so far) to include the vulnerable libcurl for this particular advisory, but that attestation is product‑scoped and not an exclusivity guarantee. Other Microsoft artifacts can and do ship libcurl (or a copy of it), and those must be inventoried, inspected, and patched independently.
Why this matters in real environments:

• Microsoft supplies a Windows build that includes a curl executable; modern Windows releases include a curl binary by default and Windows’ curl is built from the upstream curl sources. That means Windows and Windows‑based tools may ship a libcurl-based component (curl.exe and any libcurl.dll it loads). Administrators should therefore inspect the Windows curl version and any libcurl.dll files that might be bundled with third‑party or Microsoft applications.
• Many Microsoft products, partners, and third‑party tools that run on Windows or Linux embed libcurl inside their installers, agents, and services. These include some SDKs, update agents, backup and sync clients, and other networked services. Where an application bundles its own libcurl, that copy must be patched separately.

Put differently: Microsoft’s phrasing is useful and authoritative for Azure Linux customers, but for defenders the correct operational posture is to assume there may be other Microsoft artifacts that carry the same vulnerable code until you can prove otherwise through inventory or vendor VEX/CSAF outputs.

---

Evidence that other Microsoft artifacts can include libcurl​

• Windows ships a curl binary by default; the Microsoft‑provided build is assembled from the same upstream source but may use different features and TLS backends (e.g., Schannel). That build (and any libcurl DLLs loaded by Windows applications) is a practical vehicle for vulnerable libcurl code if it is not updated.
• Microsoft public help threads and Q&A show administrators routinely find libcurl.dll copies inside Microsoft products and third‑party programs on Windows — updating Windows alone does not remediate those sideloaded copies; each app that bundles libcurl may need its vendor update. Microsoft guidance points operators to scan for libcurl.dll, identify file versions, and update each affected component.
• Independent vendors (IBM, Oracle, Red Hat, Ubuntu) published advisories for CVE‑2023‑27535 for their products that ship libcurl; that ecosystem response demonstrates how ubiquitous the library is across platforms and vendor stacks. Microsoft’s Azure Linux attestation fits the same pattern of product‑scoped inventory checking rather than a universal sweep across all Microsoft artifacts.

---

Operational checklist: how to verify and remediate across Microsoft‑supplied systems​

Treat this as an operational runbook. The goal is to discover every occurrence of vulnerable libcurl (or curl executable) across your environment and apply the appropriate vendor patch or a mitigation that reduces the risk until a patch is applied.

• Inventory and discovery (Linux)
• On every Linux host (including Azure Linux images), check the package manager for the installed curl/libcurl package and its version. Ensure the installed build is a patched vendor package or an upstream >= 8.0.0 build.
• For non‑packaged deployments (containers, custom builds), inspect the container image or the binary’s linked libraries to determine the libcurl version.
• Inventory and discovery (Windows)
• Run curl --version from a command prompt to see the system curl binary version.
• Search for libcurl.dll files in Program Files, Program Files (x86), and other application directories (PowerShell example: recursively search for libcurl.dll and check the file version in file properties).
• Check installed applications that commonly bundle network libraries (for example: backup agents, SQL Server shared components, Office add‑ons, Git for Windows) and query those bundles for libcurl versions. Microsoft Q&A threads show this is an effective tactic.
• Prioritize remediation
• If a vendor package (distribution or Microsoft) has published a fix for curl/libcurl, apply that vendor’s update rather than attempting a manual binary swap, unless vendor guidance explicitly endorses it. For Azure Linux, Microsoft’s attestation signals you must prioritize those images.
• For third‑party apps that bundle an old libcurl, update the app to a vendor release that includes a patched libcurl; if an update is not available, reach out to the vendor for guidance.
• Temporary mitigations for embedded or custom code
• If you control the source code of an app that uses libcurl and cannot immediately upgrade the library, consider defensive options:
• Use libcurl options to prevent reuse of pooled connections for sensitive FTP transfers: CURLOPT_FORBID_REUSE will force libcurl to close the connection after the transfer, preventing reuse-based cross‑contamination; CURLOPT_FRESH_CONNECT forces a fresh connection for the request. These mitigations reduce risk but can significantly affect performance and are a stopgap, not a replacement for patching.
• Where possible avoid FTP for sensitive data flows until the library is patched, or enforce strict network segmentation to limit exposure of FTP servers.
• Add explicit server‑side controls (per‑session account restrictions, strong session isolation) where you manage thitoring and logging
• Audit FTP transfers and authentication sources; unusual access patterns where an account that should not have access to certain files does so can indicate a reuse‑related issue.
• Add temporary alerting on anomalies in FTP server logs: e.g., same TCP/TLS session used by multiple different usernames within a short time window.
• SBOMs and vendor VEX/CSAF
• Use any available SBOMs and vendor‑published VEX/CSAF outputs to map vulnerable components to installed product artifacts. Microsoft has indicated a programmatic path forward for machine‑readable attestations and has committed to update mappings if additional Microsoft products are found to ship the component. Until those attestations are available for every artifact you rely on, rely on your own artifact scanning.

---

Detection recipes and quick commands​

• Check the system curl version (Linux / macOS / Windows curl binary):
• Run: curl --version — confirm libcurl version shown.
• On Linux (package queries):
• Debian/Ubuntu: apt list --installed | grep curl or dpkg -l | grep curl
• RHEL/CentOS: rpm -qa | grep curl
• On Windows, find libcurl.dll copies and file version (PowerShell snippet):
• Recursively search common prolibcurl.dll, then check file version metadata to identify older copies. Microsoft guidance recommends this approach when apps bundle their own DLLs.
• Within applications:
• If you have a long‑running service that embeds libcurl, confirm its runtime library version by either checking the package supplied by that service, vendor documentation, or by using process inspection tools that can list loaded DLLs and their file versions.

---

Practical risk analysis for Microsoft customers​

• Azure Linux customers: treat the Microsoft attestation as a confirmed hit for the distro — patch or update those images and rebuild any derived images that include the vulnerable package. Microsoft’s attestation is the reason Azure Linux should be remediated immediately.
• Windows customers: do not rely on an absence of an MSRC attestation to conclude safety. Windows itself ships curl/curl.exe and many Windows apps bundle libcurl. Each installed application that might include libcurl is a potential exposure point and must be inventoried and managed separately. Microsoft help threads and internal guidance recommend searching for libcurl.dll and patat bundle vulnerable copies.
• Enterprise SaaS and managed services: If you run Microsoft managed services or third‑party services on Microsoft infrastructure, ask vendors for their component mappings and patch status, and request SBOM or VEX/CSAF attestations where feasible.

---

Strengths and limits of Microsoft’s attestation approach (critical analysis)​

Strengths

• Product‑scoped attestations are operationally useful: Microsoft’s statement that Azure Linux includes the library tells customers exactly where Microsoft has completed an inventory for that product and therefore where to prioritize fixes.
• The commitment to publish machine‑readable VEX/CSAF mappings (announced as part of MSRC transparency work) is a positive step; automated attestations make it faster for enterprise tooling to map CVEs to deployed artifacts.

Limits and risks

• Product‑scoped wording risks being misread as a universal guarantee: defenders who treat the absence of other product names as meaning those products are safe may be exposed.
• Microsoft’s attestation cadence necessarily lags; large vendors have thousands of artifacts, and a single CVE can appear in many places (OS images, SDKs, docker images, managed agents). Until attestations are exhaustive and continuously updated, organizations must perform artifact‑level verification.
• The library’s ubiquity means that OS patching alone is insufficient on Windows — many applications ship their own copy — and that reality creates an operational burden for patch managers. Microsoft support threads show administrators having to search for and replace or update multiple libcurl copies inside the same host.

Recommendation: treat Microsoft’s attestation as high‑quality signal about Azure Linux and a commitment to transparency, but not as a comprehensive, cross‑product guarantee. Confirm by scanning images and apps, and follow the principle of “assume presence until proven otherwise.”

---

Responsible disclosure and supply‑chain lessons​

CVE‑2023‑27535 is a problem: an upstream library bug affects many downstream consumers, and vendor attestations provide important but incomplete visibility. The operational takeaways for defenders include:

• Build automated inventory and SBOM‑driven pipelines that can correlate CVEs to deployed binaries and container images.
• Force vendor accountability for machine‑readable attestations where possible; VEX/CSAF is a primary mechanism for that.
• Design application code to fail safely: in the short term, use conservative libcurl options for sensitive FTP flows (e.g., CURLOPT_FORBID_REUSE, CURLOPT_FRESH_CONNECT) and server‑side session controls to reduce the magnitude of unintended reuse problems.

---

Conclusion: what every administrator should do today​

• For Azure Linux images: follow Microsoft’s attestation — patch the libcurl/curl package or redeploy updated images immediately. Microsoft’s public attestation is an authoritative signal for those images.
• Across all environments (including Windows and any machines running Microsoft agents or third‑party software): conduct a fast inventory for curl and libcurl.dll, identify versions, and apply vendor plication releases that include patched libcurl builds. Windows deployments can include multiple copies of libcurl hidden inside application folders; those must be found and updated individually where necessary.
• When you cannot patch immediately: apply mitigations in code (preventing connection reuse for sensitive transfers), adjust network controls for FTP servers, and add monitoring for anomalous FTP activity. CURLOPT_FORBID_REUSE and CURLOPT_FRESH_CONNECT are effective temporary options for libcurl‑using applications, but they are a stopgap, not a permanent substitute for an updated library.
• Demand SBOMs and watch for Microsoft VEX/CSAF updates as they publish machine‑readable attestations; but do not delay your own artifact scanning believing that an attestation absence equals safety. Microsoft has pledged to update CVE mappings if additional products are identified; until then, perform your own verification for all Microsoft artifacts you run.

CVE‑2023‑27535 is a reminder that connection reuse optimizations must be implemented with an eye toward authenticity boundaries. Vendor attestations — including Microsoft’s product‑scoped notices — are a valuable tool in the defender toolkit, but they must be combined with artifact‑level verification and prompt patching to deliver real security.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center