---

📋 Informazioni sulla vulnerabilità

Voce	Dettaglio
ID CVE	CVE-2026-5076
Plugin	ARMember – Membership Plugin & Content Restriction
Versione interessata	Premium <= 7.3.1
Versione patchata	7.3.2
Punteggio CVSS	9.8 Critical
CWE	CWE-640: Weak Password Recovery
Tipo	Meccanismo di reset password insicuro → archiviazione della chiave in chiaro
Vettore di attacco	Network / Remote / Unauthenticated (via SQLi chain)
Installazioni attive	30,000+ (Premium)
Scoperto da	Wordfence Threat Intelligence
Data di pubblicazione	3 giugno 2026

CVE correlate (stesso advisory)

CVE	Tipo	Gravità
CVE-2026-5076	Reset password insicuro — archiviazione della chiave in chiaro	9.8 Critical
CVE-2026-5073	SQL Injection non autenticata (ORDER BY)	9.8 Critical
CVE-2026-5074	SQL Injection non autenticata (WHERE)	9.8 Critical

---

🎯 Riepilogo

Tre vulnerabilità critiche nel plugin WordPress ARMember Premium <= 7.3.1 che, se concatenate tra loro, consentono la compromissione totale dell'account amministratore senza autenticazione:

1. CVE-2026-5076 — La chiave di reset password è memorizzata in plaintext in wp_usermeta (arm_reset_password_key), non hashata come da standard WordPress
2. CVE-2026-5073 — SQL Injection nel parametro order dell'handler AJAX arm_directory_paging_action()
3. CVE-2026-5074 — SQL Injection nel parametro filter dell'handler AJAX arm_directory_paging_action()

Conseguenza diretta di CVE-2026-5076: chiunque abbia accesso in lettura al database (via SQLi, esposizione di backup, ecc.) può leggere la chiave di reset password in forma plaintext e usarla immediatamente per resettare la password di qualsiasi account — senza dover eseguire alcun cracking.

---

🔬 Analisi tecnica

Causa principale #1: archiviazione della chiave in chiaro (CVE-2026-5076)

WordPress standard memorizza la chiave di reset password nella colonna user_activation_key in forma hashata utilizzando wp_hash(). ARMember memorizza una copia della stessa chiave in wp_usermeta con meta_key arm_reset_password_key — ma in forma PLAINTEXT:```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 critico**: `$wp_key` qui è la chiave generata da `wp_generate_password(20, false)` — 20 caratteri alfanumerici. WordPress esegue l'hash di questa chiave prima di salvarla in `user_activation_key`, ma ARMember la salva **prima dell'hashing** oppure salva una copia separata **non sottoposta a hash**.

### Root Cause #2: Key Persistence Bug

Quando `get_password_reset_key()` viene chiamata (WordPress core), viene generata e sottoposta a hash una nuova chiave. Tuttavia questa funzione **NON aggiorna** `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!

Di conseguenza, la vecchia chiave in chiaro rimane memorizzata per sempre in arm_reset_password_key anche dopo che l'utente ha eseguito il reset della password. Questa chiave può essere riutilizzata più volte finché la meta key non viene eliminata esplicitamente.

Causa principale #3: SQL Injection (CVE-2026-5073/5074)

L'handler AJAX arm_directory_paging_action() ha un nonce check tramite arm_check_user_cap(), ma i parametri order e filter entrano direttamente nella query SQL senza sanitizzazione:```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! }

**Exploit ORDER BY**: Il parametro `order` viene inserito nella clausola `ORDER BY` SQL. Poiché non c'è sanitizzazione, un attaccante può iniettare una 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

Questo Oracle è immune alla latenza di rete perché distingue TRUE/FALSE in base a errore vs successo, non al tempo di risposta.

---

⛓️ Roadmap della catena di attacco```

╔══════════════════════════════════════════════════════════════════════════════════╗ ║ CVE-2026-5076 FULL CHAIN ATTACK ROADMAP ║ ║ ARMember Premium <= 7.3.1 → Unauthenticated Admin Takeover ║ ╚══════════════════════════════════════════════════════════════════════════════════╝