zycoder0day/cve-2026-5076Prova de conceito de exploração para CVE-2026-5076 demonstrando tomada de conta de administrador não autenticada no ARMember Premium por meio de injeção SQL e armazenamento de chave de redefinição de senha em texto simples.
Chaves de Redefinição de Senha em Texto Simples Armazenadas no Banco de Dados + SQL Injection = Tomada Total da Conta de Admin
| Item | Detalhe |
|---|---|
| CVE ID | CVE-2026-5076 |
| Plugin | ARMember – Plugin de Associação e Restrição de Conteúdo |
| Versão Afetada | Premium <= 7.3.1 |
| Versão Corrigida | 7.3.2 |
| Pontuação CVSS | 9.8 Crítico |
| CWE | CWE-640: Recuperação de Senha Fraca |
| Tipo | Mecanismo Inseguro de Redefinição de Senha → Armazenamento de Chave em Texto Simples |
| Vetor de Ataque | Rede / Remoto / Não Autenticado (via cadeia de SQLi) |
| Instalações Ativas | 30.000+ (Premium) |
| Descobridor | Wordfence Threat Intelligence |
| Data de Publicação | 3 de Junho de 2026 |
| CVE | Tipo | Gravidade |
|---|---|---|
| CVE-2026-5076 | Redefinição de Senha Insegura — Armazenamento de Chave em Texto Simples | 9.8 Crítico |
| CVE-2026-5073 | SQL Injection Não Autenticada (ORDER BY) | 9.8 Crítico |
| CVE-2026-5074 | SQL Injection Não Autenticada (WHERE) | 9.8 Crítico |
Três vulnerabilidades críticas no plugin WordPress ARMember Premium <= 7.3.1 que, quando encadeadas, permitem a tomada total da conta de administrador sem autenticação:
wp_usermeta (arm_reset_password_key), e não com hash como no padrão do WordPressorder no manipulador AJAX arm_directory_paging_action()filter no manipulador AJAX arm_directory_paging_action()Consequência direta do CVE-2026-5076: Qualquer pessoa com acesso de leitura ao banco de dados (via SQLi, exposição de backup, etc.) pode ler a chave de redefinição de senha em texto simples e usá-la imediatamente para redefinir a senha de qualquer conta — sem necessidade de cracking.
O WordPress padrão armazena a chave de redefinição de senha na coluna user_activation_key em formato hash usando wp_hash(). O ARMember armazena uma cópia da mesma chave em wp_usermeta com a meta_key arm_reset_password_key — porém em formato TEXTO SIMPLES:```php
// FILE: armember-membership/core/class.arm_member_forms.php
// Fungsi: arm_lost_password_action()
// WordPress menyimpan HASHED key (aman) $key = wp_generate_password(20, false); $wp_key = $wpdb->get_var( $wpdb->prepare("SELECT user_activation_key FROM $wpdb->users WHERE user_login=%s", $user_login) );
// ARMember menyimpan PLAINTEXT key (VULNERABLE!) update_user_meta($user_id, 'arm_reset_password_key', $wp_key); // ^^^^^^ // Ini adalah key ASLI yang bisa langsung dipakai
**Problema crítico**: `$wp_key` aqui é a chave gerada por `wp_generate_password(20, false)` — 20 caracteres alfanuméricos. O WordPress faz hash dessa chave antes de armazená-la em `user_activation_key`, mas o ARMember a armazena **antes do hash** ou armazena uma cópia separada **não hasheada**.
### Causa Raiz #2: Bug de Persistência da Chave
Quando `get_password_reset_key()` é chamado (WordPress core), uma nova chave é gerada e hasheada. No entanto, esta função **NÃO atualiza** `arm_reset_password_key`:```php
// WordPress core: get_password_reset_key($user)
// - Generate key baru
// - Hash key → simpan di user_activation_key
// - Return key plaintext
// - TAPI: arm_reset_password_key TIDAK diupdate!
Consequentemente, a chave de texto simples antiga permanece armazenada para sempre em arm_reset_password_key mesmo depois que o usuário realiza uma redefinição de senha. Esta chave pode ser usada repetidamente até que a meta chave seja explicitamente excluída.
O manipulador AJAX arm_directory_paging_action() possui verificação de nonce via arm_check_user_cap(), mas os parâmetros order e filter entram diretamente na consulta SQL sem sanitização:```php
// FILE: armember-membership/core/class.arm_member_forms.php
// Fungsi: arm_directory_paging_action()
// Nonce check (dibutuhkan nonce valid) $nonce_check = $this->arm_check_user_cap();
// ORDER BY injection — langsung ke SQL tanpa sanitasi! $orderby = "u.{$arm_member} {$order_dir}"; // $order_dir dari $_POST['order'] → LANGSUNG ke ORDER BY
// WHERE injection via filter if (!empty($filter)) { $where .= " AND " . $filter; // ← LANGSUNG concatenation! }
**Exploração de ORDER BY**: O parâmetro `order` é inserido na cláusula `ORDER BY` SQL. Como não há sanitização, o atacante pode injetar subquery:```sql
-- Payload SQLi via parameter order
ORDER BY u.ID ASC, IF(COND, 1, EXP(710))
-- COND = TRUE → IF returns 1 → ORDER BY 1 → response normal (besar)
-- COND = FALSE → IF returns EXP(710) → MySQL overflow ERROR → response 90B
Este Oracle é imune à latência de rede porque distingue TRUE/FALSE baseado em erro vs sucesso, não no tempo de resposta.
╔══════════════════════════════════════════════════════════════════════════════════╗ ║ CVE-2026-5076 FULL CHAIN ATTACK ROADMAP ║ ║ ARMember Premium <= 7.3.1 → Unauthenticated Admin Takeover ║ ╚══════════════════════════════════════════════════════════════════════════════════╝