ABSOLUTE NANO picoCTF 2026 Solution

Published: March 20, 2026

Description

You have complete power with nano. Think you can get the flag?

Launch the challenge instance and SSH in.

Check what sudo permissions are available.

bash
sudo -l

Solution

Want to try it yourself first?

The guided walkthrough reveals hints one step at a time.

Walk me through it
  1. Step 1
    Check sudo permissions
    Observation
    I noticed the challenge description said 'You have complete power with nano,' which suggested an unconventional sudo grant tied to a text editor and pointed toward enumerating sudo permissions as the first step.
    Run sudo -l. It lists what you can run as root, and shows nano with NOPASSWD here. See the linux CLI guide for more sudo enumeration patterns.
    bash
    sudo -l

    See linux CLI for CTF for sudo and shell escape recipes.

    What didn't work first

    Tried: Running 'sudo su' or 'sudo bash' directly to get a root shell

    Both commands fail with 'Sorry, user picoplayer is not allowed to execute /bin/su or /bin/bash as root'. sudo -l reveals which exact binaries are permitted - without checking first, you waste time trying commands the sudoers policy never allowed.

    Tried: Running 'cat /etc/sudoers' to read the policy instead of using sudo -l

    The sudoers file is owned by root and not world-readable, so cat returns 'Permission denied'. sudo -l is the correct way to enumerate grants because sudo itself evaluates the policy and prints only the rules that apply to your user.

    Learn more

    sudo -l lists the commands a user is permitted (and forbidden) to run as root or another user. The output comes from /etc/sudoers or drop-in files in /etc/sudoers.d/. In CTF challenges, misconfigured sudo rules often grant access to editors, interpreters, or utilities that can be leveraged for privilege escalation.

    In this challenge the output looks like:

    User picoplayer may run the following commands on challenge:
        (root) NOPASSWD: /usr/bin/nano /etc/sudoers

    NOPASSWD: means sudo will not prompt for the user's password. The path can be a single binary, an absolute path with fixed arguments, or a wildcard. Wildcards are dangerous because shell globbing happens before sudo evaluates the rule, so /var/log/*.log can be matched by adding ../ traversal in many cases. Path restrictions only apply to the literal command - once nano runs, it inherits root privileges for everything it can spawn.

    Even after sudo nano drops you into a root editor, sudo's default env_reset behaviour scrubs most environment variables (PATH, LD_PRELOAD, IFS) so you cannot abuse those vectors. The shell escape works because nano spawns its child with a fresh shell, not because of any inherited env. The classic reference for techniques is GTFOBins (gtfobins.github.io). In real engagements, sudo -l is one of the first enumeration steps after gaining a foothold.

  2. Step 2
    Open /etc/sudoers as root via the restricted nano grant
    Observation
    I noticed that sudo -l revealed the exact rule '(root) NOPASSWD: /usr/bin/nano /etc/sudoers', which meant nano was granted root access specifically on the sudoers policy file and opening that file was the intended escalation path.
    The sudo rule allows nano only for /etc/sudoers. Open that file with the granted command.
    bash
    sudo nano /etc/sudoers
    What didn't work first

    Tried: Running 'sudo nano /etc/passwd' or 'sudo nano /root/.bashrc' to open a different file

    sudo rejects the command immediately with 'Sorry, user picoplayer is not allowed to execute /usr/bin/nano /etc/passwd as root'. The rule hard-codes the argument to /etc/sudoers, so nano can only be invoked on that exact path.

    Tried: Using the GTFOBins nano shell escape (Ctrl+R then Ctrl+X) to spawn a root shell inside the editor

    The Ctrl+R Ctrl+X trick opens nano's 'execute command' prompt and runs a shell as root. It works when you have unrestricted 'sudo nano', but here the rule is locked to /etc/sudoers so the escalation path is editing that file directly rather than escaping to a shell.

    Learn more

    Because the rule is (root) NOPASSWD: /usr/bin/nano /etc/sudoers, you cannot run sudo nano on an arbitrary file. The only allowed invocation is sudo nano /etc/sudoers, which opens the sudoers policy file in an editor running as root.

  3. Step 3
    Edit /etc/sudoers to grant yourself full privilege
    Observation
    I noticed that nano was running as root with write access to /etc/sudoers, which meant I could directly append a permissive rule for picoplayer to escalate from a narrow nano grant to unrestricted sudo access.
    Inside nano, scroll to the bottom of the file and add a line that gives your user unrestricted NOPASSWD sudo access. Save with Ctrl+O, confirm the filename, then exit with Ctrl+X.
    bash
    # At the bottom of the file, add:
    bash
    picoplayer ALL=(ALL) NOPASSWD: ALL
    bash
    # Then press Ctrl+O to save and Ctrl+X to exit
    What didn't work first

    Tried: Adding '%sudo ALL=(ALL) ALL' or modifying an existing group line instead of adding a user-specific line

    Group lines require picoplayer to actually be in that group; 'groups' will confirm it is not in sudo or wheel by default. A direct user line 'picoplayer ALL=(ALL) NOPASSWD: ALL' bypasses group membership entirely and takes effect immediately on save.

    Tried: Pressing Ctrl+X without first pressing Ctrl+O, expecting nano to prompt to save

    nano does prompt to save on exit, but if you confirm the wrong filename or accidentally hit N, the edits are discarded and you must re-open the file. The explicit Ctrl+O then Enter sequence locks in the save before exiting and avoids accidentally clobbering the file.

    Learn more

    Adding picoplayer ALL=(ALL) NOPASSWD: ALL at the bottom of /etc/sudoers overrides the previous narrow rule. sudo processes rules top-to-bottom and the last matching entry wins (or in some configurations the first), so placing the permissive line at the bottom guarantees it takes effect. After saving, sudo will immediately honour the new policy without requiring any restart.

    The GTFOBins Ctrl+R Ctrl+X shell escape is an alternative approach that works when the sudo rule permits sudo nano without a fixed file argument. Here, because nano is restricted to /etc/sudoers, the sudoers-editing path is the correct technique.

  4. Step 4
    Read the flag using the new sudo grant
    Observation
    I noticed that after saving the updated sudoers file, the new 'picoplayer ALL=(ALL) NOPASSWD: ALL' rule was immediately active, which meant I could now run any command as root and read the flag directly with sudo cat.
    With the new unrestricted sudo rule in place, read the flag directly.
    bash
    sudo cat /flag

    Expected output

    picoCTF{4bs0lut3_n4n0_...}
    Learn more

    You now have full sudo access, so sudo cat /flag reads the flag as root. If /flag is not present, check /root/flag.txt or run sudo find / -name flag.txt 2>/dev/null.

Flag

Reveal flag

picoCTF{4bs0lut3_n4n0_...}

The sudo rule restricts nano to /etc/sudoers - edit that file to add a permissive rule for yourself, then use the new grant to read the flag.

Key takeaway

Sudo privilege escalation exploits overly permissive rules that grant low-privilege users root access to specific binaries. Editors, interpreters, and shell utilities are especially dangerous grants because they can spawn subprocesses or write to arbitrary files, turning a narrow capability into full root. GTFOBins catalogs hundreds of these techniques, and 'sudo -l' is one of the first post-foothold enumeration steps in real penetration tests for exactly this reason.

Related reading

Want more picoCTF 2026 writeups?

Useful tools for General Skills

What to try next