HUSTack

Program overview

hustack.soict.ai is the online programming judge operated by the School of ICT (SOICT) at Hanoi University of Science and Technology. Students use it to practise algorithms, data structures and programming in C, C++, Java and Python. The system accepts source code submissions, compiles and runs them inside a sandbox, and compares output against test cases.

The two things that matter most here are:

1. Sandbox isolation. Submitted code runs on the judge server. Can it break out of the sandbox, read files on the host, access the network, or interfere with other submissions running concurrently?
2. Submission confidentiality. Every student's source code is their own work. Can one user view, download or enumerate another user's submissions, grades or account data?

This is a vulnerability disclosure programme (VDP). There is no cash bounty; valid findings receive recognition.

What to look for

These are the vulnerability classes this programme is most interested in:

• Sandbox escape: compiling or running submitted code in a way that reads or writes files outside the sandbox, executes arbitrary commands on the host, accesses the network, or reaches the judge's internal services.
• Submission access / IDOR: viewing, downloading or enumerating another user's source code, test results, grades or profile through direct object reference, API parameter manipulation or access control flaws.
• Authentication and authorisation: session hijacking, privilege escalation to instructor or admin roles, authentication bypass.
• Injection: SQL injection, command injection, template injection, stored or reflected XSS in problem statements, submission comments or user profiles.
• Information disclosure: exposed configuration, .git directories, debug endpoints, stack traces revealing internal architecture, or judge test case data that students should not see.

Testing rules and expectations

• Use your own account. Register a normal account and test with that. No special headers, user agents or identifiers are needed. Do not attempt to access instructor or admin panels beyond proving reachability.
• Do not access other students' data. If you discover an IDOR or access control flaw, prove it with the minimum evidence (e.g. a response showing a submission ID that is not yours) and stop. Do not bulk-download submissions.
• Sandbox testing. You may submit code designed to test the sandbox boundary – reading /etc/passwd, listing directories, attempting network connections. Do not attempt to persist (no reverse shells, no cron jobs, no written files intended to survive your submission).
• Do not disrupt. The platform is used by students during coursework. Avoid anything that would degrade the service, corrupt the problem set, or affect other users' submissions or grades.
• Do not modify data. Do not alter problems, test cases, other users' accounts, or grading results, even if you can.

If you encounter personal data (student names, emails, grades), stop reading it immediately, do not save it unredacted, and report the access path.

Proving sandbox escape

If you achieve file-system access or code execution outside the sandbox:

• Capture the minimum evidence: id, hostname, a directory listing, the contents of a world-readable file like /etc/hostname.
• Do not persist. No reverse shells, no added users, no written files.
• Do not pivot. If you can reach the internal network, stop and report it. Reachability is the finding.
• Include the exact source code you submitted, the language you selected, and the submission ID in your report.

Proving submission access

If you can view another user's submission:

• Show the HTTP request and response, with the submission ID or user ID that is not yours.
• Redact any actual source code belonging to another student.
• Do not enumerate all submissions. One proof is enough.

Proving write access

If you find a way to write, do not prove it by causing damage. Prove it with the smallest change that can be attributed to you and undone in the same minute.

• One or two punctuation characters. Delete a full stop, add a comma. Nothing longer, nothing visible, no payload, no changed number or amount.
• Only on a record you created yourself. Never another user's record, never site content, never anything the public can see.
• Revert within sixty seconds, in the same run, without being asked.
• Capture four states: before, after the change, after the revert, and an independent re-read confirming the revert held.
• If it cannot be reverted, do not change it. Report the write primitive and stop. A row count and a column list already prove database access.

No special request headers or identifiers are required. Just use a normal account and test normally.

Safe harbour

Good-faith testing that stays inside these rules is authorised access. You are expected to stay within scope, minimise impact, avoid privacy violations, and give the operators reasonable time to fix what you find before telling anyone else.

Authorisation ends the moment you step outside it. Bulk-downloading student submissions, persisting access on the judge server, disrupting the platform, or using a finding for any purpose other than this report takes you outside the engagement.

Disclosure policy

Coordinated disclosure. Do not publish anything before the operators have confirmed the fix and agreed to publication. Student data, internal hostnames, credentials and staff names must be redacted from anything that is eventually published.

How to report

Send reports to admin@bugbounty-program.com. A usable report contains:

• one sentence stating the impact,
• the exact URL, method, parameter and account role needed,
• for sandbox findings: the submitted source code, language and submission ID,
• numbered steps a non-expert can follow to reproduce,
• the raw request and response (not a screenshot),
• what you did not do, so the operators can scope their investigation,
• a suggested fix, if you have one.