Hardening WordPress: Disabilitare wp-mail.php e Bonificare la Bacheca

All’interno delle installazioni standard di WordPress risiedono endpoint e moduli concepiti nei primi anni 2000, nati per scenari d’uso oggi superati. Tra questi spicca il sistema di pubblicazione articoli via email basato sul protocollo POP3 e orchestrato dal file wp-mail.php.

In un contesto moderno basato su REST API, autenticazione a due fattori e perimetri WAF isolati, mantenere attivo questo canale rappresenta un debito tecnico che consuma cicli di calcolo ed espone l’infrastruttura a tentativi di scansione e potenziale esaurimento delle risorse.

1. Il debito tecnico di wp-mail.php: Analisi del vettore

Il meccanismo nativo funziona interrogando una casella di posta remota via protocollo POP3: i messaggi in ingresso vengono analizzati dal server, l’oggetto convertito nel titolo del post e il corpo del testo salvato come articolo.

Questo approccio introduce criticità architetturali e di sicurezza non trascurabili:

• Overhead computazionale (Resource Exhaustion): Per sua natura, wp-mail.php esegue il bootstrap completo dell’ambiente WordPress (wp-load.php), alloca memoria RAM per l’interprete PHP e avvia connessioni al database prima ancora di verificare se il servizio sia realmente configurato. Uno spider o un attacco automatizzato che colpisce ripetutamente questo endpoint genera un consumo inutile di thread PHP.
• Autenticazione debole e spoofing: Il protocollo POP3 originale non offre standard di sicurezza conformi ai criteri di Zero Trust. Se i parametri vengono configurati con credenziali deboli o senza crittografia di canale, un attaccante in grado di falsificare i mittenti di posta (email spoofing) potrebbe tentare di iniettare contenuti non autorizzati a database.
• Rumore cognitivo nella UI: Nella schermata Impostazioni → Scrittura, WordPress continua a mostrare campi di configurazione server, porte e password in chiaro, disorientando redattori e sistemisti.

2. Livello 1: Protezione perimetrale su Web Server (Apache 2.4)

Il primo principio di hardening impone che il traffico ostile o inutile non debba mai raggiungere l’interprete PHP. Se il web server intercetta e abbatte la chiamata a livello socket, il consumo di CPU e memoria sul server rimane pari a zero.

All’interno del file .htaccess (o nel file di configurazione del Virtual Host), iniettiamo la direttiva di diniego esplicito per Apache 2.4:

<Files wp-mail.php>
    Require all denied
</Files>

Per le infrastrutture che utilizzano NGINX come reverse proxy o web server primario, la direttiva equivalente nel blocco server è:

location = /wp-mail.php {
    deny all;
    access_log off;
    log_not_found off;
}

Collaudando la richiesta tramite curl -I, il web server risponderà immediatamente con un’intestazione 403 Forbidden nativa senza avviare il motore applicativo.

3. Livello 2: Disattivazione nel Core e bonifica della Bacheca

Bloccare l’accesso al file fisico non è sufficiente per garantire un’esperienza utente pulita all’interno della dashboard amministrativa. Nascondere la sezione tramite fogli di stile CSS (display: none) è un approccio fragile che lascia intatta la logica di backend.

WordPress espone nel proprio core un hook specifico progettato per disattivare strutturalmente l’intero modulo: enable_post_by_email_configuration.

Inserisci questo filtro in un Must-Use Plugin (ad esempio in /wp-content/mu-plugins/db-hardening.php):

<?php
/**
 * Disabilita la pubblicazione via email nel core e bonifica la UI amministrativa.
 */
add_filter( 'enable_post_by_email_configuration', '__return_false' );

Gli effetti sistemistici dell’hook:

• Rimozione nativa del markup: Il motore di WordPress salta l’esecuzione della sezione «Pubblica articoli via email» in wp-admin/options-writing.php. Il titolo <h2> e la tabella dei campi (server, porta, utente, password) non vengono inseriti nel DOM inviato al browser.
• Eliminazione dei tab contestuali: La documentazione di aiuto in alto a destra viene privata delle istruzioni legacy POP3.
• Sicurezza di secondo livello: Se un’anomalia di routing dovesse consentire il passaggio di una richiesta verso wp-mail.php, lo script verificherebbe il filtro ed eseguirebbe all’istante una terminazione forzata con wp_die( ..., 403 ).