Il web poggia su PHP. La fondazione che lo sostiene ha un solo dipendente full-time

La PHP Foundation ha un solo dipendente full-time. È Elizabeth Barron, la direttrice esecutiva. Attorno a lei lavorano 14 contractor, in gran parte part-time, mentre il consiglio di amministrazione è composto da volontari non retribuiti. La fotografia arriva da un’intervista rilasciata a Reuters pochi giorni dopo che due vulnerabilità critiche di PHP hanno costretto organizzazioni pubbliche e private a correre per installare le patch.

È una struttura piccola per qualsiasi progetto software. Diventa meno intuitiva quando si guarda dall’altra parte: secondo W3Techs, PHP è utilizzato dal 69,3% dei siti per i quali è possibile identificare il linguaggio server. WordPress, a sua volta, dipende da PHP. Una quantità considerevole di amministrazione pubblica, commercio elettronico, editoria e piccoli siti aziendali continua quindi a poggiare su un linguaggio nato nel 1995 e su un ecosistema di manutenzione molto meno monumentale del web che gli sta sopra.

Barron l’ha sintetizzato senza bisogno di formule elaborate: «Given that reliance, it is clear that PHP is incredibly under-funded». Il problema si è materializzato questa settimana, quando la sicurezza di una parte enorme del web è diventata improvvisamente un lavoro urgente.

PHP Foundation: un solo dipendente full-time dietro un’infrastruttura enorme

La PHP Foundation non è “PHP” e non controlla da sola il linguaggio. PHP è un progetto open source con una comunità, maintainer, contributor e sviluppatori che operano anche fuori dalla fondazione. La Foundation finanzia però una parte importante del lavoro sul core, della manutenzione e della sicurezza, e negli ultimi anni è diventata uno dei meccanismi attraverso cui attività difficili da sostenere soltanto con il volontariato possono essere pagate.

Nel rapporto di trasparenza relativo al 2025 la fondazione dichiarava 536 sponsor e contributori individuali e 730.534 dollari di contributi complessivi. Alla fine di quell’anno sosteneva undici sviluppatori a contratto, oltre alla direzione esecutiva e a un consiglio volontario. Nel secondo trimestre del 2026 il core team era salito a tredici persone distribuite in otto Paesi; la maggior parte dei contractor lavorava part-time.

Non è una storia sulla povertà romantica dell’open source. È un problema di proporzioni. Le aziende possono costruire servizi, negozi, CMS e infrastrutture commerciali su componenti aperti senza che il valore economico generato sopra di essi si trasformi automaticamente in risorse per chi mantiene il livello sottostante. Finché il software funziona, quella distanza rimane quasi invisibile.

Due falle critiche hanno mostrato quanto lavoro resta umano

Il 21 ottobre il progetto PHP ha pubblicato aggiornamenti di sicurezza per correggere due vulnerabilità critiche capaci, in determinate condizioni, di consentire l’esecuzione remota di codice senza autenticazione. La PHP Foundation ha ricostruito pubblicamente il percorso che ha portato alle patch: una delle cause profonde era stata osservata già nel 2024, ma inizialmente non era stato dimostrato un vettore d’attacco concreto sufficiente a trasformarla nella priorità che sarebbe diventata due anni dopo.

Nel 2026 sono arrivati nuovi report da Calif, OpenAI, Wiz e altri ricercatori. Alcuni strumenti di intelligenza artificiale hanno contribuito a trovare o verificare percorsi di exploit che avevano resistito per anni. La Foundation usa anche strumenti AI per validare segnalazioni e raggruppare report riconducibili alla stessa causa.

Il risultato, però, non è una sicurezza automatizzata. La stessa Foundation scrive che dal primo luglio il team ha pubblicato 15 CVE e ha lavorato su più di cento segnalazioni risultate poi invalide, duplicate o non riproducibili. Gli strumenti producono più segnali; qualcuno deve ancora distinguere una vulnerabilità reale da una pista sbagliata, capire l’impatto di una modifica sul motore e decidere come correggere un comportamento senza rompere software che esiste da decenni.

È un caso concreto della trasformazione che sta investendo la cybersecurity. Anche il Cyber Resilience Act europeo parte da un presupposto simile: le vulnerabilità devono essere gestite più rapidamente e con responsabilità più chiare. Ma aumentare la velocità con cui i difetti vengono scoperti non moltiplica automaticamente gli ingegneri in grado di correggerli.

L’AI raddoppia le proposte di codice, non i maintainer

Barron ha raccontato a Reuters l’altra faccia dell’AI applicata allo sviluppo. PHP sta ricevendo quasi il doppio delle modifiche proposte rispetto a un anno fa, mentre il numero dei contributor non è raddoppiato. La generazione di codice accelera l’ingresso; la revisione rimane un collo di bottiglia.

È una distinzione poco spettacolare e proprio per questo utile. I modelli possono scrivere patch, suggerire correzioni, trovare pattern sospetti e produrre test. La manutenzione di un linguaggio che deve restare compatibile con milioni di installazioni richiede però memoria storica, conoscenza del codice, comprensione degli effetti laterali e responsabilità sulla decisione finale. La Foundation lo scrive in modo esplicito: ogni decisione sulle segnalazioni e ogni patch passa ancora da una persona.

Nel caso delle vulnerabilità di ottobre, la Foundation afferma che senza il proprio finanziamento non sarebbe stato possibile avere più persone impegnate a tempo pieno sul problema, anche nei fine settimana e attorno all’orologio, coordinando ricercatori e soggetti esterni.

Dopo trent’anni, PHP continua a essere abbastanza vecchio da sembrare infrastruttura e abbastanza invisibile da essere trattato come software gratuito che in qualche modo continuerà a mantenersi. Nel 2025, la fondazione che ne finanzia una parte sostanziale dello sviluppo core ha raccolto 730.534 dollari. Nel 2026, la sua direttrice ha dovuto ricordare al mercato quante persone ci sono dall’altra parte della patch.