Privilege Escalation: Hijack the PATH

You are 'student' on this box with exactly one sudo grant: you may run an administrator's maintenance script as root with no password. The script is root-owned and you cannot edit it — so a GTFOBins shell trick on the script itself is off the table. The weakness is one level down.

1. Read your grant, then read the script. sudo -l shows the one command you may run as root. The script is world-readable — open it and notice it calls a helper program by its bare name, not an absolute path.

2. Work out why that matters. When a privileged program runs a command by bare name, the shell resolves it through $PATH. If sudo passes your PATH through to the script (this box's admin disabled the usual protection so their tool would be found), then whichever directory comes first in your PATH decides which 'helper' actually runs — and you control your PATH.

3. Escalate. Put a program of your own, with the helper's name, in a directory you control, point PATH at it, and run the sudo command. The script — running as root — executes your program instead of the real helper.

4. Prove it. Have your program write a marker to /root/pwned.txt, then read the root-only flag at /root/flag.txt into /home/student/loot.txt.

Grading reads the machine state: a /root/pwned.txt owned by root, and your loot matching the real flag. This is a classic real-world finding — a privileged script that trusts an attacker-controlled PATH — and the fix is to call tools by absolute path and keep secure_path on.