Avviso di esposizione di dati sensibili del plugin LatePoint//Pubblicato il 2026-04-19//CVE-2026-5234

TEAM DI SICUREZZA WP-FIREWALL

LatePoint CVE-2026-5234 Vulnerability

Nome del plugin LatePoint
Tipo di vulnerabilità Esposizione di dati sensibili
Numero CVE CVE-2026-5234
Urgenza Basso
Data di pubblicazione CVE 2026-04-19
URL di origine CVE-2026-5234

LatePoint <= 5.3.2 — Riferimento diretto a oggetti non sicuro (IDOR) che espone fatture (CVE-2026-5234): Cosa devono fare ora i proprietari di siti WordPress

Riepilogo
Una vulnerabilità recentemente divulgata (CVE-2026-5234) nel plugin di appuntamenti e prenotazioni LatePoint — che colpisce le versioni fino e comprese 5.3.2 — consente a attori non autenticati di enumerare ID fattura sequenziali e recuperare pagine di fattura che contengono informazioni finanziarie sensibili. Questo è un classico problema di Riferimento diretto a oggetti non sicuro (IDOR) / controllo accessi non sicuro che può esporre dettagli di fatturazione e altri dati privati dei clienti. Il fornitore ha rilasciato una versione corretta (5.4.0). Se esegui LatePoint sul tuo sito, devi agire ora.

Questo post è scritto dalla prospettiva di un team di sicurezza WordPress con esperienza pratica nella risposta agli incidenti. Spiegherò qual è il problema, come gli attaccanti possono sfruttarlo, come puoi rilevare se sei colpito, mitigazioni pratiche che puoi applicare immediatamente (inclusi tecniche di WAF/patching virtuale) e indurimenti a lungo termine per prevenire fallimenti simili in futuro.

Nota: Non utilizzare alcuna tecnica di test descritta di seguito su sistemi che non possiedi o per i quali non hai autorizzazione esplicita per testare. Il test non autorizzato potrebbe essere illegale.

Sommario

  • Contesto: cosa è successo
  • Perché questo è importante: rischi per la tua attività e i clienti
  • Panoramica tecnica (IDOR tramite ID fattura sequenziale)
  • Confermare se il tuo sito è vulnerabile (controlli sicuri)
  • Mitigazioni a breve termine (applica se non puoi aggiornare immediatamente)
  • Guida a WAF e patching virtuale — modelli e regole di esempio
  • Correzioni consigliate a lungo termine
  • Checklist per la rilevazione e la risposta agli incidenti
  • Come WP-Firewall aiuta (e come iniziare)
  • Conclusione
  • Riferimenti

Contesto: cosa è successo

LatePoint è un plugin di prenotazione e appuntamenti WordPress ampiamente utilizzato che include funzionalità di fatturazione. Nelle versioni fino e comprese 5.3.2 è stata scoperta una falla in cui le risorse di fattura potevano essere accessibili senza adeguati controlli di accesso. Le fatture sono riferite da identificatori sequenziali, il che significa che un attaccante può iterare gli ID (1, 2, 3…) e recuperare pagine di fattura senza autenticazione. Quella pagina contiene spesso dettagli di fatturazione dei clienti e altri metadati finanziari, e in alcuni casi può includere informazioni relative ai pagamenti (a seconda di come è stato configurato il sito).

Questo tipo di vulnerabilità è generalmente categorizzato come un IDOR — un tipo di Controllo accessi interrotto — e mappato alle preoccupazioni OWASP A3 / Esposizione di dati sensibili. La vulnerabilità è identificata con CVE-2026-5234.

La soluzione più sicura è aggiornare LatePoint alla versione 5.4.0 o successiva, che contiene la correzione del fornitore. Se non puoi aggiornare immediatamente — ad esempio, a causa di personalizzazioni, vincoli ambientali o requisiti di staging/QA — devi implementare controlli compensativi per prevenire la perdita di informazioni.

Perché questo è importante: rischi per la tua attività e i clienti

