CVE-2023-27534: Curl SFTP Tilde Path Traversal Explained and Patched

When a single character — the humble tilde (~) — is handled incorrectly, the result can be more than just a parsing glitch: it can be a pathway out of intended restrictions and into other users’ files. CVE‑2023‑27534 is exactly that kind of bug: a path‑traversal flaw in curl’s SFTP path handling that caused tilde expansion to happen in the wrong locations, letting crafted paths such as /~2/foo resolve in unexpected ways and enabling attackers to bypass filtering or access unintended files. This article walks through the technical root cause, exploitation scenarios, the patching timeline, the confusing differences in severity assessments, practical mitigations for defenders, and the realistic risk profile for Windows and Linux environments.

Background / Overview​

SFTP URLs in curl include a path component where the tilde character has a special meaning: when used as the first path element the tilde designates a path relative to a user’s home directory (for example, ~/file maps to /home/you/file on many systems). This convention derives from early SFTP URL drafts and has been implemented in curl’s SFTP support for many years.
CVE‑2023‑27534 (disclosed March 2023) arises from a subtle off‑by‑context bug in curl’s SFTP path parsing: the implementation replaced tilde prefixes not only when the tilde was the standalone first path element but also when it appeared as a prefix inside the first element. That means a request for /~2/foo could be unexpectedly converted into a home‑directory expansion — e.g., /home/dan2/foo when the active user is dan — allowing traversal out of an expected subtree and potentially bypassing server- or application-level filters. The vulnerability affects curl versions prior to 8.0.0.

---

What went wrong: technical anatomy​

How tilde expansion should work​

