# Come il progetto PHP gestisce le vulnerabilità di sicurezza

> Come il progetto PHP gestisce le vulnerabilità: segnalazione tramite GitHub o security@php.net, classificazione, correzione nel rilascio e cosa ne ricavano i gestori.

Fonte: https://phpsos.de/it/php/php-sicherheitsprozess/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** le vulnerabilità di PHP vengono segnalate in modo riservato, di preferenza tramite il modulo Advisory privato nel repository GitHub `php/php-src`, in alternativa a security@php.net. Gli sviluppatori di PHP classificano il caso come alto, medio o basso; gli errori gravi vengono corretti in un repository di sicurezza separato e pubblicati solo con il rilascio, insieme a un GitHub Security Advisory e di solito a un numero CVE. Con PHP2Shell questa procedura si è svolta a ritmo serrato: preavviso il 20/10/2026, patch il 21/10/2026, avvertenza integrativa il 23/10/2026.

## Chi si occupa della sicurezza in PHP?

PHP è un progetto open source. La politica di sicurezza nel wiki lo descrive come un progetto di volontari senza budget per i compensi. Per ogni versione ci sono dei release manager che rispondono delle pubblicazioni. A ciò si aggiunge la PHP Foundation, che secondo la propria descrizione incarica un team di sviluppatori a tempo parziale e a tempo pieno che lavora su manutenzione, sicurezza e nuove funzioni di PHP.

Per le aziende significa: non esiste un produttore con contratto, hotline o tempi di reazione garantiti. Chi ha bisogno di impegni vincolanti li ottiene dalla propria distribuzione Linux, dal proprio hoster o da un fornitore di supporto a lungo termine, non dal progetto PHP stesso. Questa catena di fornitura è bene conoscerla.

## Come si segnala una vulnerabilità

Il percorso è descritto nella politica di sicurezza su GitHub:

1. **Segnalare:** tramite il modulo privato per i Security Advisory nel repository `php/php-src`. Chi non può usarlo o vuole discutere un tema che non è una segnalazione di errore scrive a security@php.net.
2. **Descrivere in breve:** si desidera un breve esempio che mostri l'errore, non una lunga relazione sulle possibili conseguenze. Così il team può esaminare più in fretta.
3. **Riservatezza:** la segnalazione resta privata fino alla pubblicazione.
4. **Menzione:** chi segnala viene citato come collaboratore secondo il sistema di credit di MITRE.

La pagina più vecchia del wiki cita inoltre il classico tracker degli errori con il tipo «Security». Oggi è determinante il percorso tramite GitHub.

## Che cosa il progetto PHP classifica come vulnerabilità

Non ogni arresto anomalo è una vulnerabilità. Il wiki indica quattro criteri: un errore consente azioni non autorizzate, supera confini di sicurezza, apre l'accesso a dati altrui oppure compromette gravemente disponibilità o prestazioni. La classificazione avviene su tre livelli:

| Livello | Significato secondo la politica | Numero CVE |
|---|---|---|
| Alto | terzi possono compromettere la maggior parte delle installazioni, eseguire codice o leggere file | di regola sì |
| Medio | effetto simile, ma solo in condizioni più rare, ad esempio un'estensione o una configurazione rara | per lo più sì |
| Basso | teoricamente possibile, in pratica sfruttabile con grande difficoltà | per lo più no |

Altrettanto istruttivo è l'elenco di ciò che espressamente non è una vulnerabilità: codice dannoso eseguito intenzionalmente, aggiramenti di `open_basedir` e `disable_functions`, input dannosi passati a `unserialize()`, l'uso di FFI e una normale interruzione per memoria in cui interviene `memory_limit` e termina solo la richiesta corrente. Per i gestori significa: [disable_functions](https://phpsos.de/it/ratgeber/disable-functions/) è un utile rafforzamento, ma non una muraglia protettiva.

## Dalla correzione alla pubblicazione

Le correzioni per le vulnerabilità di livello alto e medio vengono inserite, secondo il wiki, in un repository di sicurezza separato prima che venga creato il rilascio. Gli errori classificati come bassi seguono il percorso delle normali correzioni. La vulnerabilità viene pubblicata secondo il principio della divulgazione responsabile: prima la correzione, poi i dettagli. I rilasci escono, secondo il wiki, di solito di giovedì, spesso nell'ambito delle regolari pubblicazioni mensili.

Con il rilascio esce un GitHub Security Advisory con identificativo proprio (GHSA) e livello di gravità. Nel repository, ad esempio, il 24/09/2026 sono usciti diversi advisory su stream wrapper, FastCGI e filtri con gravità da bassa ad alta. I pacchetti sorgente su php.net sono offerti con checksum SHA-256 e firme GPG dei release manager; i tag Git sono firmati. Quali rami di versione ricevano ancora correzioni di sicurezza lo mostra la pagina sulle [versioni di PHP e il ciclo di rilascio](https://phpsos.de/it/php/release-zyklus/).

## PHP2Shell come esempio del caso grave

PHP2Shell mostra come la procedura si svolga sotto pressione:

- **20/10/2026:** php.net annuncia un rilascio di sicurezza critico per il 21/10/2026 alle 14:00 UTC e si riserva di pubblicare prima, se i dettagli diventassero pubblici o comparissero attacchi. Secondo diversi resoconti i dettagli erano effettivamente diventati noti prima della scadenza del termine di embargo; i retroscena li illumina [Perché la vulnerabilità di PHP era nota prima della patch](https://phpsos.de/it/blog/php-luecke-vorzeitig-bekannt/).
- **21/10/2026:** escono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, insieme agli advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) e GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), entrambi classificati come critici. Secondo php.net le distribuzioni Linux e i fornitori di supporto a lungo termine avevano ricevuto in anticipo le correzioni. Per 7.4, 8.0 e 8.1 esistono backport minimi.
- **23/10/2026:** un'avvertenza informativa su CVE-2026-115560 raccomanda `session.upload_progress.enabled=0`; l'advisory completo seguirà con il prossimo rilascio.

## Che cosa ne ricavano i gestori

1. **Abbonarsi alle fonti:** php.net, gli advisory GitHub di `php/php-src` e i bollettini di sicurezza della Sua distribuzione.
2. **Conoscere la catena di fornitura:** chi fornisce il Suo pacchetto PHP, e con che rapidità vi arrivano i backport?
3. **Pianificare la finestra temporale:** i rilasci critici possono uscire al di fuori del ritmo abituale; una finestra di patch deve essere possibile in tempi brevi.
4. **Prevedere il riavvio:** un aggiornamento ha effetto solo quando tutti i processi PHP sono stati riavviati.
5. **Mettere al sicuro la prova:** documentare versione, stato del pacchetto e momento.

## Come aiuta concretamente PHP SOS?

Con il [servizio di patch PHP](https://phpsos.de/it/leistungen/php-patch-service/) ci occupiamo della parte che spetta a Lei:

- **Seguire le segnalazioni:** osserviamo php.net, gli advisory e i bollettini delle distribuzioni e valutiamo se i Suoi sistemi siano interessati.
- **Attuare la patch:** aggiornamento dalla fonte adatta, riavvio di tutti i processi, controllo della versione in esecuzione.
- **Mettere in sicurezza la transizione:** dove l'aggiornamento si blocca, attuiamo le misure transitorie ufficiali.
- **Documentare:** riceve una prova con versioni, stati dei pacchetti e momenti.


## Domande frequenti

**Come si segnala una vulnerabilità in PHP?**  
Di preferenza tramite il modulo di segnalazione privato per i Security Advisory nel repository GitHub php/php-src. Chi non può usarlo scrive a security@php.net. La segnalazione resta riservata fino alla pubblicazione.

**Il progetto PHP paga un compenso per le vulnerabilità trovate?**  
No. Secondo la politica di sicurezza PHP è un progetto di volontari senza fondi per i bug bounty. Chi segnala viene però citato come collaboratore.

**Aggirare disable_functions è una vulnerabilità di sicurezza?**  
Secondo la politica del progetto PHP no. Gli aggiramenti di open_basedir e disable_functions non sono considerati un problema di sicurezza di PHP. Le impostazioni sono rafforzamento, ma non un confine di sicurezza affidabile.

**Dove vengo a sapere delle nuove vulnerabilità di PHP?**  
Nella home page di php.net con le comunicazioni sui rilasci e nei Security Advisory del repository GitHub php/php-src. Chi ottiene PHP dalla distribuzione segue inoltre i suoi bollettini di sicurezza.

**Perché PHP2Shell è stata pubblicata di mercoledì?**  
Secondo il wiki i rilasci escono di solito di giovedì. Per PHP2Shell php.net ha annunciato il 20/10/2026 un rilascio di sicurezza per mercoledì 21/10/2026, ore 14:00 UTC, riservandosi di pubblicare prima se i dettagli fossero diventati pubblici.

## Fonti

- [php-src: Security Policy e Advisory (GitHub)](https://github.com/php/php-src/security)
- [PHP Wiki: politica di sicurezza](https://wiki.php.net/security)
- [php.net: comunicazioni dal 20 al 23/10/2026](https://www.php.net/)
- [php.net: versioni supportate](https://www.php.net/supported-versions.php)