Anche se il punteggio CVSS assegnato è moderato, gli IDOR che perdono informazioni finanziarie o identificabili personalmente sono gravi per diversi motivi:

  • L'esposizione delle fatture rivela nomi dei clienti, indirizzi email, indirizzi di fatturazione, importi pagati, descrizioni dei servizi e talvolta ID transazione o dettagli parziali della carta — tutti dati sensibili.
  • Danno reputazionale: i clienti si aspettano che le aziende proteggano i loro dati di fatturazione. Una violazione potrebbe danneggiare la fiducia.
  • Rischio normativo e di conformità: a seconda della tua giurisdizione e delle operazioni di elaborazione, la perdita di dati di fatturazione potrebbe attivare obblighi di notifica di violazione ai sensi del GDPR, PCI-DSS, leggi sulla privacy statali o altre normative.
  • Attacchi successivi: i dati esposti possono essere utilizzati per phishing mirato, ingegneria sociale, stuffing di credenziali o tentativi di takeover dell'account.
  • Scraping di massa: gli attaccanti possono automatizzare l'enumerazione di ID sequenziali e raccogliere migliaia di pagine di fattura su molti siti vulnerabili rapidamente.

In parole semplici: anche se su un singolo sito l'impatto appare ridotto, questa vulnerabilità può essere sfruttata su larga scala.