• In normal SFTP semantics as implemented by clients, the tilde only has special meaning when it stands alone as the first path element (for example, sftp://host/~user/path or sftp://host/~/path).
• When the tilde stands elsewhere — for example embedded in a deeper path element such as /uploads/~user/file or /path/~/file — it should not be treated as a home expansion. It should be considered literally part of the path component.

The bug: context was lost​

• The vulnerable code performed tilde expansion by examining the first path element but failed to verify whether the tilde was the entire first element or merely a prefix.
• As a result, the string-comparison/expansion logic turned a path element beginning with '~' (even if it was not the sole element) into a home-directory expansion. This allowed an attacker‑controlled path segment to be interpreted as a user lookup rather than remaining a literal path.

Concrete example​

Request:
sftp://dan@example.com/~2/foo
Observed (vulnerable) resolution:

• curl treats “~2” as a home expansion relative to the current user dan, and expands it to something like /home/dan2/foo (or similar per server mapping), effectively letting the request escape the intended / root or a confined directory.

This simple example demonstrates why the bug is more than string handling: it changes the semantic meaning of a path component in ways that can bypass safeguards.

---

Affected versions and the fix​

• The flaw was present in curl releases up to and including the 7.88.x liessed before the 8.0.0 release. Multiple vulnerability databases and vendor advisories list curl versions up to 7.88.1 as affected, with fixes incorporated into the 8.0.0 series and backported fixes published by various distributions.
• Upstream maintainers merged a targeted fix in late January 2024, and downstream vendors subsequently issued package updates and advisories to distribute the corrected behavior to their customers.

Practical takeaway: upgrade curl to 8.0.0 or later, or install your OS vendor’s security update that includes the backported fix. Ubuntu, SUSE, Amazon Linux, and other major vendors produced advisories and fixed packages in the weeks and months after disclosure.

---

How this can be abused — exploitation scenarios​

The vulnerability is primarily a path‑traversal / access control bypass primitive. In real‑world terms, that means an attacker who can supply or control the path component sent to curl (for example via a web interface that builds SFTP URLs from user input, or a script that accepts filenames from untrusted sources) may be able to:

• Read files in other users’ home directories (for example, .ssh/authorized_keys, configuration files, or secrets that live in user homes).
• Bypass server-side filtering intended to restrict operations to a particular subtree (for instance, an SFTP “uploads/” directory).
• Combine access to other data with follow-on attacks (exfiltrate keys, drop payloads, or enumerate accounts) that lead to further compromise or lateral movement.

Security advisories and vulnerability databases also note the theoretical possibility of arbitrary code execution in environments where the client or the calling process is able to act on acquired files in insecure ways (for example, if a script downloads a configuration or a binary into an executable path and the environment automatically trusts it). The immediate and concrete risk, however, is a permissions‑boundary bypass to read or overwrite files that should not be reachable.
Important constraints that limit exploitability in practice:

• The attacker must be able to influence the path argument sent to the vulnerable curl client (remote exploitation of an unattended, privileged curl server is not the usual vector).
• Server-side confinement (chroot, internal SFTP subsystems that enforce per-user roots, SELinux/AppArmor policies, or OS-level home-directory protections) can significantly blunt the impact even if the client mis-parses the path.

---

Confusing severity scores — why different vendors disagree​

CVE‑2023‑27534 shows a common theme: the same technical fact can be scored differently by different organizations depending on the assumed threat model.

• The NVD entry (and many vendors’ security advisories) reference a high severity (CVSS v3.1 8.8), reflecting the potential to read or alter sensitive files across accounts when the client is used in contexts with local privileges.
• Some Linux distribution advisories and cloud vendors (for example Amazon Linux ALAS) present a lower base score (for example, 4.5) because they evaluate the realistic exploitability and typical deployment conditions (for instance, whether the vulnerable component is reachable or invoked in a privileged, unattended manner).
• SUSE’s tracking shows both perspectives: upstream CNAs and NVD may show the higher score while SUSE’s product scoring can be lower due to their product‑specific context.

What this means for defenders: don’t rely solely on a single numeric score. Instead, evaluate the threat relative to how curl is used in your environment:

• Is curl invoked by untrusted inputs or web services?
• Does your environment allow a curl client to run with elevated privileges?
• Do you rely on server‑side path controls that could be bypassed by a misbehaving client?

If the answer to any of these is “yes,” treat this issue as high priority regardless of a vendor’s numeric severity label.

---

Evidence of fixes and vendor responses​

• Upstream: curl maintainers released the corrective changes in the SFTP p fix was merged and documented in the curl advisories. OSV and curl’s own advisories list the issue and the remediation.
• Downstream: Linux distributions and vendors rapidly issued backports and patches. Ubuntu, SUSE, Amazon Linux, and container base images were updated; vendors such as IBM and others published product bulletins referencing the underlying curl issue and recommending upgrades.
• Community monitoring: security trackers and vulnerability databases aggregated the details and pointed to proofs of concept and the root cause for developers and auditors.

Internal reporting and coordination continued into 2024 as vendors backported fixes and closed supply‑chain gaps; upstream maintainers merged a targeted fix in late January 2024 and vendors issued their advisories thereafter.

---

Detection and hunting guidance​

If you’re responsible for an environment that uses curl — directly or indirectly (scripts, automation, orchestration agents, embedded devices) — prioritize the following checks:

• Inventory: locate all invocations of curl on hosts and in containers. Identify schen scripts, CI runners, and web backends that might accept user-supplied path inputs. Prioritize packages that ship curl as a system tool.
• Log search: look for SFTP URL patterns containing a tilde in the first path element (for example, requests that include /~ or /~[0-9]+/). These patterns may indicate accidental or malicious attempts to trigger the tilde expansion. Keep an eye for accesses to other users’ typical protected files (.ssh, .bash_history, .config).
• File activity: on hosts that run curl, monitor for unexpected reads of home-directory files by the process that runs curl (or by the parent scripts that invoke curl). Correlate timestamps with suspicious user input or web requests.
• Application review: if you maintain a web app or API that constructs SFTP URLs from user input, inspect the code paths and add sanitization or canonicalization checks. Hunt for code that simply concatenates base_url + user_input and then shells out to curl.

Note: There was no wide‑scale automated exploitation publicly reported around initial disclosure; still, the primitive is strong enough to warrant investigation where curl is used programmatically, especially in automation scenarios.

---

Practical mitigation checklist (prioritized)​

• Patch first: upgrade curl to version 8.0.0 or later where the SFTP tilde handling bug has been fixed, or apply your vendor’s security update. This is the single most effective fix.
• Sanitize inputs: never allow untrusted users to supply raw SFTP paths without robust validation. Normalize and canonicalize paths server‑side and in the client code that constructs SFTP requests.
• Avoid shelling out: if your application needs SFTP transfers, prefer libraries with controlled bindings over calling the system curl binary via shell commands with concatenated arguments. If you must use curl, pass parameters as properly escaped arguments rather than interpolated strings.
• Harden server confinement: enforce server-side chroot jails, internal SFTP subsystems (e.g., OpenSSH internal-sftp with ChrootDirectory), and strict file-system permissions so that a mis-parsing client cannot abuse server laxness to reach other users.
• Code integrity and application allow‑listing: on Windows endpoints where curl.exe is present as a system tool, use code integrity policies or application control to block execution of vulnerable curl binaries until patching can be completed. Microsoft has recommended caution about replacing the system curl binary manually because of system dependencies and suggested controlled mitigations instead.
• Monitor and alert: deploy alerts for suspicious SFTP access patterns and unexpected file reads by curl or the parent process. Correlate with web application logs that accept user-supplied file parameters.

---

Server‑side hardening recipes​

• Use OpenSSH’s internal-sftp with ChrootDirectory to guarantee per‑user confinement. Even if a client misinterprets a tilde, confinement prevents access to other home directories.
• Enforce strict Unix permissions and limit group memberships so that users’ home directories are not world readable.
• If your service constructs SFTP requests from user data, canonicalize paths and reject any path that contains unexpected components, such as initial slashes followed by a tilde or embedded user identifiers.
• Where possible, use public key authentication rather than password-based flows and limit what automated clients can do with keys (scoped keys, forced-commands).

These server controls convert a client parsing bug into, at worst, a localized client issue instead of an attack facilitating cross-user disclosure.

---

Realistic risk assessment for WindowsForum readers​

• Desktop Windows users who occasionally run curl manually are at low risk unless they are tricked into invoking curl with a crafted SFTP URL by a social‑engineering or spearphishing scenario. The more likely danger is in automated contexts: CI pipelines, orchestration agents, container images, or administrative scripts that call curl with user-provided paths.
• Servers and embedded devices that ship older curl versions and accept user‑controlled paths are higher risk, especially if the invoking process has elevated privileges or if server-side confinement is weak. In those scenarios the attacker can read (or possibly influence) files in other users’ home directories.
• The most urgent remediation path is upgrade and patching; for Windows administrators, coordinate patch scheduling with system update cycles and consider a code‑integrity policy if you cannot immediately install the patched curl package. Microsoft guidance has emphasized not to replace the built‑in curl binary manually because of potential update/store side effects; instead use policy controls or official Windows updates when available.

---

Why the exploit description sometimes mentions Denial‑of‑Service​

Some advisories (and vendor product pages) discuss availability impacts or denial‑of‑service-style consequences in the context of related curl issues or when attacker activity leads to servers being overwhelmed. The general principle is: misparsed paths can be used to perform repeated operations that cause high load or resource exhaustion, and in some downstream products this results in availability loss until patching occurs. If you saw an MSRC entry or other vendor text describing “total loss of availability,” treat that as a product‑specific impact statement — check your vendor’s product advisory for precise CVSS/Affected Product details. Note: our automated fetch of some MSRC pages was blocked by client-side rendering, so verify the exact Microsoft wording directly in your product portal if your environment uses Microsoft‑packaged curl. (msrc.microsoft.com)

---

Post‑patch review: what to look for after you fix​

• Confirm package versions across fleet: patching a single host is insufficient in large environments. Use your configuration management tools to verify curl >= 8.0.0 (or vendor‑patched package) on every host that ships or invokes curl.
• Re‑audit scripts: if you patched curl but are still shipping automation that constructs SFTP URLs from untrusted input, apply input validation and re‑test. Patching is necessary, but avoiding the underlying design problem is also essential.
• Review logs from the pre‑patch window to look for suspicious SFTP requests containing tilde tokens; correlate with file access audits to identify potential data disclosure.

---

Strengths and residual risks: a critical view​

Strengths

• The defect is relatively easy to describe and reproduce, which helped maintainers produce a focused, auditable fix that could be backported and packaged by vendors. Upstream remediation was clear and timely once disclosed.
• Modern distribution and container ecosystems reacted: multiple OS vendors published fixes and advisories, and container image maintainers updated base images. That reduces long-term systemic exposure for patched deployments.

Residual risks and limitations

• Discrepancies in CVSS scoring across vendors can create complacency where an organization treats the issue as “low” because one vendor says so while their specific deployment is actually high‑impact. Evaluate impact locally.
• Supply‑chain and embedded device exposure: devices or appliance firmware that includes an older curl binary may not be regularly updated, leaving persistent pockets of vulnerability. Vendor product bulletins must be tracked and devices inventoried.
• Human factors: the most likely path to serious compromise is not a direct remote exploit against curl itself but misuse — e.g., scripts that automatically act on data downloaded by curl or services that accept user-supplied path parameters without validation. Remediation therefore requires both patching and secure coding practices.

---

Final recommendations (action plan)​

• Immediately identify and remediate all hosts and images with vulnerable curl packages. Prioritize automation servers, CI runners, admin workstations, containers, and appliances.
• Apply vendor security advisories and ensure package versions reflect the upstream fix (curl 8.0.0 or vendor backport).
• Audit and sanitize any code that builds SFTP URLs from external input; add canonicalization and rejection rules for paths containing ambiguous tilde usage.
• Harden SFTP servers with chroot, strict permissioning, and least‑privilege key usage so that a misbehaving client cannot by itself disclose unrelated home directories.
• Monitor logs for the telltale path patterns and for unexpected reads of home-directory assets. Correlate suspicious activity and investigate historical access around disclosure and patch windows.

---

CVE‑2023‑27534 is a textbook vulnerability in the sense that it pairs a small parsing mistake with very real consequences: when client code over‑interprets a syntax token, it can subvert access controls that were assumed by application and server designers. The technical fix is straightforward and already available; the operational challenge for teams is the standard — but harder — business of inventory, patching, and sanitizing the places where user input crosses into privileged automation. If you run curl in any automated, multi‑tenant, or user‑facing context, treat the issue as material: patch, audit your code paths, and harden server confinement to eliminate the opportunity for surprise tilde expansion to become a security incident.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center