CVE-2026-45390

In OCaml-tar before 3.4.0, a crafted archive with ../ path segments in its name allows escaping the current working directory. This is not desired behavior, and tar(1) rejects such extractions, but ocaml-tar decompresses it anyway. The impact is that it allows arbitrary file writes outside of the desired extraction directory (to an attacker that can reach a tar decompression endpoint).

In OCaml-tar before 3.4.0, a crafted archive with ../ path segments in its name allows escaping the current working directory. This is not desired behavior, and tar(1) rejects such extractions, but ocaml-tar decompresses it anyway. The impact is that it allows arbitrary file writes outside of the desired extraction directory (to an attacker that can reach a tar decompression endpoint).

In OCaml-tar before 3.4.0, a crafted archive with ../ path segments in its name allows escaping the current working directory. This is not desired behavior, and tar(1) rejects such extractions, but ocaml-tar decompresses it anyway. The impact is that it allows arbitrary file writes outside of the desired extraction directory (to an attacker that can reach a tar decompression endpoint).

In OCaml-tar before 3.4.0, a crafted archive with ../ path segments in its name allows escaping the current working directory. This is not desired behavior, and tar(1) rejects such extractions, but ocaml-tar decompresses it anyway. The impact is that it allows arbitrary file writes outside of the desired extraction directory (to an attacker that can reach a tar decompression endpoint).

A malicious archive with ../ path segments in its name allows escaping the current working directory. This is not desired behavior, and tar(1) rejects such extractions, but ocaml-tar decompresses it anyway. The impact is that it allows arbitrary file write outside of the desired extraction directory to an attacker that can reach a tar decompression endpoint. In terms of severity, similar vulnerabilities in different ecosystems (python, node, go) have been assigned CVSS scores of 6.8 MEDIUM, 7.1 HIGH, and 8.2 HIGH.

Details

Function Tar_unix.extract uses Filename.concat.

let extract ?(filter = fun _ -> true) ~src dst =
  let f ?global:_ hdr () =
    if filter hdr then
      match hdr.Tar.Header.link_indicator with
      | Tar.Header.Link.Normal ->
        begin match Result.map_error unix_err_to_msg
            (safe Unix.(openfile (Filename.concat dst hdr.Tar.Header.file_name)
                          [ O_WRONLY ; O_CREAT ]) hdr.Tar.Header.file_mode) with
        | Error _ as err -> Tar.return err
        | Ok dst ->
          try copy ~dst_fd:dst (Int64.to_int hdr.Tar.Header.file_size)
          with exn -> safe_close dst; Tar.return (Error (`Exn exn))
        end
        (* TODO set owner / mode / mtime etc. *)
      | _ ->
        (* TODO handle directories, links, etc. *)
        let open Tar.Syntax in
        let* () = Tar.seek (Int64.to_int hdr.Tar.Header.file_size) in
        Tar.return (Ok ())
    else
      let open Tar.Syntax in
      let* () = Tar.seek (Int64.to_int hdr.Tar.Header.file_size) in
      Tar.return (Ok ())
  in
  fold f src ()

Filename.concat does not perform any sanitation:

# Filename.concat "/tmp" "../../../etc/passwd";;
- : string = "/tmp/../../../etc/passwd"

Hence, calling Unix.openfile on such a path will result in opening /etc/passwd.

I only confirmed it in the following setting (see PoC below), and a proper fix would require investigating it in more details:

version targeted: 3.3.0, which seems to be the only version of ocaml-tar. But use of Filename.concat seems to have been there since the beginning.

Impact

This is a path traversal vulnerability that allows an attacker to perform an arbitrary file write outside of the intended extraction directory. Vulnerable users are the users relying on ocaml-tar, which includes (according to the readme of ocaml-tar):

• xapi (confirmed not vulnerable by maintainers)
• obuilder

Related CVEs

• CVE-2007-4559: same problem in python's implementation of tar
• CVE-2025-0377: similar problem in hashicorp's go implementation of tar
• CVE-2026-24842: similar problem in node-tar

Fix

The fix is to sanitize paths before calling Unix.openfile. In the presence of symlink support, extra validation is needed.

Timeline

• 2026-05-07: reported via GitHub (on https://github.com/ocaml/security-advisories)
• 2025-05-20: initial fix developed and asked for review, also informed xapi and obuilder teams
• 2025-05-22: fixed tar released, security advisory announced