> For the complete documentation index, see [llms.txt](https://mistx0.gitbook.io/mistx0/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mistx0.gitbook.io/mistx0/write-ups/online/hackday-quals-2026/lets-meet.md). # Let's meet
The application provides simple login and account creation functionality. After logging in, we get our first look at the website.
A website to manage meetings for multiple people. Mainly we have 2 pages Account page which has a reset password and my appointments.
The other page has a calendar. Many endpoints to test, but first let's take a look at the note provided with the challenge. ```css ============================================================ SYSTEM ADMINISTRATION LOG - JANUARY 12, 2000 FROM: Samuel Sanders - (known also as admin_65537) SUBJECT: Maintenance & New Dev Features ============================================================ STATUS: SITE UNDER MAINTENANCE (PATCHING IN PROGRESS) The scheduling system is currently offline for a security patch cycle. While the frontend is restricted, I've started coding the new 'Admin Management API' to handle our MongoDB instances directly from the backend. NEW FEATURE: ADMIN MEMBER MANAGEMENT ------------------------------------ The internal API now allows us to force-add members to any appointment using their unique reference ID. This is for internal use ONLY on the management port (5000). Example usage for the dev team: curl "http://127.0.0.1:5000/api/admin/add-to-app?new_user=exampleuser&reference=exampleuser2-JAN1" NOTE: To simplify the early-stage testing (temporary), I have configured the backend so that any POST request sent to this route is automatically REDIRECTED to the GET handler. It's easier to debug via browser strings for now. NEW "SMART-NAV" FEATURE (BETA): ------------------------------- I've implemented a persistent replay buffer. Whenever a user books an appointment, the backend caches the entire POST request in db. Why? If a user accidentally deletes an appointment and wants to re-book it immediately, the system can "replay" that stored request at high speed. It saves the user from re-typing everything. WARNING: Do not expose port 5000 to the public gateway. ============================================================ /!\ For more details email me so that I can add you to the kick-off meeting I booked on the app on August, 21st. ``` There is a lot of information here let's take a quick look. Here is what i found important at first. 1. ``` admin_65537 -- > this could strongly be the admin username ``` 2. An internal endpoint we have to take a look at 
http://127.0.0.1:5000/api/admin/add-to-app?new_user=exampleuser&reference=exampleuser2-JAN1
From what the note says this endpoint can add any user to any meeting by just knowing the Username of the person created the meeting and at what time the meeting is. 3. SMART-NAV Feature this says it saves the entire POST request when a user creates a meeting, so if the user accidentally deletes a meeting they created they could recreate the meeting without typing all the information again. 4. The admin is creating a meeting on August, 21st. 5. ``` NOTE: To simplify the early-stage testing (temporary), I have configured the backend so that any POST request sent to this route is automatically REDIRECTED to the GET handler. It's easier to debug via browser strings for now. ``` This could explain why the **/api/admin** endpoint takes data in the url parameter, Because in a standard REST api we usually add resources using a POST request, that enables us to add a user with one simple GET request. With all of this information, We could have an overview of how the attack might happen. Simply we need a way to access that internal endpoint so we can add our user to the admin meeting, That can be achieved by SSRF but we don't know yet. Let's start testing each endpoint:
Any user can schedule an appointment from this endpoint **/book**
Here is how the request looks like, The user supplies the data in the body, i also made sure to test if there is a user name called admin\_65537 and it worked i added that user to the meeting which confirms our hypothesis. After going back to **/account**
Here is the meeting we created, on the top right we have some operations we could do on the meeting, Adding a user to the meeting, Editing the meeting details and deleting the meeting. From the notes we know there is something to do with replaying the meeting, Let's test it, After deleting the meeting this appeared in **/account**
Looking at the request:
It works by taking a reference for what meeting we want to replay, simple i tried SSRF there, I placed this as the reference **/api/admin/add-to-app?new\_user=exampleuser\&reference=exampleuser2-JAN1** Just to test the server behavior, That resulted in a 500 error i thought if found something interesting, but after some testing i realised i got this error because of how the server handles the reference input, it looks for two parts separated by a hyphen. After getting out of the rabbit hole i found something interesting.
The server didn't save any of my data like the meeting name, meeting details, etc...., This contradicts the note which says it is saving the FULL POST request,Maybe its relying on one value to create the meeting , After some testing i noticed something the first note i created didn't appear when i replied it, but other worked normally let's try to spot the difference.

First one

Second one

After some looking i found that the difference between them is the referer header, The first one that didn't work it didn't have the parameters that specified the date of the meeting, but the other one did. This confirms our idea that its only storing one value which is the referer header and it replays the url there. This is a strong SSRF vector, Let's try ``` http://127.0.0.1:5000/api/admin/add-to-app?new_user=mist&reference=admin_65537-AUG21 ``` After adding this as the referer and creating a meeting then deleting i didn't find it in the deleted meetings which also confirms that its relying on the d and m parameters to know the meeting reference so let's add them and try again ``` http://127.0.0.1:5000/api/admin/add-to-app?new_user=mist&reference=admin_65537-AUG21?d=21&m=JAN ``` BOOM!
There are multiple ways to bypass an SSRF filter but let's try with the most simple approach which is, changing the IP address format I tried multiple formats like ipv6 format and 0.0.0.0 but the one that worked is this **2130706433** which is the decimal format for 127.0.0.1 but i still didn't get into the admin meeting After some investigating ``` http://2130706433:5000/api/admin/add-to-app?new_user=mist&reference=admin_65537-AUG21?d=21&m=JAN ``` Its taking d and m as parameters for the GET request for **/api/admin** which we don't want we want these just for the replay endpoint to know the meeting reference, We can solve this by simply changing the ? to anything that wouldn't ruin the url like a # for example, so the final payload is ``` http://2130706433:5000/api/admin/add-to-app?new_user=mist&reference=admin_65537-AUG21#d=21&m=JAN ```
After creating this meeting, then deleting it and replaying it we get,
``` FLAG: HACKDAY{BL1ND_SSRF_W1TH_F1LT3R_BYP4SS_R0CKS_!!!} ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://mistx0.gitbook.io/mistx0/write-ups/online/hackday-quals-2026/lets-meet.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.