Debian patches opam sandbox escape via .install path traversal

TL;DR — A path traversal flaw in opam lets a malicious package use .install destination paths (e.g., ../..) to write outside the package area, enabling arbitrary file overwrite during opam install.

What happened

opam is the de facto package manager for the OCaml ecosystem, used on developer endpoints and CI runners to fetch and install build dependencies.

On April 21, 2026, Debian’s security tracker published DLA-4541-1 for opam, fixing CVE-2026-41082. Debian describes the core issue as: in OCaml opam before 2.5.1, a .install field containing a destination filepath can use ../ to reach a parent directory, escaping the intended package area.

The OCaml security advisory frames this as an install sandbox bypass: a crafted package.install file can redirect an installed file into a user-controlled path like ~/.bashrc (example payload below), turning a dependency install into a persistence primitive.

bin: [
  "payload.sh" {"../../../.bashrc"}
]

Even though this typically requires getting a target to install a malicious/compromised package, package-manager sandbox escapes are supply-chain force multipliers: they convert “bad dependency content” into “writes on the host that runs builds,” often with access to long-lived credentials and release keys.

Who is impacted

• Debian LTS (Bullseye) systems installing opam from Debian repositories.
• Upstream opam users on versions < 2.5.1 (per the OCaml advisory referenced by Debian’s tracker).
• Highest-risk environments: CI runners and build hosts that perform opam install against dependency sources that can be influenced (malicious packages, compromised repositories, or unreviewed internal overlays).

What to do now

• Follow Debian’s remediation path for DLA-4541-1 by applying the security update for opam from your Debian security/LTS repositories.
• Inventory where opam runs (developer workstations, CI runners, build containers) and verify the installed package version reflects the fixed build listed by Debian for your release.
• Treat this as a supply-chain boundary bug:
  • Prefer pinned, reviewed dependency sets (lockfiles where applicable; controlled mirrors for opam-repository).
  • For CI, minimize credential exposure to dependency-install steps (least privilege, short-lived tokens, isolated builders).
• If compromise is suspected, scope for unexpected file writes during dependency installation (e.g., dotfiles like ~/.bashrc, repo hooks, or CI workspace scripts) and rotate any credentials accessible to the affected build environment.