TryHackMe Valenfind—Writeup
Back at it. Belated Valentine’s Day. Today: Valenfind—TryHackMe’s special web CTF. I’ll break down exactly how I got the flag, step by step. No fluff, just the hacks.

PS: I forgot to screenshot the main page of the site, so we'll be proceeding with the profile setup after signup.

After setting up our profile, we'll be redirecting to the dashboard.

A simulated dating app huh? I hope Waguri is here, xd.

I began probing the page. While interacting with profiles and likes, I inspected the requests via Developer Tools and noticed something off.

Notice the endpoint? /api/fetch_layout?layout=. My first thought: it’s probably dynamically loading a file based on the parameter. The structure suggests server-side template rendering, where different layouts or components are returned depending on the input. The predictable URL pattern and the way the response behaves make it clear that this endpoint is key to how the page is being assembled—definitely worth probing further to see what’s being called and how it handles input.
In bug bounty hunting, /api endpoints are prime targets because they usually expose the core business logic of an application. While the frontend is often locked down with client-side checks and limited interaction paths, the API sits behind it all, handling raw requests and trusting structured input. This makes APIs a common place for developers to assume “safe usage,” which leads to weak validation, over-permissive parameters, and hidden functionality that never appears in the UI. If a feature exists, it almost always exists first in the API.
On top of that, APIs are built for automation and flexibility, not for hostile users. They often support parameters for internal use—debug flags, file loaders, filters, or object identifiers—that attackers can manipulate directly. Poor access control, IDORs, SSRF, template injection, and file inclusion bugs frequently live in /api routes because they’re designed to be called programmatically, not carefully defended. In bug bounty, finding a vulnerable /api endpoint usually means you’ve found the fastest path to real impact.
Now back to the challenge, when we visit the URL, this is the result:

Now let's change the theme_modern.html > /etc/passwd :

And my instinct is correct:> Instant LFI!

I noticed that the server is Python-based and probably Flask, the way it renders responses, the structure of the JSON, and the predictable routing all point to a lightweight Python web framework. Classic Flask behavior: simple endpoints returning JSON or HTML snippets, no heavy abstraction, just straight-up web logic waiting to be poked.
Now let's play with the LFI we've found!
In the /etc/passwd, the only user is ubuntu, let's visit it:

And the error reveals the full path, /opt/Valenfind/templates/components/ . The app.py is probably at the /opt/Valenfind/ path.

And there it is, here's the full code:
Take a closer look here:
This endpoint exposes /api/admin/export_db, which allows downloading the application’s database if the X-Valentine-Token header matches ADMIN_API_KEY. The vulnerability lies in the fact that this token is hardcoded in the source, meaning once the code is exposed—through source leaks, client-side references, backups, or reverse engineering—the protection completely collapses. With no session-based authentication, role checks, or token rotation, possession of this static value is enough to access and exfiltrate the entire database. This turns the endpoint into a single-point failure where one leaked string results in full data compromise.
curl "http://10.65.144.2:5000/api/admin/export_db" -H "X-Valentine-Token: REDACTED" -o data.db

Now let's grep the hell out of that database file and get the flag!
strings data.db | grep "THM"

Hardcoded secrets leak. Hearts leak. One mistake, one exposure, and everything burns. I could take it. I don’t. True skill is bearing the pain of knowing. Protect, endure, give—without applause, without reward. Some things aren’t for possession—they’re for safeguarding. Some vulnerabilities aren’t yours to exploit—they’re yours to carry, quietly, painfully, selflessly. This is love. This is hacking. This is trust.
Last updated