HTB: Previous

5 min readFeb 25, 2026

Enumeration

> sudo nmap 10.129.240.237 -p- -sCV --open --min-rate=1000 -oN previous-nmap-version

Nmap version scan revealed two open TCP service of SSH on port 22 and HTTP on port 80. In addition, the vhost name previous.htb was spotted.

The vhost name was added to the /etc/hosts file for the proper DNS resolution.

> http://previous.htb

On the target web server, Next.js 15.2.2 was running. Clicking either Get Started or Docs button led me to the login page for the beta user.

🤔 What is Next js?
Next.js is a popular React framework that simplifies the process of building fast, interactive web applications.

🤔 What is React?
React is a JavaScript UI library for building user interface.

Initial Access: Authentication Bypass + Directory Traversal

> x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware

[source] https://strobes.co/blog/understanding-next-js-vulnerability/
At the beginning, I couldn’t access the /docs page without authentication. However, adding thex-middleware-subrequest HTTP header to the request allowed me to bypass the authentication because Next.js 15.2.2 is vulnerable to authorization bypass (CVE-2025–29927). The vulnerability stems from improper trust of the HTTP header.

> http://previous.htb/docs

After the authentication bypass, I was met with the Documentation Overview page containing two links to the Getting Started page and the Examples page.

> http://previous.htb/docs/examples

On the examples page, there was an option to download the example code. Clicking the here link resulted in the page redirection to http://previous.htb/api/download along with the parameter example.

> /api/download?example=../../../etc/passwd

The example parameter of the download page was vulnerable to directory traversal. With the payload ../../../etc/passwd, I could review the /etc/passwd file containing two accounts of node and nextjs under the /home directory.

**Directory Traversal**: /proc/self/environ

> /api/download?example=../../../proc/self/environ

The directory traversal vulnerability with the payload ../../../proc/self/environ revealed the environment variables on the target. From the variables, I inferred that the current user was nextjs, but the current working directory was /app.

**Directory Traversal:** /app/package.json

> /api/download?example=../../../app/package.json

Given that the /app directory contained the package.json file, the directory appeared to be the project root directory.

Get bluesnow’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

🤔 What is the package.json file?

The package.json file is the main configuration file used by Node.js projects. It stores important information about the project and manages its dependencies.

> /api/download?example=../../../app/.next/server/pages/api/auth/[...nextauth].js
       
     /app : the project root directory
     /.next/server : when we run npm run build or next build, Next.js compiles the application's source code into optimized, production-ready files within the .next directory; the .next/server directory holds the compiled server-side code
     /pages/api/auth/[…nextauth].js : the nextauth.js path of Pages Route; the [...nextauth].js file (or [...nextauth].ts for TypeScript) is a catch-all API route that serves as the main entry point for NextAuth.js, the open-source authentication library for Next.js applications

Admittedly, figuring out this payload path to nextauth.js was not an easy task at all. In the nextauth.js file, the cleartext password of the user jeremy was discovered.

🤔 What is the nextauth.js file?

The nextauth.js file is the authentication configuration file for a Next.js application using Auth.js (formerly NextAuth).

🤔 Where is the nextauth.js file located?

In order Next.js (Pages Router)
> /pages/api/auth/[…nextauth].js
In modern Next.js (App Router)
> /app/api/auth/[…nextauth]/route.js

> ssh jeremy@10.129.241.5

The password of jeremy found in nextauth.js granted me the access to the target via SSH.

The user.txt flag was located in the jeremy user’s home directory.

Privilege Escalation: Jeremy → Root

> sudo -l

The user jeremy was able to execute /usr/bin/terraform chidir\=/opt/examples apply command as root using sudo.

Based on the .terraformrc file, which is a Terraform CLI configuration file, the provider binary was currently located in /usr/local/go/bin.

🤔 What is the provider binary of Terraform?

The provider binary is the executable plugin Terraform runs to manage a specific service. Without it, Terraform cannot create or manage resources.

> mkdir myterra
> nano myterra/terraform-provider-examples
> cat myterra/terraform-provider-examples

Executable Permission

> chmod +x myterra/terraform-provider-examples

[source] https://servian.dev/terraform-local-providers-and-registry-mirror-configuration-b963117dfffa
Terraform allows developers to override the provider binary with locally built one to test. In order to exploit this feature to my advantage for privilege escalation, I prepared a new provider binary named terraform-provider-examples, which copies /bin/bash to /tmp/mybash and sets the SUID bit.


  "previous.htb/terraform/examples" = "/home/jeremy/myterra"

In order to override the provider binary, dev_overrides in the provider_installation block of the .terraformrc CLI configuration file was modified to /home/jeremy/myterra containing the new provider binary.

> sudo /usr/bin/terraform -chdir=/opt/examples apply
> /tmp/mybash -p

Once executing the terraform binary with sudo, the new provider binary was executed. As a result, the /tmp/mybash binary with the SUID set returns a shell as root.

The root.txt flag was found in the /root directory.

Thank you for taking the time to read my write-up! ❄️