Aggiornamenti importanti e rilascio: Wendy!!

Icona 2

Wendy, che sta per WordPress ENDpoint discoverY è appena stato aggiornato e rilasciato alla nuova versione stabile v0.4.0. Gli aggiornamenti e i miglioramenti che sono stati fatti sono impressionanti… Le grosse novità sono Intelligence feeds da wordfence e modalità aggressive con token da wpscan:

Aggiornamenti Core (tutte le modalità)

  • WordPress Detection – versione, tema attivo, plugin attivi
  • Plugin/Theme Discovery – fino a 15 000+ plugin e temi da database CVE live (Wordfence Intelligence); versione letta da readme.txt (plugin) e style.css (temi)
  • Smart Probing – in modalità normale proba i top 3 000 slug ordinati per score di priorità (popolarità WP.org × CVE recenti × severità); modalità aggressive proba tutto il database
  • CVE Matching – confronto versione installata vs database vulnerabilità; riporta CVE ID, CVSS score, severità, descrizione; supporta plugin e temi
  • Security Headers – verifica presenza e valore di HSTS, CSP, X-Frame-Options, Referrer-Policy e altri header; segnala configurazioni deboli (CSP con unsafe-inline/unsafe-eval, HSTS max-age troppo corto)
  • User Enumeration – REST API /wp-json/wp/v2/users (con paginazione), author archives /?author=N, RSS feed, commenti REST API, login error differential
  • XML-RPC – verifica accesso, pingback (DDoS amplification), multicall (brute-force amplification)
  • Hardening Checks – wp-config.php, .env, debug.log, readme.html, install.php, xmlrpc.php, directory listing su wp-content/uploads/
  • Advanced WordPress Checks (nuovi in v0.4.0): REST API namespace enumeration + /wp-json/wp/v2/settings leakage Verifica protezione wp-admin/ (redirect a login vs accesso diretto) Rilevamento protezioni anti-brute-force su wp-login.php (CAPTCHA, lockout, 2FA, rate-limit headers) Test esecuzione PHP in wp-content/uploads/ Rilevamento WP_DEBUG attivo in produzione via errori REST API

Aggressive mode (–aggressive)

  • User enumeration estesa (fino a 20 author ID; login error differential)
  • Plugin e theme discovery senza limiti (tutti i 15 000+ slug CVE-DB)
  • WPScan API enrichment (richiede WPSCAN_API_TOKEN)

È stato creato un file da editare nominato “.keys” nel quale, come dice il nome, è possibile aggiungere le api keys e i token, ma ci sono anche altri parametri importanti che possono determinare una scansione completa con più o meno copertura:

╰─>>[ cat .keys.example                                                                          
# WENDY API Keys & Probe Tuning
# ─────────────────────────────────────────────────────────────────────────────
# Copy this file to wendy/.keys and fill in your keys.
# wendy/.keys is gitignored and will never be committed.
#
# All values here are also readable as environment variables, which take
# precedence over this file (useful for CI/CD pipelines).

# ── API Keys ──────────────────────────────────────────────────────────────────

# Wordfence Intelligence API key — required for CVE database updates (-u flag)
# Obtain for free at: https://www.wordfence.com (Account → Integrations)
WORDFENCE_API_KEY=

# WPScan API token — required for extended CVE lookup in aggressive mode
# Free plan: 25 requests/day — https://wpscan.com/register
WPSCAN_API_TOKEN=

# ── Probe Tuning (optional) ───────────────────────────────────────────────────
#
# These parameters control which plugins are probed and how they are scored.
# Defaults work well for most use cases; adjust for faster or more thorough scans.

# Minimum WordPress active installs for a plugin to be included in normal mode.
# Plugins below this threshold are skipped UNLESS they carry a recent CRITICAL CVE
# (those are always probed regardless of install count).
#
# Suggested values:
#   0       — no filter, probe all ~15 000 CVE-DB slugs (default, aggressive behaviour)
#   1 000   — skip ultra-niche plugins, reduces normal-mode list significantly
#   10 000  — skip anything not widely deployed; still catches ~95 % of real targets
#   100 000 — only widely-used plugins; fastest scan, misses niche installs
#
MIN_ACTIVE_INSTALLS=0

# Maximum number of plugins probed in normal (non-aggressive) mode.
# Increase for broader coverage, decrease for faster scans.
# Default: 3000
PROBE_NORMAL_LIMIT=3000

# Maximum number of themes probed in normal mode.
# Default: 100
PROBE_THEME_LIMIT=100

# How many plugins to fetch from WordPress.org to build the installs index.
# A larger index improves scoring accuracy but adds a few seconds to -u updates.
# Default: 10000
INSTALLS_INDEX_LIMIT=10000

# Comma-separated list of CVE years considered "recent" for priority scoring.
# Recent CVEs receive a +3 bonus per entry — set this to the last 1-2 years
# if you want tighter focus, or add future years as they become active.
# Default: 2024,2025,2026
CVE_YEARS=2024,2025,2026

Questo parametro “MIN_ACTIVE_INSTALLS=0” indica quante installazioni almeno deve avere un plugin per essere ricercato sul sito target, questo dato lo si ottiene quando si fa l’update del db da wordfence e la logica è questa, wendy ti chiede “Io sto facendo una ricerca sul target e sto cercando i plugin, sono più di 15.000 e sono tanti ci posso mettere anche delle ore, quindi, i plugin che ti devo cercare sono conosciuti da molti o sono quasi all’oblio? In tutto l’universo wordpress, tra tutti i siti che esistono in wp i plugin che ti devo cercare devono essere stati installati almeno su quanti siti? 1.000? 10.000? 100.000?” un plugin che è stato installato su 100 siti, possiamo dire che è quasi sconosciuto, quindi quale probabilità abbiamo di trovarlo proprio su questo sito?

Ma c’è un altro meccanismo che entra in gioco, nonostante un plugin sia scarsamente installato se esiste una cve critica recente questo viene ricercato lo stesso, indipendentemente dal fatto che sia stato inserito un count. Questo ci porta all’altro parametro secondo me importante: “CVE_YEARS=2024,2025,2026” indica quanto “recenti” devono essere le cve ricercate, se vogliamo solo quelle del 2026 aggiusteremo l’entry con “CVE_YEARS=2026” se invece vogliamo andare più indietro e avere più copertura aggiungerò più anni.


C’è anche un altra anticipazione, application_traceroute_4_0 ci sta regalando parecchie soddisfazioni, la percentuale di detection è molto alta, e la rimozione dei falsi positivi è precisa e accurata portando un risultato veramente veramente concreto per un tool che non proviene dalla sylicon valley ma da un paese tra le campagne delle bassa bergamasca:

Siamo in fase di ultimazione, manca veramente poco. Vorrei ricordare che la suite application_traceroute + smart_crawler ha unito per la prima volta concetti di matematica avanzata per la selezione delle tecniche di avanzamento, la prioritizzazione, la conferma e la probabilità di riuscita. Teoria dei grafi, entropia di shannon, game theory e molto altro non è solo “contorno” è matematica seria applicata alla cybersecurity… e funziona!!

La versione stabile è ancora la 3.5 e funziona standalone, la versione 4.0 invece si installa nel virtual env e si utilizza con security-traceroute –help o security-crawler –help

Output di security-crawler: bypass engine, wordlist e rilevamento tecnologia caricati con successo

Con tutto il bene che vogliamo alfree software, all’opensource e alladiffusione di saperi e conoscenze abbiamo deciso di implementare un gestore di licenze, mensili o annuali, nonostante questo isorgenti sono disponibili su github. Se volete testare la v4.0 clonate la branch stabile, checkout sulla “‹v4.0-suite-stable›” , installate le dipendenze nel venv e lanciate il tool. Se volete avere licenze free contattateci in privato, non esiterò a fornirvi supporto. A questa pagina trovate i nostri software, mentre il repository di wpscanner WENDY è a questo link

Grazie di tutto e buon lavoro


Potrebbe interessarti anche

ItalianoitItalianoItaliano