Panoramica tecnica (come funziona l'IDOR)

A un livello alto, la vulnerabilità deriva da tre condizioni:

  1. Le risorse delle fatture sono indirizzabili tramite un identificatore nell'URL (ad esempio, /invoices/view/{id} o un parametro GET come ?invoice_id=123).
  2. L'identificatore è prevedibile e sequenziale.
  3. Il codice lato server restituisce il contenuto della fattura senza controlli di autorizzazione sufficienti (ad esempio, non verifica la sessione corrente o controlla il proprietario della fattura).

Un attaccante può approfittare di questo:

  • Scoprendo un formato di URL della fattura (a volte tramite un link di fattura legittimo o un modello di sito).
  • Scrivendo un piccolo script che itera gli ID interi e richiede ciascun URL della fattura.
  • Salvando eventuali risposte non 404 e scansionando il contenuto della fattura (nomi, importi, indirizzi).

Lo scenario peggiore è che l'attaccante raccoglie un grande volume di fatture e dati sensibili.

Nota importante: i nomi esatti degli endpoint e i parametri variano tra le implementazioni dei plugin e le configurazioni dei siti. Il problema principale è la mancanza di controlli di autorizzazione lato server.

Confermare se il tuo sito è vulnerabile (controlli sicuri)

Se sei un proprietario di sito o un amministratore autorizzato, esegui questi controlli in modo controllato:

  1. Controlla la tua versione di LatePoint:
    – In WP admin > Plugin o ispezionando il readme/changelog del plugin. Se la tua versione di LatePoint è 5.3.2 o inferiore, tratta il sito come vulnerabile fino a quando non viene corretto.
  2. Cerca nel tuo sito gli endpoint delle fatture:
    – Nell'interfaccia di prenotazione/fattura, cerca URL che contengono ID di fattura o token numerici.
    – Luoghi comuni: email di conferma appuntamenti rivolte ai clienti, pagine di visualizzazione delle fatture per gli amministratori.
  3. Test di riproduzione sicura (solo sul tuo sito):
    – Accedi a un account non privilegiato se disponibile (o usa una sessione in incognito).
    – Prova ad accedere a un URL di fattura per un ID diverso che non possiedi.
    – Se il sito restituisce contenuti di fattura per altri ID di fattura mentre non sei autenticato o con un utente che non dovrebbe avere accesso, sei vulnerabile.
  4. Analisi dei log:
    – Cerca nei log del tuo server web modelli come fattura o noti endpoint di LatePoint durante una finestra di preoccupazione:

    grep -i "fattura" /var/log/nginx/access.log*

    – Cerca richieste ripetute e sequenziali da singoli IP o user-agent — un segno di enumerazione.

  5. Ispezione del database:
    – Se sicuro e autorizzato, ispeziona la tabella delle fatture per verificare le sequenze di ID. Le chiavi numeriche sequenziali sono facilmente enumerate.

Se confermi l'esposizione, assumi che i dati possano essere stati raccolti e procedi con la risposta all'incidente (vedi sezione successiva).

Mitigazioni a breve termine che puoi applicare ora

Se un aggiornamento immediato del plugin a 5.4.0 non è possibile, implementa uno o più dei seguenti controlli compensativi per interrompere l'enumerazione e bloccare l'accesso non autenticato:

  1. Aggiorna LatePoint a 5.4.0 o successivo (consigliato).
    – Questa è la soluzione definitiva. Pianifica un aggiornamento in produzione non appena possibile.
  2. Blocca l'accesso pubblico agli endpoint delle fatture utilizzando un semplice controllo di autenticazione (esempio PHP)
    – Aggiungi un mu-plugin o un piccolo frammento da inserire per richiedere l'autenticazione per le visualizzazioni delle fatture:
<?php
// File: wp-content/mu-plugins/latepoint-invoice-protect.php
add_action('init', function(){
    // Adjust pattern to match your invoice URL / parameter
    // Example: ?invoice_id=123 or /latepoint/invoice/123
    if ( isset($_GET['invoice_id']) || (isset($_SERVER['REQUEST_URI']) && strpos($_SERVER['REQUEST_URI'], '/latepoint/invoice/') !== false) ) {
        // Allow administrators or specific roles (change as needed)
        if ( !is_user_logged_in() ) {
            // Return 403 for unauthenticated users
            status_header(403);
            wp_die('Access denied', 'Forbidden', ['response' => 403]);
            exit;
        }
    }
}, 1);

Importante: testalo prima in staging. L'obiettivo è prevenire il recupero anonimo delle fatture; adatta il matching dell'URL al tuo ambiente.

  1. Negare l'accesso a livello di server web (indurimento rapido)

Esempio Apache (.htaccess) per bloccare l'accesso diretto agli endpoint delle fatture:

# Blocca l'accesso agli URI delle fatture di LatePoint per utenti non autenticati (semplice)

Esempio Nginx (blocca se invoice_id presente e nessun cookie/sessione):

# all'interno del blocco server {}

Queste regole del server web sono strumenti blunt — negano tutto l'accesso, comprese le richieste legittime. Usale solo come misure temporanee fino a quando non implementi un controllo più sicuro a livello di applicazione.

  1. Aggiungi limitazione della velocità e sfida IP
    • Applica la limitazione della velocità a qualsiasi endpoint di fattura per rallentare i tentativi di enumerazione:
    • Limita a poche richieste al minuto per IP.
    • Usa CAPTCHA o risposte di sfida sulle pagine che rivelano gli ID delle fatture, se possibile.
  2. Cambia i link pubblici delle fatture
    • Se la tua configurazione invia link con ID prevedibili in email o pagine pubbliche, modifica i modelli per evitare di esporre ID numerici diretti. Usa token hashati o a tempo se possibile.
  3. Patch virtuale con un WAF (raccomandato se ne hai uno)
    • Implementa una regola WAF che blocca le richieste agli endpoint delle fatture a meno che non presentino un cookie, un'intestazione approvata o provengano da un IP fidato. Vedi la sezione WAF qui sotto per esempi di modelli di regole.

Guida WAF e patching virtuale — modelli, logica e regole di esempio

Se gestisci un Web Application Firewall (WAF) — inclusi WAF gestiti e basati su plugin — dovresti applicare una patch virtuale temporanea per bloccare le richieste non autenticate alle risorse delle fatture.

Principi per una regola WAF/patching virtuale:

  • Targetizza solo le richieste che corrispondono al modello dell'endpoint vulnerabile (percorso URL o parametro GET).
  • Consenti il traffico legittimo che contiene un cookie di sessione autenticato o un'intestazione specifica.
  • Blocca o sfida (CAPTCHA) tutte le altre richieste.
  • Registra i tentativi bloccati e notifica i proprietari della sicurezza.

Di seguito sono riportate regole di esempio per stili WAF comuni. Questi sono esempi generici e illustrativi — adatta al tuo ambiente e testa con attenzione.

  1. Regola WAF generica (pseudo-logica)
    • SE il percorso della richiesta contiene “/invoices/” OPPURE il parametro GET “invoice_id” è presente
    • E la richiesta NON include un cookie di autenticazione WordPress valido (wordpress_logged_in_*)
    • QUINDI blocca la richiesta (HTTP 403) o presenta una sfida CAPTCHA.
  2. Esempio di regola ModSecurity (Apache; illustrativa):
Regola ModSecurity # per bloccare l'accesso non autenticato alle pagine delle fatture

Note:

  • Questa regola controlla i modelli di URL delle fatture e nega la richiesta se non è presente un cookie di accesso a WordPress.
  • La sintassi RICHIESTA_COOKIE:/wordpress_logged_in_.*@eq 0 è illustrativa. Il tuo motore ModSecurity potrebbe richiedere un approccio diverso per il matching dei cookie.
  1. Nginx + Lua / pseudo-regola WAF personalizzata
    • Ispeziona intestazioni e cookie per il cookie di accesso a WordPress.
    • Se non presente e l'URI corrisponde a un endpoint di fattura noto, restituisci 403 o emetti una sfida.
  2. Regole UI Cloud/WAF (WAF gestiti)
    • Crea una regola per abbinare le richieste contenenti fattura nel percorso o il parametro id_fattura, e blocca le richieste a meno che non abbiano il wordpress_logged_in cookie.
    • Limita il traffico corrispondente e genera un avviso.
  3. Regola focalizzata sulla rilevazione (raccomandata insieme al blocco)
    • Crea una regola che registra e conta le richieste che corrispondono ai modelli di enumerazione delle fatture (ad es., stesso IP che richiede ID crescenti). Imposta una soglia (ad es., 10 ID fattura distinti richiesti da un singolo IP entro 60s) e attiva un avviso.

Perché la patch virtuale è utile

I programmi di distribuzione delle patch a volte ritardano a causa di test, personalizzazioni di terze parti o processi aziendali. Il WAF/patching virtuale fornisce una barriera immediata all'exploit, riducendo la finestra di esposizione mentre ti prepari ad aggiornare il plugin e a eseguire eventuali test di regressione richiesti.

Correzioni consigliate a lungo termine

Una volta contenuto il rischio immediato, segui questi passaggi per rafforzare la resilienza:

  1. Aggiorna LatePoint alla versione 5.4.0 o successiva
    • Mantieni i plugin aggiornati. Tieni traccia delle versioni e degli avvisi di sicurezza.
  2. Applica l'autorizzazione lato server ovunque.
    • Assicurati che qualsiasi risorsa con dati sensibili controlli sia l'autenticazione che se l'utente autenticato è autorizzato a visualizzare quella risorsa (controlli di proprietà o di ruolo).
    • Usa controlli di capacità ed evita di fare affidamento sull'oscurità (ad es., ID non sequenziali) come unica protezione.
  3. Sostituisci gli ID numerici sequenziali con identificatori opachi.
    • Usa UUID, hash o token firmati per i link pubblici. I token a tempo limitato sono preferiti per le fatture inviate via email.
  4. Revisioni del codice e test di sicurezza
    • Aggiungi controlli di accesso alla tua lista di controllo della sicurezza per le revisioni del codice.
    • Usa scansioni automatiche (SAST) e test manuali/interattivi per trovare IDOR.
  5. Registrazione, monitoraggio e allerta
    • Registra i tentativi di accesso agli endpoint delle fatture separatamente e crea avvisi per schemi insoliti.
    • Mantieni i log per un periodo di conservazione sufficiente a supportare l'indagine forense.
  6. Principio del privilegio minimo
    • Limita quali dati sono inclusi nelle pagine pubbliche. Non includere dettagli completi della carta o di pagamento nelle pagine delle fatture a meno che non sia necessario e conforme al PCI.
  7. Sicurezza dei modelli email.
    • Evita di inviare link diretti con ID prevedibili. Preferisci portali per utenti autenticati o token firmati.
  8. Revisione della privacy e della conformità.
    • Se i dati dei clienti sono stati esposti, consulta i team legali/compliance per determinare gli obblighi di notifica.

Checklist per la rilevazione e la risposta agli incidenti

Se sospetti che il tuo sito sia stato preso di mira o sfruttato, segui una risposta agli incidenti strutturata:

  1. Contenimento immediato (0–24 ore).
    • Aggiorna LatePoint a 5.4.0+ se possibile.
    • Se l'aggiornamento è bloccato, implementa la mitigazione a livello di webserver o applicazione mostrata sopra (richiedi autenticazione per gli endpoint delle fatture).
    • Abilita la regola WAF per bloccare i tentativi di enumerare gli ID delle fatture.
    • Ruota le credenziali di amministratore e API se sospetti un compromesso.
  2. Raccolta di prove (24–72 ore)
    • Conserva i log (webserver, applicazione, WAF) — copiali in un backup immutabile per l'analisi.
    • Esporta le tabelle del database LatePoint rilevanti (fatture, pagamenti, utenti) per una revisione offline.
    • Registra i timestamp e gli IP dei modelli di accesso sospetti.
  3. Indagine e determinazione dell'ambito
    • Identifica se un attaccante ha enumerato le fatture e quanti record sono stati accessi.
    • Controlla i segni di esfiltrazione: richieste GET sequenziali a lungo raggio, agenti utente insoliti o modelli di traffico scriptati.
    • Rivedi i log di invio email — i link delle fatture sono stati accessi dagli stessi IP?
  4. Rimedi e recupero
    • Applica la patch al plugin (5.4.0+) in una finestra di manutenzione.
    • Applica il rafforzamento (token non sequenziali, controlli di autenticazione).
    • Revoca e riemetti eventuali chiavi, token o credenziali compromessi.
    • Se i dati di pagamento sono stati esposti e l'ambito PCI è implicato, segui le procedure per gli incidenti PCI.
  5. Notifiche e documentazione
    • A seconda dell'esposizione, prepara le notifiche ai clienti e la segnalazione agli enti regolatori come richiesto dalla legge e dalla politica interna.
    • Documenta la cronologia dell'incidente, le misure adottate e le lezioni apprese.
  6. Azioni successive all'incidente
    • Esegui una revisione della sicurezza per prevenire ricorrenze.
    • Considera un audit di terze parti o un test di penetrazione per convalidare le correzioni.
    • Implementa un monitoraggio migliorato e runbook per incidenti simili.

Come testare e convalidare la tua mitigazione (controlli sicuri e non invasivi)

Dopo aver applicato una mitigazione (regola WAF o aggiornamento del plugin):

  • Utilizza account QA interni per verificare che le pagine delle fatture si comportino normalmente per gli utenti autorizzati.
  • Prova ad accedere a un URL di fattura mentre non sei autenticato — conferma di ricevere 403 o una sfida, non il contenuto della fattura.
  • Controlla i log per assicurarti che le richieste bloccate siano catturate con identificatori di regola e IP di origine.
  • Esegui un test di enumerazione controllato e limitato da un IP noto per garantire che il rate-limiting funzioni e che gli avvisi vengano attivati.

Esempio curl controlli (esegui solo contro il tuo sito):

Controllo autenticato (sostituisci il valore del cookie di conseguenza):

curl -I -H "Cookie: wordpress_logged_in_XXXX=..." "https://example.com/latepoint/invoice/123"

Controllo non autenticato:

curl -I "https://example.com/latepoint/invoice/123"

Aspettati 403 o reindirizzamento al login piuttosto che 200 con contenuto della fattura

Come WP-Firewall aiuta: protezione pratica e mitigazione rapida

(Breve spiegazione delle capacità della piattaforma, scritta dal team di sicurezza di WP-Firewall)

  • Se gestisci la sicurezza di WordPress con WP-Firewall, ecco come rendiamo la mitigazione veloce e gestibile quando appare una vulnerabilità come questa:.
  • Firme WAF gestite e patch virtuali: possiamo implementare regole per bloccare richieste non autenticate agli endpoint delle fatture e firme adattate rapidamente ai modelli di problemi di LatePoint, prevenendo l'enumerazione di massa mentre testi e applichi la patch del fornitore.
  • Scanner di malware e monitoraggio: la scansione continua aiuta a rilevare cambiamenti anomali nei file o nuovi script che potrebbero far parte di attività post-sfruttamento.
  • Protezione della larghezza di banda illimitata e regole in tempo reale: le regole di mitigazione vengono servite al confine per fermare il traffico malevolo senza degradare l'accesso legittimo.
  • Copertura di mitigazione OWASP: le protezioni integrate mirano a classi comuni di attacchi web, riducendo l'esposizione a lacune nel controllo degli accessi e attacchi di enumerazione.

Registrazione degli incidenti e avvisi: forniamo log e avvisi contestuali per aiutarti a gestire tentativi di enumerazione sospetti e seguire con un'indagine.

Inizia a proteggere il tuo sito WordPress — prova WP-Firewall Basic (gratuito)

Proteggi il tuo sito subito con un'opzione sempre gratuita che include un firewall gestito, WAF, scansione malware e mitigazione per i rischi OWASP Top 10. Il piano Basic è ideale per i proprietari di siti che necessitano di uno strato di sicurezza immediato senza costi, ed è semplice da attivare mentre testi gli aggiornamenti dei plugin e le misure di indurimento.

Punti salienti del piano:

  • Basic (Gratuito): firewall gestito, larghezza di banda illimitata, WAF, scanner malware e mitigazione dei rischi OWASP Top 10.
  • Standard ($50/anno): include rimozione automatica del malware e controlli flessibili di blacklist/whitelist IP.
  • Pro ($299/anno): funzionalità avanzate, report di sicurezza mensili, patch virtuali automatiche e componenti aggiuntivi premium per servizi gestiti.

Iscriviti al piano gratuito qui: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Esempi pratici: codice e regole che puoi adattare

Alcuni altri frammenti pratici e modelli di regole che puoi adattare:

  1. Filtro WordPress che nega l'accesso alle pagine delle fatture a meno che non si sia connessi:
// Esempio minimo — inserisci in mu-plugins e testa;
  1. Regola pseudo-regola di rilevamento WAF (concettuale) — blocca i modelli di enumerazione sequenziale:
    • Rileva più richieste agli endpoint delle fatture dallo stesso IP dove l'ID fattura richiesto è in costante aumento.
    • Se > X tali richieste negli ultimi Y secondi, blocca l'IP e avvisa.
  2. Esempio Nginx per rifiutare richieste con parametro invoice_id a meno che non esista un cookie:
map $http_cookie $has_wp_login {

Domande frequenti (FAQ)

D: Ho aggiornato LatePoint. Devo ancora fare qualcosa?
R: Sì. L'aggiornamento è la correzione principale, ma dovresti anche esaminare i log per segni di enumerazione precedente e seguire un breve elenco di controllo per la risposta agli incidenti. Considera di indurire e monitorare per prevenire problemi simili in futuro.

D: Quali dati sono tipicamente esposti tramite una pagina di fattura?
R: Le pagine delle fatture contengono comunemente nomi dei clienti, email, descrizioni dei servizi, importi pagati, ID transazione, date e talvolta indirizzi di fatturazione. Raramente possono contenere informazioni parziali sulla carta di pagamento (ultimi 4 cifre) a seconda dell'integrazione del gateway di pagamento — i numeri di carta completi non dovrebbero mai essere memorizzati.

D: Dovrei notificare i clienti?
R: Se le indagini mostrano che le fatture sono state accessibili, o non puoi determinare l'ambito, coinvolgi il tuo team legale/compliance. Molte giurisdizioni richiedono la notifica di violazione per determinati tipi di dati personali.

D: Un WAF può sostituire l'aggiornamento del plugin?
R: No. Un WAF è un'importante misura temporanea (patch virtuale) che riduce il rischio immediato, ma dovresti comunque applicare la patch del fornitore e verificare i controlli di accesso a livello di applicazione.

Chiusura: priorità pratiche per le prossime 72 ore

  1. Conferma la tua versione di LatePoint. Se <= 5.3.2, preparati ad aggiornare a 5.4.0+.
  2. Se non puoi aggiornare immediatamente, implementa controlli di autenticazione a livello di applicazione per gli endpoint delle fatture o una patch virtuale WAF per bloccare l'accesso non autenticato.
  3. Abilita il logging e cerca modelli che indicano enumerazione (ID sequenziali richiesti dallo stesso IP).
  4. Se rilevi accessi, conserva i log e segui il tuo piano di risposta agli incidenti (contenimento, valutazione, notifica).
  5. Considera di iscriverti a un servizio di firewall gestito che offre patch virtuali istantanee e protezione OWASP se non ne hai già uno.

Riferimenti e risorse

Se vuoi, il nostro team di sicurezza può aiutarti a implementare le regole WAF temporanee, creare il corretto mu-plugin per forzare l'autenticazione e analizzare i log per segni di enumerazione. Proteggere i dati finanziari dei clienti è non negoziabile — agisci rapidamente per ridurre l'esposizione e ripristinare la fiducia dei clienti.

wordpress security update banner

Ricevi WP Security Weekly gratuitamente 👋
Iscriviti ora!!

Iscriviti per ricevere gli aggiornamenti sulla sicurezza di WordPress nella tua casella di posta, ogni settimana.

Non facciamo spam! Leggi il nostro politica sulla riservatezza per maggiori informazioni.

Contattaci per programmare una consulenza gratuita sulla sicurezza di WordPress

Contattaci

WP-Firewall
6/F, I Raggi, 71 Hung To Road, Kwun Tong, Kowloon, Hong Kong

Caratteristiche Prezzi Blog Login
politica sulla riservatezza Termini di servizio Documenti Affiliato

© 2026 WP-Firewall™