Avoid Security Risks When Running Python Scripts from the Downloads Folder and Using $PYTHONPATH

Python has become one of the most popular programming languages worldwide because of its simple syntax and ease of use; a script placed in a .py file can be executed immediately.

Modules are also easy to import – for example, creating a file my_lib.py and adding import my_lib in another script loads the module.

However, this convenience can become a security backdoor. Beginners often download Python packages or scripts into ~/Downloads and run them directly, which can introduce serious vulnerabilities.

Why this is dangerous? A secure Python execution requires three conditions:

Every entry on the system PATH must be located in a safe directory.

The directory containing the "main script" must always be on the PATH .

If the python command is used with -c or -m , the calling program’s directory must also be safe.

If Python is correctly installed, the only locations automatically added to the system path outside the virtual environment are the Python installation directory and the directory of the main program.

Running commands from the Downloads folder can expose you to attacks. For instance:

<code>~$ cd Downloads
~/Downloads$ python -m pip install ./totally-legit-package.whl</code>

If a malicious pip.py is placed in the Downloads folder, it can replace the system pip and hijack subsequent commands.

Another attack scenario demonstrates a malicious pip.py taking over:

<code>~$ mkdir attacker_dir
~$ cd attacker_dir
~$ echo 'print("lol ur pwnt")' > pip.py
~$ python -m pip install requests
lol ur pwnt</code>

Setting $PYTHONPATH is also unsafe. If $PYTHONPATH is empty or unset, Python treats an empty string as the current directory, allowing attacker‑controlled modules to be imported.

Example of a vulnerable script:

<code># tool.py
try:
    import optional_extra
except ImportError:
    print("extra not found, that's fine")</code>

Placing a malicious optional_extra.py in a directory that appears earlier in $PYTHONPATH leads to code execution:

<code># optional_extra.py
print("lol ur pwnt")</code>

Running the script from an attacker‑controlled directory:

<code>~/attacker_dir$ python ../install_dir/tool.py
extra not found, that's fine</code>

When $PYTHONPATH is set to include the attacker directory:

<code>export PYTHONPATH="/a/perfectly/safe/place:$PYTHONPATH"
python ../install_dir/tool.py
lol ur pwnt</code>

Even clearing $PYTHONPATH with an empty string does not remove the entry; you must unset it to avoid the empty‑string pitfall.

<code>export PYTHONPATH=""
python ../install_dir/tool.py
lol ur pwnt</code>

Therefore, it is recommended to stop using $PYTHONPATH for environment configuration and rely on virtualenv or similar tools. If you must modify $PYTHONPATH , use a safe pattern that avoids empty entries and always use absolute paths:

<code>export PYTHONPATH="${PYTHONPATH:+${PYTHONPATH}:}new_entry_1"
export PYTHONPATH="${PYTHONPATH:+${PYTHONPATH}:}new_entry_2"

echo "$PYTHONPATH"
new_entry_1:new_entry_2</code>

Additional precautions include avoiding running Jupyter notebooks directly from ~/Downloads and always invoking pip via its full virtual‑env path (e.g., /path/to/venv/bin/pip ) instead of python -m pip .

Key takeaways:

When using tools in ~/Downloads , invoke them via the virtual‑env pip path rather than python -m pip .

Do not use the Downloads folder as the current working directory; move tools to a safer location before execution.

Understanding where Python obtains executable code is crucial—granting others the ability to run arbitrary Python commands effectively gives them full control over your computer.