Submissions on the HTB Labs platform will be reviewed in approximately three to four months.

For example, if you submit your challenge on January 1, you can expect to receive a review decision between April 1 and May 1.

You must include a write-up that adheres strictly to the official write-up template.

We will reject your submission or return it to you with a request for updates if it does not include a compliant write-up.

You must not upload the challenge to a public GitHub repository.

Uploading your challenge to a public GitHub repository will result in the immediate rejection of your submission.

You must include only one container if your challenge utilizes a dockerized component.

The memory usage of a Docker container must not exceed 1 GB of RAM.

You must contact HackTheBox staff at [email protected] to request an exception if your challenge requires more than 1 GB of RAM.

You must format all flags accurately as HTB{som3_t3xt}.

You must contact HackTheBox staff at [email protected] to request an exception if your exploitation process requires a different flag format.

You must include a fully automated solver with your submission.

You must contact HackTheBox staff at [email protected] to request an exception if an automated solver cannot be provided.

You must include a full write-up showing the intended path to own the challenge using the provided template.

You must provide the write-up in an editable format, such as Markdown or a Word document.

You must provide a description of all important processes running on the challenge. For example, clearly state if there is an HTTP server using Flask that is started by a service named flask.service.

You must describe all automation and include copies of any scripts running on the challenge, such as crons or schedtasks.

You must include all Dockerfiles and configuration files for containers if you are using Docker.

You must provide the source code for any binary file alongside the exact compilation command used to produce it.

Failing to include source code and compilation commands will result in the immediate rejection of the challenge.

You must provide details about how future patches might impact the exploit path. For example, clearly state if a package used for the server deployment must be version-pinned because the exploit relies on that specific version's vulnerability.

You must keep the challenge scenario realistic wherever possible.

You must ensure the exploited code exists for a logical, legitimate reason.

You must not include unnecessary artifacts, such as a todo.txt file on a web server, unless it serves a specific purpose.

You must avoid including rabbit holes unless there is a strong pedagogical reason for doing so.

You must pick a strong but easy-to-type passphrase for any passwords that are not intended to be cracked.

You must not include inappropriate, trolling, offensive, political, or insulting content.

You must not require brute-forcing outside of the stated requirements without prior approval from HackTheBox staff at [email protected].

You must not include unnecessary or unreasonable guessing in the challenge mechanics.

You must present a coherent path containing worthwhile elements that guides contestants through the design patterns to the solution.

You must not use commercial or paid software, including trial versions.

You must not include copyrighted material in any form.

You must structure your code with a well-thought-out layout and architecture to make state management obvious.

You must use a consistent naming scheme and avoid repeating code.

You must avoid writing excessively long lines of code by breaking large tasks down into smaller chunks.

You must keep the resulting Docker image size as small as possible if your challenge uses Docker.

You must keep your dockerized project simple to run by providing a straightforward script, such as ./build-docker.sh.

Very Easy: This represents a beginner-friendly, entry-level topic for the specified category.

Easy to Medium: This represents a topic that requires basic or intermediate knowledge of the security landscape in the specified category.

Hard to Insane: This represents a topic that requires advanced or specialized knowledge of the security landscape in the specified category.

You must follow the standard file structure for new challenges. You can make minor adjustments based on your specific files, but the core structure must remain consistent.

You must include a README.md file containing the challenge write-up written in Markdown language.

You must include a "challenge" folder containing all the files related to the challenge.

You must exclude all secret data, such as flags or private keys, from the "challenge" folder. This is the exact folder users will see when they download the challenge files.

You must include an "htb" folder containing the files required for solving the challenge.

The solver inside the "htb" folder must work without accessing the private data in the "challenge" folder. For example, a Python script named solve.py must solve the challenge without reading a secret.py file.

You must include a "release" folder containing the password-protected zip file that users will download.

You must create the release zip file by placing all required files into a folder named after your challenge, and then running the command: zip -9 -P hackthebox <category_challenge_name>.zip <category_challenge_name>

You must replace any whitespace in the zip file's name with an underscore.

You must protect the zip file with the exact password hackthebox.

You must include the unzipped files inside the release folder alongside the final .zip file.

If your challenge requires connecting to a remote instance, you can use the following Dockerfile templates as a starting point.

If you cannot build the Docker image, submit your challenge following the file structure conventions, and the HackTheBox team will investigate the issue during the review.