A writable directory on root's PATH

How a bare command name gets hijacked

When a script runs backup-logs instead of /usr/bin/backup-logs, the shell searches the directories in PATH in order and runs the first match. Look at the maintenance job and the directory it searches first:

cat /etc/cron.d/maint
ls -ld /opt/maint/bin

In the terminal (root's job searches /opt/maint/bin first — and it is world-writable (777))

student@vulntech:~$ cat /etc/cron.d/maint
PATH=/opt/maint/bin:/usr/bin:/bin
* * * * * root /opt/maint/collect.sh >/dev/null 2>&1
student@vulntech:~$ ls -ld /opt/maint/bin
drwxrwxrwx 2 root root 0 Oct 19 10:35 /opt/maint/bin

Any user can drop a file called backup-logs in that writable directory, and the next time root's job runs, it finds and executes theirs as root. Two mistakes combine: a bare command name in the script, and a writable directory early on PATH.

Tip: The deeper fix is to make privileged scripts call programs by full path and set an explicit, trusted PATH. But closing the writable directory removes the exposure immediately.