Skip to main content

SharpCompress CVE-2026-44788

MEDIUM
Path Traversal (CWE-22)
2026-05-08 https://github.com/adamhathcock/sharpcompress GHSA-6c8g-7p36-r338
5.9
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
5.9 MEDIUM
AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L
Attack Vector
Network
Attack Complexity
High
Privileges Required
None
User Interaction
Required
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
Low

Lifecycle Timeline

3
Source Code Evidence Fetched
May 09, 2026 - 00:16 vuln.today
Analysis Generated
May 09, 2026 - 00:16 vuln.today
CVE Published
May 08, 2026 - 23:50 nvd
MEDIUM 5.9

DescriptionGitHub Advisory

Summary

A path traversal vulnerability in IArchive.WriteToDirectory() allows a malicious archive to create directories outside the intended extraction root. For TAR archives, this can be escalated to arbitrary file writes by chaining with a symlink entry, giving a full write primitive on the target filesystem subject to the permissions of the running process.

Details

The vulnerable code is in the directory-entry branch of WriteToDirectoryInternal (sync, IArchiveExtensions.cs:48-61) and WriteToDirectoryAsyncInternal (async, IAsyncArchiveExtensions.cs:70-84):

csharp
var dirPath = Path.Combine(destinationDirectory, entry.Key);
Directory.CreateDirectory(Path.GetDirectoryName(dirPath + "/"));

No Path.GetFullPath() normalisation and no bounds check are applied before the Directory.CreateDirectory call. Two .NET Path.Combine behaviours make this exploitable:

  • Relative traversal: Path.Combine("/safe/extract", "../../evil") → the OS resolves .. segments on the raw path, placing the directory outside the extraction root.
  • Absolute path override: Path.Combine("/safe/extract", "/tmp/evil") → returns "/tmp/evil" - the base is discarded entirely for rooted paths.

File entries are not directly affected - they route through ExtractionMethods.WriteEntryToDirectory which applies the correct guard (GetFullPath + StartsWith, see ExtractionMethods.cs:54-65). The directory-entry branch is a separate fast-path that was added without that guard.

Affected archive formats: ZIP and TAR (non-solid). Solid archives and 7-Zip use the reader path which calls the secure method.

Escalation to arbitrary file writes (TAR only)

Path.GetFullPath on .NET does not resolve symlinks - it only normalises . and .. segments. This means the file-entry guard in ExtractionMethods.WriteEntryToDirectory can be bypassed via symlink chaining in TAR archives when the caller supplies a SymbolicLinkHandler:

csharp
archive.WriteToDirectory("/safe/extract", new ExtractionOptions
{
    ExtractFullPath = true,
    SymbolicLinkHandler = (linkPath, linkTarget) =>
        File.CreateSymbolicLink(linkPath, linkTarget)  // naive - no validation of linkTarget
});

Attack sequence in a single TAR archive:

  1. Symlink entry - link../evil_outside/

The SymbolicLinkHandler creates /safe/extract/link pointing outside the extraction root.

  1. File entry - link/secret.txt

ExtractionMethods.WriteEntryToDirectory computes:

  • destdir = Path.GetFullPath("/safe/extract/link")"/safe/extract/link" - textually inside root, check passes ✓
  • File.Open("/safe/extract/link/secret.txt") - OS follows symlink, file is written to /evil_outside/secret.txt

The library does not validate linkTarget before passing it to the caller's handler, and the XML docs do not warn that it may be a traversal path. The idiomatic handler implementation above is therefore silently exploitable.

ZIP does not support symlinks in SharpCompress (ZipEntry.LinkTarget always returns null), so this escalation is TAR-only.

AttackZIPTAR
Directory traversal (escape extraction root)YesYes
Escalate to arbitrary file writes via symlink chainNoYes (if caller provides SymbolicLinkHandler)

Recommended fix - apply the same pattern from ExtractionMethods.WriteEntryToDirectory to both affected files:

csharp
var fullDestDir = Path.GetFullPath(destinationDirectory);
if (!fullDestDir.EndsWith(Path.DirectorySeparatorChar))
    fullDestDir += Path.DirectorySeparatorChar;

