Un lavoratore IT ingaggiato per la manutenzione di un sito ne ha deturpato le pagine e lo ha reso irraggiungibile all’azienda che lo aveva assunto. Il caso sta nell’avviso congiunto del 18 settembre 2026 firmato da polizia nazionale giapponese, ufficio giapponese per la cibersicurezza, FBI, DC3, ACSC australiano e servizi tedeschi BND e BfV, nella sezione sui lavoratori IT nordcoreani che si fanno assumere come freelance. Nessuno zero-day, nessun plugin bucato: l’accesso era stato dato per contratto.

Le contromisure che quell’avviso indica a chi commissiona lavoro stanno in due righe: limitare codice sorgente, credenziali e diritti di accesso al minimo necessario, e revocare prontamente account e sessioni quando un fornitore risulta sospetto (il caso di fine rapporto lo aggiungo io: vale lo stesso). Su WordPress diventano tre gesti precisi, e il terzo quasi nessuno lo fa per intero. Il lato macchina, cioè dove eseguire il codice di uno sconosciuto, l’ho trattato in VM o macchina di lavoro per il codice di terzi; qui si parla di chi ha le chiavi del tuo sito.

Un utente per persona, ruolo minimo

L’account condiviso admin con la password girata su WhatsApp è ancora la norma nelle PMI, e rende impossibili entrambe le contromisure: non puoi togliere l’accesso a una persona sola, e nel registro delle modifiche resta un nome che non corrisponde a nessuno. Crea un utente per ogni collaboratore, con la sua email vera, e assegnagli il ruolo più basso che gli permette di lavorare: Editore per chi scrive e pubblica, Autore per chi tocca solo i propri contenuti. Amministratore serve a chi installa plugin o modifica il tema, e va su un utente dedicato, non sul tuo. Stessa regola fuori da WordPress: un accesso SFTP per persona, mai la credenziale unica del pannello hosting. Un utente in più costa zero minuti, un accesso che non sai chiudere costa il sito.

Una Application Password per ogni strumento

Gli strumenti non devono usare la password dell’account: né lo script di deploy, né il plugin SaaS che sincronizza il catalogo, né l’agente AI che legge le bozze. Dal 5.6 WordPress ha le Application Password: dal profilo utente ne generi una per strumento, con un nome che dice a cosa serve, e la revochi singolarmente senza toccare il resto. Funzionano solo per la REST API in Basic Auth e per XML-RPC; sulla schermata di login non funzionano affatto, ed è una scelta di progetto, non un limite. Per questo sono la credenziale giusta da consegnare a un fornitore esterno che deve far parlare un servizio con il tuo sito: una stringa che non apre wp-admin, che ha un nome nel profilo, e che spegni in un clic il giorno che il progetto chiude. Se il servizio sta su un server di terzi, vale la stessa logica del proxy davanti alla chiave API.

La revoca in cinque passaggi

Quando un collaboratore esce, in quest’ordine:

  1. Cancella l’utente e riassegna i contenuti a un account interno. Eliminare l’utente porta via anche le sue Application Password, che stanno nella usermeta _application_passwords.
  2. Se l’utente deve restare, apri il suo profilo e usa Revoca tutte le password delle applicazioni: un clic chiude tutte le sue Application Password in una volta. Quello che il core non offre è il giro su più utenti insieme, quindi i profili si aprono uno per uno.
  3. Ruota le credenziali che ha visto e che non sono sue: SFTP, database, chiavi dei servizi collegati, accesso al pannello hosting.
  4. Rigenera le chiavi di sicurezza in wp-config.php. Invalida tutte le sessioni con cookie, comprese le tue: avvisa il team prima, perché uscite tutti insieme.
  5. Rileggi la lista utenti e la sezione Application Password di ogni amministratore rimasto. L’account dimenticato è il residuo classico e non si vede finché non lo cerchi.

L’errore da evitare

«Ho cambiato la password, siamo a posto» è la frase che lascia la porta aperta. In WordPress cambiare la password non revoca le Application Password di quell’utente: wp_set_password() riscrive l’hash in wp_users e azzera la chiave di attivazione, e non tocca la usermeta dove stanno le credenziali applicative. Ogni stringa emessa prima continua ad autenticare chiamate REST dopo il cambio, e il pannello non ti avvisa di niente. Lo stesso vale fuori dal CMS: la password nuova di WordPress non chiude una chiave SSH sull’hosting, né un token che il collaboratore aveva salvato nel suo file di ambiente. La take è questa, e non è prudenza generica: un accesso esterno è un affitto con una data di scadenza, non un regalo. Metti la data nel contratto e in agenda, e tieni scritta la lista degli strumenti a cui hai dato una credenziale. La revoca si fa in dieci minuti solo se sai cosa revocare; senza quella lista si fa in tre giorni, e male. Se accetti segnalazioni dall’esterno, il complemento è il security.txt sul sito.

Fonti: NPA, NCO, FBI, DC3, ASD ACSC, BND, BfV, «North Korean WaterPlum Cyber Actor Group Targeting IT Professionals; Activities of North Korean IT Workers in Japan, the United States and Europe», 18 settembre 2026; documentazione WordPress su ruoli e capacità; guida core alle Application Password; Tom’s Hardware, 20 settembre 2026.