# Il repository sury.org: pacchetti PHP da una fonte di terze parti

> Il repository PHP sury per Debian e Ubuntu: chi lo cura, cosa lo distingue da Debian, come verificare lo stato di PHP2Shell e quando diventa un rischio.

Fonte: https://phpsos.de/it/blog/sury-repository-php/  
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:** il repository PHP sury è una fonte di terze parti molto diffusa per pacchetti PHP su Debian (packages.sury.org) e Ubuntu (PPA ondrej/php). Consente più versioni di PHP in parallelo e rami più recenti rispetto alla distribuzione. Dopo PHP2Shell sono state rese disponibili lì, secondo i rapporti, build per tutti i rami da 5.6 a 8.5. La prova per il Suo server la forniscono però solo lo stato del pacchetto e il changelog, non le segnalazioni di sicurezza di Debian o Ubuntu.

## Che cos'è il repository sury

Dietro sury.org c'è Ondřej Surý. Secondo la pagina del suo progetto, come sviluppatore Debian pacchettizza dai tempi di PHP 5 i pacchetti PHP per Debian, e i pacchetti PHP ufficiali di Debian e Ubuntu si basano sul suo lavoro. Accanto a questo lavoro gestisce un repository proprio con pacchetti PHP che si possono installare in parallelo.

Per Debian il repository si trova su packages.sury.org, per Ubuntu è offerto come PPA `ondrej/php`. Gli errori, secondo la pagina del progetto, si segnalano tramite un issue tracker su Codeberg, non via e-mail. La cura avviene, per sua stessa dichiarazione, prevalentemente nel tempo libero; per le versioni più vecchie delle distribuzioni esiste un'offerta commerciale tramite Freexian.

Molti admin e hoster usano il repository perché offre rami PHP più recenti di quelli forniti dalla distribuzione, o perché le applicazioni richiedono una versione specifica.

## Cosa lo distingue dai pacchetti Debian

La differenza più importante per la sicurezza: i pacchetti di sury.org non rientrano nelle segnalazioni di sicurezza di Debian o Ubuntu. Il Debian Security Tracker mostra solo lo stato dei pacchetti ufficiali. Se vi si legge che php8.4 in trixie è corretto, ciò non dice nulla su un php8.4 di sury.org sullo stesso server.

| Caratteristica | Pacchetti ufficiali Debian e Ubuntu | sury.org |
|---|---|---|
| Editore | Debian o Canonical | Ondřej Surý come singola persona |
| Segnalazioni di sicurezza | DSA, DLA, USN | nessuna di queste segnalazioni |
| Versioni | un ramo per rilascio | più rami in parallelo |
| Numero di versione dopo il fix | Debian in parte nuova versione upstream, Ubuntu di solito vecchio numero con nuovo stato del pacchetto | di norma versione upstream attuale |
| Prova | segnalazione e changelog | changelog e versione del pacchetto |

Per le aziende significa una dipendenza da una singola persona per un componente centrale. Non è un motivo per evitare il repository, ma per assumersene consapevolmente la responsabilità: con monitoraggio, prova e un piano B.

## Il repository PHP sury dopo PHP2Shell: verificare lo stato

Per prima cosa chiarisca se e per quali pacchetti il server usa sury. I comandi sono di sola lettura.

```bash
# sury è registrato come fonte dei pacchetti?
grep -rEl "sury|ondrej" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

# Da quale fonte proviene il pacchetto installato?
apt policy php8.3-fpm

# Versione installata e voce del changelog sui CVE
dpkg-query -W -f='${Package}\t${Version}\n' 'php*-fpm' 'libapache2-mod-php*' 2>/dev/null
zgrep -E "CVE-2026-10961[89]" /usr/share/doc/php8.3-fpm/changelog.Debian.gz
```

Con i rami attuali riconosce il fix di norma dalla versione upstream 8.5.12, 8.4.27, 8.3.36 o 8.2.35 nel nome del pacchetto. Con i rami vecchi come 7.4 o 8.1 non esiste una versione di destinazione ufficiale, lì la voce del changelog è la prova più importante. Se manca, chieda tramite l'issue tracker del progetto o tratti il pacchetto come non chiarito.

## Rami PHP vecchi da sury: una comodità ingannevole

Il repository rende facile gestire PHP 7.4 o persino 5.6 su un Debian attuale. Secondo i rapporti esistevano build contro PHP2Shell anche per questi rami. È utile per la situazione acuta, ma sposta soltanto il problema di fondo: il progetto PHP non cura più questi rami, e la prossima vulnerabilità li colpirà di nuovo.