var dirPath = Path.GetFullPath(Path.Combine(fullDestDir, entry.Key));
if (!dirPath.StartsWith(fullDestDir, PathComparison))
    throw new ExtractionException(
        "Entry is trying to create a directory outside of the destination directory.");

Directory.CreateDirectory(dirPath);

Additionally, the library should validate LinkTarget before invoking the caller's SymbolicLinkHandler, or document clearly that callers must validate it themselves.

PoC

A self-contained .NET console app is available at: https://github.com/svenclaesson/poc-sharpcompress-traversal

git clone https://github.com/svenclaesson/poc-sharpcompress-traversal
cd poc-sharpcompress-traversal
dotnet run

The PoC crafts a ZIP with three directory entries (../../escaped_relative/, /tmp/escaped_absolute/, safe_subdir/) using System.IO.Compression (stdlib), then extracts with SharpCompress. Output shows [ESCAPED] for the two malicious entries and [ok] for the legitimate one, on both sync and async APIs.

Tested against SharpCompress 0.47.4 (latest NuGet).

Impact

This is a path traversal / zip slip vulnerability (CWE-22). Any application that calls archive.WriteToDirectory() on an untrusted archive is affected - which covers the primary documented extraction API.

For ZIP archives the impact is limited to arbitrary directory creation, which can be used to stage privilege escalation (e.g. cron drop-ins, XDG config paths, service spool directories) or shadow expected paths to alter application behaviour.

For TAR archives, callers that implement a SymbolicLinkHandler - which is the only way to faithfully restore a TAR - are exposed to a full arbitrary file write primitive via the symlink chaining described above.

AnalysisAI

Path traversal in SharpCompress WriteToDirectory() allows malicious ZIP and TAR archives to create directories outside the intended extraction root via relative (../../) and absolute path (/tmp/) overrides in the directory-entry fast-path. TAR archives can be further escalated to arbitrary file writes when callers implement SymbolicLinkHandler without validating symlink targets, enabling an attacker to write files anywhere on the filesystem subject to process permissions. CVSS 5.9 reflects moderate severity; real-world impact depends on whether the application extracts untrusted archives and implements symlink handling.

Technical ContextAI

SharpCompress is a .NET compression library supporting ZIP, TAR, 7-Zip, and other formats. The vulnerability exists in the directory-entry extraction path (IArchiveExtensions.cs:48-61 and IAsyncArchiveExtensions.cs:70-84) which uses raw Path.Combine() without normalization or bounds checking. The library's file-entry path correctly applies Path.GetFullPath() and StartsWith() validation, but the directory fast-path was added without this guard. The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). Two .NET Path.Combine behaviors enable exploitation: (1) relative path traversal where .. segments are resolved by the OS after combining, and (2) absolute path override where a rooted second argument discards the base path entirely. For TAR archives with SymbolicLinkHandler, symlink targets are not validated before being passed to the caller, allowing symlink chaining to bypass the file-entry guard since Path.GetFullPath() does not resolve symlinks-only normalizes . and .. segments. ZIP does not support symlinks in SharpCompress, limiting that format to directory creation; TAR enables full file writes.

RemediationAI

No vendor-released patch identified at time of analysis-the affected repository shows no fixed version tagged on NuGet. Immediate mitigation: upgrade to the latest SharpCompress version when available and verify the fix is included in release notes, or contact the vendor for ETA. If upgrade is not immediately possible, implement path validation before extraction: apply Path.GetFullPath() normalization and StartsWith() bounds checking on all extracted paths as documented in the CVE (normalize destination root, compute full path of each entry, verify entry path begins with root before creation). Alternatively, extract archives into a temporary sandbox directory with strict permissions, then validate each entry's path before copying to the final location. For applications implementing SymbolicLinkHandler for TAR extraction, validate the linkTarget parameter before creating symlinks-reject any target containing .. or / prefixes that would escape the intended root. Document this requirement in extraction API contracts so callers understand the library does not validate symlink targets. Side effect of path validation: legitimate archives with directory entries using absolute paths or relative traversal (edge case, but may occur in legacy archives) will fail extraction with an ExtractionException; test archives in use to confirm compatibility before deployment.

Share

CVE-2026-44788 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy