Il ticket WordPress n. 30465 è stato aperto 10 anni fa: il 2025 sarà l'anno in cui verrà finalmente risolto?

Nel novembre 2014, uno sviluppatore di WordPress di nome Sergej Mueller ha sollevato quella che sembrava una preoccupazione ragionevole: gli utenti non avevano modo di sapere se un plugin che stavano utilizzando era stato rimosso dal repository ufficiale, anche se era stato rimosso per motivi di sicurezza. Il suo ticket – ufficialmente n. 30465 – è stato chiuso relativamente presto, ma senza alcuna risoluzione. Sergej non sapeva che sarebbe stato riaperto quasi dieci anni dopo .

Ed eccoci qui, all'inizio del 2025, con me che scrivo un aggiornamento al riguardo.

Perché?

Per alcuni motivi.

Innanzitutto, è molto rilevante per alcuni eventi di sicurezza dei plugin avvenuti di recente, nell'ottobre dello scorso anno per l'esattezza. Ne parlerò tra breve. E, in secondo luogo, la volontà e lo slancio per risolvere il problema hanno acquisito notevole slancio: l’ultima attività sul ticket è stata meno di un mese fa:

Quindi sembra che la pazienza di Sergej potrebbe finalmente dare i suoi frutti presto...

Cominciamo ripercorrendo lo sviluppo del ticket. Quindi, possiamo passare a ciò che è successo nelle ultime settimane:

Dal "non si risolverà" al salire sul palco del WCEU 2023 🙅‍♂️

Quando il ticket è stato aperto per la prima volta, ha ricevuto alcune risposte ma è stato chiuso abbastanza rapidamente dallo sviluppatore principale di WordPress Andrew Nacin. Lo ha chiuso e lo ha contrassegnato come "non si risolverà", spiegando che la rimozione dei plugin è avvenuta per vari motivi, non solo per problemi di sicurezza:

Successivamente ci fu una raffica di commenti, ma poi si spensero in un commento annuale (a volte anche meno) di qualcuno che tentava di rilanciare la questione.

Poi, nel marzo 2023 , è successo qualcosa di interessante. Joost de Valk, figura molto nota nella community di WordPress, ha riaperto ufficialmente il ticket . La sua tesi era che WordPress ha la responsabilità di dire agli utenti se un plugin è mantenuto o meno.

Ha inoltre sottolineato che WordPress.org mostrava già queste informazioni sulla piattaforma stessa, ma solo dopo un periodo di attesa di 60 giorni. Il suo suggerimento è stato quello di portare la stessa trasparenza nel backend di WordPress dove gli utenti gestiscono effettivamente i propri plugin.

Ciò ha scatenato una nuova ondata di entusiasmo in tutto il thread. Il biglietto è diventato così popolare che Oliver Sild, CEO e co-fondatore di Patchstack, lo ha persino menzionato nel suo discorso al WCEU 2023 :

Non solo ne ha parlato, ma ha incoraggiato i partecipanti al WCEU a lasciare commenti sul thread utilizzando il codice QR personalizzato che ha aggiunto alla sua presentazione. Usò questo plug anche come alley-oop ritardato per un concorso che Patchstack avrebbe ospitato l'anno successivo.

Evento di ottobre 2024 di Patchstack 🪲

Nell'ottobre 2024, Patchstack ha lanciato un evento Bug Bounty come parte del mese della sicurezza informatica. Se la menzione di Oliver del biglietto n. 30465 nel suo discorso al WCEU fosse un alley-oop, allora il risultato di questo evento sarebbe il suo schiacciante.

I ricercatori di sicurezza che hanno partecipato all'evento hanno scoperto l'incredibile cifra di 1.571 rapporti validi sulle vulnerabilità della sicurezza in un solo mese. Anche questi non erano solo problemi minori: stiamo parlando di:

• 73 casi in cui gli aggressori potrebbero caricare file dannosi.
• 67 vulnerabilità SQL injection che potrebbero compromettere interi database.
• 58 modi in cui gli aggressori possono aumentare i propri privilegi.
• 17 vulnerabilità legate all'esecuzione di codice in modalità remota (oddio!)

Le conseguenze hanno portato alla chiusura temporanea di quasi 1.000 plugin. E quando Patchstack ha provato a contattare gli sviluppatori di plugin riguardo a questi problemi, quasi il 74% si è rivelato completamente irraggiungibile. O i loro moduli di contatto non funzionavano, le loro e-mail venivano respinte o i loro domini erano scaduti.

La cosa interessante è che molti di questi plugin vulnerabili sono rimasti nel repository per 6-11 anni. Alcuni risalivano addirittura a 17 anni fa! E sì, ci sono ancora siti Web attivi che dipendono da questi plugin.

Inutile dire che tutti questi dati hanno dato a Oliver la possibilità di portare avanti il ​​ticket n. 30465 verso il completamento. Ne ha approfittato con gioia e ha pubblicato alcuni dettagli due settimane prima della pubblicazione del post ufficiale sul blog Patchstack in cui si discuteva dell'evento:

Dalla discussione all'azione 🛠️

L'attività sul thread stava già crescendo a dismisura quando Oliver ha aggiunto il suo commento, quindi valutarne l'impatto individuale è difficile. Tuttavia, non è irragionevole supporre che abbia aggiunto benzina ad una fiamma crescente. Soprattutto con altri utenti (di cui almeno uno è un dipendente Patchstack) che sostengono apertamente il suo commento.

In risposta, lo sviluppatore principale di WordPress Dion Hulse (@dd32) ha dato qualche opposizione su diversi punti, ma si è anche fatto avanti in modo enorme creando un plugin sperimentale che implementa la funzionalità tanto attesa:

L'implementazione è meravigliosamente semplice: quando un plugin viene chiuso nel repository WordPress.org, gli utenti vedono una notifica chiara ma misurata. Nessun allarme rosso che induca al panico, solo semplici informazioni sullo stato del plugin.

Qualcuno trovi Sergej e gli dica: "mamma, ce l'abbiamo fatta!"

Beh... quasi.

Non fa ancora parte del core di WordPress, ma ho la sensazione che siamo vicini al traguardo qui!

Ora che è stato dimostrato che è possibile, il passo successivo è decidere l'implementazione finale. Quindi può essere integrato nel core di WordPress.

Qual è il prossimo passo? 🎯

Al momento in cui scriviamo, si sta prendendo in considerazione l'inclusione della funzionalità in WordPress 6.8 (secondo Dion Hulse), anche se ci sono ancora alcuni ostacoli da eliminare. Questi includono:

• Finalizzazione dei tempi di notifica (si discute sull'eventuale estensione della finestra di 60 giorni).
• Standardizzazione della documentazione relativa al motivo della chiusura.
• Bilanciare la consapevolezza dell'utente con l'onere del supporto dello sviluppatore.
• Decidere la posizione esatta (la schermata di integrità del sito o direttamente sul plug-in, come mostrato nello screenshot di esempio del plug-in).

Il quadro generale 🌐

L’evoluzione del ticket WordPress n. 30465 ci dice qualcosa di affascinante su come è cambiata la sicurezza di WordPress negli ultimi dieci anni. Ciò che una volta veniva considerato un caso limite, è diventato sempre più critico man mano che l’ecosistema è cresciuto e le sfide alla sicurezza si sono moltiplicate.

Anche se ci sono voluti dieci anni per arrivare fin qui, il plugin sperimentale suggerisce che ci stiamo finalmente avvicinando a una soluzione che bilancia la consapevolezza della sicurezza con l'esperienza dell'utente. Con milioni di installazioni WordPress potenzialmente interessate da plugin vulnerabili, questa funzionalità non arriverà mai abbastanza presto.

Se vuoi seguire lo sviluppo, dai un'occhiata al plugin sperimentale su GitHub o tieni d'occhio il ticket n. 30465. Questo potrebbe essere uno di quei rari momenti in cui possiamo assistere alla trasformazione di una conversazione decennale in un risultato tangibile. 💡

Cosa ne pensi di questa funzionalità? Pensi che sarebbe utile per te come utente WordPress essere informato che un plugin è stato chiuso? Fatemelo sapere nei commenti. Ci vediamo lì.