Chi in questo modo tiene in vita una vecchia applicazione dovrebbe chiedersi onestamente per quanto ancora. Cosa valga per PHP 8.1 e precedenti lo riassume la pagina [PHP 8.1 e precedenti: cosa vale ora](https://phpsos.de/it/php2shell/php-8-1-und-aelter/). Le alternative commerciali con i loro limiti le descrive l'articolo [Supporto a lungo termine per vecchie versioni di PHP](https://phpsos.de/it/blog/langzeitsupport-alte-php-versionen/).

> **Importante:**
> Non mescoli su un server, in modo incontrollato, pacchetti PHP della distribuzione e di sury.org. Le dipendenze tra estensioni e librerie possono portare, al prossimo aggiornamento, a cambi di pacchetto inattesi.

## Raccomandazioni per l'esercizio con sury

1. **Documentare** quali server usano sury e per quali rami.
2. **Stabilire l'origine**, ad esempio con l'APT pinning, perché i pacchetti PHP provengano da una sola fonte.
3. **Monitorare gli aggiornamenti**, perché senza DSA o USN manca la consueta segnalazione. Aiuta un confronto regolare di `apt list --upgradable`.
4. **Riavviare** dopo ogni aggiornamento, per ogni versione installata singolarmente. Quante ne girino in parallelo lo mostra l'articolo [Più versioni di PHP su un server](https://phpsos.de/it/blog/mehrere-php-versionen-server/).
5. **Sostenere**, se la Sua azienda dipende dal repository. La pagina del progetto indica donazioni e supporto commerciale come vie possibili.

## Tornare ai pacchetti della distribuzione?

Non ogni server che oggi usa sury ne ha ancora bisogno. Spesso il repository è stato inserito anni fa, perché la distribuzione di allora portava con sé solo una versione di PHP più vecchia. Nel frattempo, ad esempio, Debian 13 trixie fornisce PHP 8.4, che secondo il Debian Security Tracker è corretto contro PHP2Shell. Se la Sua applicazione gira con questa versione, il ritorno può porre fine alla dipendenza da una fonte di terze parti.

Il ritorno è un piccolo progetto di migrazione. Verifichi prima quali estensioni servano all'applicazione e se la distribuzione le offra. Testi l'applicazione con il pacchetto della distribuzione su una copia, prima di rimuovere la fonte sury. Poi le segnalazioni di sicurezza tornano per le vie consuete, e la prova si basa su DSA o USN anziché solo su un changelog.

Dove resta necessaria una versione più recente o più vecchia di quella della distribuzione, sury è ancora una scelta sensata. Allora la decisione dovrebbe però essere presa consapevolmente e documentata.

## Come aiuta concretamente PHP SOS?

- Accertiamo quali pacchetti PHP sui Suoi server provengono da sury.org, dalla distribuzione o da altre fonti.
- Verifichiamo lo stato di PHP2Shell per ramo tramite versione del pacchetto e changelog e riavviamo tutti i servizi.
- Configuriamo pinning e monitoraggio degli aggiornamenti e rimuoviamo i rami non più necessari nell'ambito dell'[hardening del server](https://phpsos.de/it/leistungen/server-haertung/).
- Per i rami vecchi pianifichiamo il passaggio a una versione supportata.


## Domande frequenti

**Il repository sury è un repository ufficiale di Debian?**  
No. È gestito da Ondřej Surý che, secondo il suo sito, come sviluppatore Debian pacchettizza da tempo PHP per Debian. Non è però l'archivio di sicurezza di Debian, e per i suoi pacchetti non esistono segnalazioni di sicurezza di Debian.

**sury.org ha messo a disposizione pacchetti contro PHP2Shell?**  
Secondo i rapporti sono stati resi disponibili build per tutti i rami da 5.6 a 8.5. Verifichi comunque personalmente lo stato sul Suo server tramite versione del pacchetto e changelog, perché i rapporti non sostituiscono una prova per il Suo sistema.

**sury.org rende di nuovo sicure le vecchie versioni di PHP?**  
Una build per un ramo vecchio può chiudere una vulnerabilità concreta. Non cambia il fatto che il progetto PHP non curi più questi rami. Per un esercizio sicuro nel lungo periodo resta necessario il passaggio a una versione supportata.

**Come scopro se il mio server usa sury?**  
Cerchi nelle fonti dei pacchetti sotto /etc/apt la voce sury o ondrej e verifichi con apt policy da quale fonte provengono i pacchetti PHP installati.

## Fonti

- [DEB.SURY.ORG](https://deb.sury.org/)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [php.net: versioni supportate](https://www.php.net/supported-versions.php)