CVE-2026-24479: Critical Zip-Slip Flaw in HUSTOJ Enables Remote Code Execution via Malicious ZIP Uploads

CVE-2026-24479

CVE ID: CVE-2026-24479
Product / Project: HUSTOJ (HUST Online Judge, a web application for coding competitions and judging)
Severity: Critical
Impact: Remote Code Execution (RCE)
Exploitability: High — remote and simple to trigger
Official patch/upgrade: Upgrade to version 26.01.24 – Link provided below

What the vulnerability is

This vulnerability exists because the software accepts a ZIP file from a user and extracts it without carefully checking the file paths inside that ZIP.

The extraction code does not prevent path traversal, which means:

A ZIP entry can contain file names like ../../shell.php
When extracted, the code writes the file into places it should never write — such as the web server root folder
This allows an attacker to drop a file they control into a location that the server will serve as web content

That’s the classic Zip-Slip pattern: a badly unpacked ZIP that lets an attacker break out of the intended folder.

Once the attacker places a file like shell.php in the web root, they can simply browse to it and start executing commands on the server.

This leads to Remote Code Execution, one of the worst types of vulnerabilities.

Why it matters

Remote Code Execution means attackers can run arbitrary commands on your server.
If they get a shell, they can pivot, steal data, delete data, or install backdoors.
Most security models assume uploaded files remain in safe folders — this breaks that assumption.
It doesn’t require admin credentials — any unauthenticated user who can upload ZIP files to the problem import function can attempt exploitation.

How it is exploited

1. Attacker finds the upload endpoint

The code that imports problem sets has a form that accepts ZIP files. This is where the extractor runs.

2. Attacker prepares a malicious ZIP

Inside the ZIP, instead of normal problem files, it includes entries like:

../../shell.php
../../evil.txt

These directory traversal sequences tell the ZIP extractor: “go up out of the intended folder and write files elsewhere.”

3. Attacker uploads the ZIP

They use the legitimate upload form — the system doesn’t block or sanitize path traversal in entry names.

4. Server extracts and places files

Because there’s no proper filtering, the extraction process writes the file into a location like /var/www/html/shell.php.

5. Attacker accesses the new file

They browse to:

https://target.domain/shell.php

Once the file is in a web-accessible directory, it runs as PHP code.

6. Attacker uses it for Remote Code Execution

Inside shell.php, the attacker could have code that executes commands the web server user can run — leading to total compromise.

This exploitation chain is straight-forward and doesn’t require complex encoding or special magic. It is simple directory traversal leading to file overwrite.

Proof of Concept (educational context)

A real working exploit would:

Create a ZIP such as:

zip -r exploit.zip ../shell.php

Where shell.php contains:

<?php system($_GET['cmd']); ?>

Upload that to the problem import.
Visit: http://yourserver/shell.php?cmd=whoami

This would print the server user name — showing remote code execution.

This type of PoC is simple and widely understood by attackers, which is why fixing it quickly is essential.

What real attackers look for

An attacker tries:

ZIP files with directory traversal in entry names
ZIPs that unpack into writable, web-accessible directories
Upload forms that run extraction without checking file paths

Just seeing a server that accepts uploads to a PHP endpoint that extracts is enough incentive for probing.

This is not a rare or obscure bug — it’s a well-known unsafe pattern.

Signs of exploitation

1. Unexpected new files in web root

Files like shell.php, cmd.php, upload.php, etc, that do not belong to your deployed application.
Check recent files:

find /var/www/html -type f -mtime -1 -print

If any unknown PHP files show up, assume compromise.

2. Unusual requests in web server logs

Look for:

POST to problem import endpoints
Filenames containing ../ or %2e%2e%2f
Requests to new PHP files that were not part of the app

Example log search:

grep -E "%2e%2e|../" /var/log/nginx/access.log

3. Upload activity from unexpected IPs

If a non-trusted IP uploads a ZIP containing thousands of bytes with goofy file names, that’s suspicious.

4. Unusual process execution

If the web server process suddenly spawns shells, connects to external hosts, or creates new processes, that’s evidence of compromise.

Concrete Splunk Detection Rules

Here are ready-to-use Splunk rules you can drop into your threat detection content:

Rule 1 — Path traversal in uploads

index=web_logs
| search method=POST uri="/problem_import_" 
| regex "filename.*(%2e%2e|../)"
| stats count BY src_ip, user_agent, uri
| where count > 2

Detects file uploads with directory traversal patterns.

Rule 2 — New PHP files accessed

index=web_logs
| search ".php" 
| search NOT [ | inputlookup known_php_files.csv | fields filename ]
| stats dc(src_ip) AS unique_ips BY uri
| where unique_ips > 2

Tracks access to unknown PHP files.

Rule 3 — Correlate uploads with new file access

index=web_logs OR index=file_change_logs
| eval eventType = if(index=="web_logs" AND uri like "%problem_import%", "upload", 
                      if(index=="file_change_logs" AND filepath like "/var/www/html/%", "newfile", "other"))
| stats earliest(_time) AS firstTime BY src_ip, eventType
| where eventType="upload" AND eventType="newfile" AND firstTime_upload < firstTime_newfile

This highlights clients where upload preceded new file checklist.

Recommended detection practices

Beyond these rules:

Monitor file creation timestamps in web root
Block uploads that contain path traversal strings
Whitelist allowed filenames or extensions
Log ZIP entry names before extraction
Use file integrity monitoring systems

Mitigation steps

1. Patch / Upgrade (must do)

Upgrade to version 26.01.24 — this is the official, complete fix.

https://github.com/zhblue/hustoj/releases/tag/26.01.24

2. Restrict access

Until patching is done:

Restrict import endpoint to admin IPs only
Put the upload form behind VPN or internal access
Disable public uploads entirely if possible

3. Harden your environment

Make the web server user unable to write outside a specific directory
Ensure extraction code rejects ../ patterns
Validate ZIP contents before extracting
Log everything that is extracted

4. Monitor and alert

Use the detection rules above, plus:

File integrity monitoring
IDS/IPS rules blocking encoded traversal sequences
Endpoint detection for unusual web server process behavior

Incident Response

Isolate the server immediately
- Remove from network to prevent further exploitation.
Preserve logs and disk image
- Do not delete files yet — export them for analysis.
Search for webshells
- Any unexpected PHP files in your web root are likely backdoors.
Scan for outbound connections
- Many webshells try to phone home or connect out to command servers.
Rebuild from known good backups after patching
- If compromised, it’s safest to rebuild and not trust the compromised system.

Final Takeaways

This is a remote code execution risk caused by unsafe ZIP extraction.
Attackers can upload crafted ZIPs and get a webshell placed on your server.
The only correct fix is to upgrade to 26.01.24.
Detection is possible — watch for traversal patterns, file creations, new PHP access.
Concrete Splunk rules and best practices above help defenders identify exploitation.

Official patch:
https://github.com/zhblue/hustoj/releases/tag/26.01.24