# PHP presso i fornitori cloud e PaaS: chi aggiorna il runtime?

> Aggiornamento di PHP su PaaS e piattaforme cloud: chi aggiorna il runtime PHP, perché spesso serve una nuova build e come documentare lo stato in esecuzione.

Fonte: https://phpsos.de/it/blog/paas-php-laufzeit/  
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:** presso i fornitori cloud e PaaS non è automaticamente il fornitore ad aggiornare. Se gestisce il runtime PHP, lo aggiorna, ma spesso solo con il deployment successivo. Se crea da sé immagini o build, o gestisce la piattaforma in proprio, deve ricostruire e ripubblicare. Conta sempre il runtime che il Suo sito sta servendo in quel momento.

## Aggiornamento di PHP su PaaS: a chi appartiene il runtime?

I servizi di piattaforma, in gergo PaaS (Platform as a Service), tolgono alle aziende la gestione del server. Si carica il codice, la piattaforma lo compila e lo esegue. Con PHP2Shell ne nasce un'incertezza tipica: chi deve in realtà aggiornare PHP?

Vercel lo riassume nel suo bollettino su PHP2Shell: non basta aggiornare l'ambiente di sviluppo locale, il codice dell'applicazione o i plugin. Conta il runtime PHP del deployment che risponde effettivamente alle richieste. Se questo runtime sia aggiornato dipende da chi lo fornisce e da quando è stato compilato l'ultima volta.

## Quattro modelli di esercizio a confronto

Le denominazioni dei fornitori differiscono. Per la questione delle patch, la maggior parte delle offerte si può ricondurre a uno di questi modelli:

| Modello | Chi aggiorna PHP? | Cosa deve fare Lei |
|---|---|---|
| Runtime gestito dal fornitore | Fornitore | Ottenere conferma, se necessario fare un nuovo deploy perché il nuovo runtime sia attivo |
| Runtime basato su build (buildpack) | Il fornitore mette a disposizione la nuova versione, la Sua build la fissa | Avviare una nuova build, verificare la versione nel log della build |
| Immagine container propria | Lei | Ricostruire l'immagine con PHP corretto e ripubblicarla |
| Piattaforma gestita in proprio | Lei, per piattaforma e applicazioni | Aggiornare la piattaforma e ogni applicazione singolarmente |

Molte aziende usano più modelli contemporaneamente, ad esempio un runtime gestito per il sito e container propri per gli strumenti interni. Ogni applicazione ha quindi bisogno di una risposta propria.

Un'insidia si nasconde nella parola «gestito». Anche se il fornitore cura il runtime, un'applicazione già pubblicata continua spesso a girare con lo stato con cui è stata compilata. La nuova versione diventa allora attiva solo con la build o il deployment successivi. Alcune piattaforme mantengono inoltre raggiungibili, con indirizzi propri, vecchi deployment o ambienti di anteprima. Non chieda quindi solo se il fornitore abbia aggiornato, ma anche da quando le Sue istanze in esecuzione usino la patch e cosa succeda ai vecchi deployment.

## Cosa dicono Vercel e Coolify su PHP2Shell

Due fornitori hanno reso pubbliche le loro indicazioni. Sono istruttive perché indicano con chiarezza i limiti delle proprie misure di protezione.

**Vercel**, secondo il proprio bollettino, ha attivato prima della pubblicazione regole di protezione nel suo Web Application Firewall (WAF), un filtro per le richieste web. Valgono automaticamente per le funzioni PHP su Vercel e per le richieste che Vercel inoltra a server PHP esterni. Allo stesso tempo Vercel chiede di aggiornare subito il runtime PHP a una versione corretta. I deployment in container vanno ricostruiti e ripubblicati con un'immagine di base PHP aggiornata. Le richieste che aggirano Vercel e vanno direttamente a un server PHP esterno non sono coperte dal WAF.

**Coolify**, una piattaforma gestibile in proprio, secondo il proprio advisory era essa stessa interessata: tutti i rami della versione 4. Come primi stati corretti Coolify indica 4.0.1, 4.1.3, 4.2.1, 4.3.24 e 4.4.7 e raccomanda la 4.4.7. Importante è l'aggiunta: l'aggiornamento di Coolify non aggiorna le applicazioni PHP che gestisce tramite essa. I loro runtime o le loro immagini vanno aggiornati separatamente e ricostruiti o ripubblicati. Secondo Coolify ciò vale anche per i clienti di Coolify Cloud e anche dietro Cloudflare, perché le regole di Cloudflare verificano solo il traffico che passa attraverso Cloudflare.

Cosa offrano le regole di Cloudflare lo inquadra l'articolo [Regole di protezione Cloudflare contro PHP2Shell](https://phpsos.de/it/blog/cloudflare-waf-php2shell/).

## Come verificare il runtime in esecuzione

I passaggi seguenti funzionano a prescindere dal fornitore. Mirano a una prova, non a una sensazione.

1. **Elencare tutti gli ambienti:** produzione, staging, deployment di anteprima e servizi in background come i queue worker. Ogni ambiente può avere un runtime diverso.
2. **Leggere la versione del runtime per ogni ambiente:** nella console del fornitore, nel log della build o nel file di configurazione del progetto.
3. **Verificare la data dell'ultimo deployment:** se è precedente al 21 ottobre 2026, con alta probabilità gira ancora il vecchio runtime, a meno che il fornitore non confermi espressamente altro.
4. **Controllare nell'istanza in esecuzione:** se la piattaforma offre una console, il comando seguente mostra la versione dell'istanza.
5. **Includere i server PHP esterni:** i server ai quali la piattaforma inoltra le richieste richiedono un aggiornamento proprio e non dovrebbero essere raggiungibili direttamente da Internet.

```bash
# Nella console dell'istanza in esecuzione (se offerta dal fornitore)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
```

Ci si aspetta 8.5.12, 8.4.27, 8.3.36 o 8.2.35 oppure un backport confermato dal fornitore. Tenga presente che la riga di comando di un'istanza non usa sempre lo stesso runtime del processo web. Per la verifica non crei alcun file phpinfo raggiungibile pubblicamente. Come interpretare correttamente numero di versione e stato dei backport lo descrive [Verificare versione e stato della patch di PHP](https://phpsos.de/it/php2shell/php-version-pruefen/).

> **Importante:**
> Un nuovo deployment non elimina il software dannoso entrato prima in archivi persistenti come i volumi di upload o il database. Queste aree le verifichi separatamente.

## Mettere per iscritto la responsabilità

PHP2Shell mostra quanto sia spesso poco chiaro il confine tra piattaforma e cliente. Stabilisca per ogni applicazione chi fornisce il runtime, chi ricostruisce in caso di segnalazioni di sicurezza e come il fornitore annuncia le patch. Ne fa parte anche chi ha accesso alla console della piattaforma quando c'è urgenza e chi può avviare una nuova build fuori dall'orario di lavoro.

Per la documentazione interna basta una breve tabella per applicazione: piattaforma, modello di esercizio, ramo PHP, data dell'ultima build, responsabile. Chi ha questo elenco a portata di mano alla segnalazione successiva risparmia i giorni che molti team hanno speso a cercare dopo il 21 ottobre. Per le applicazioni in container ne fa parte chi cura l'immagine di base; il contesto lo spiega [PHP nei container](https://phpsos.de/it/php/php-in-containern/).

Per i server gestiti senza carattere PaaS valgono domande simili, che abbiamo riassunto in [Server gestiti: chiarire la responsabilità](https://phpsos.de/it/server/managed-server/).

## Come aiuta concretamente PHP SOS?

- **Assegnare:** associamo ciascuna delle Sue applicazioni a un modello di esercizio e chiariamo chi fornisce il runtime PHP.
- **Documentare:** verifichiamo runtime, data della build e deployment per ogni ambiente e documentiamo il risultato.
- **Ricostruire e ripubblicare:** con il [servizio di patch PHP](https://phpsos.de/it/leistungen/php-patch-service/) aggiorniamo immagini e build e le ripubblichiamo in modo controllato.
- **Chiudere le lacune:** verifichiamo se i server PHP esterni siano raggiungibili direttamente e ne limitiamo l'accesso.


## Domande frequenti

**Il mio fornitore PaaS aggiorna PHP automaticamente?**  
Dipende dal modello. Se il fornitore gestisce il runtime, lo aggiorna, ma spesso solo per i nuovi deployment. Se crea da sé immagini o build, deve ricostruire e ripubblicare. Si faccia confermare lo stato per la Sua applicazione.

**Il WAF del mio fornitore di piattaforma basta contro PHP2Shell?**  
No. Vercel e Coolify scrivono espressamente che le regole di protezione non sostituiscono l'aggiornamento del runtime PHP. Inoltre agiscono solo sul traffico che passa attraverso la piattaforma.

**Dopo la patch devo fare un nuovo deploy?**  
Spesso sì. Per i deployment in container Vercel indica la ricostruzione con un'immagine di base PHP aggiornata e un nuovo deployment. Sulle piattaforme basate su build il runtime viene fissato durante la build; solo una nuova build recepisce la patch.

**Uso Coolify. Basta l'aggiornamento di Coolify?**  
No. Secondo l'advisory di Coolify, l'aggiornamento aggiorna solo Coolify stesso. I runtime PHP o le immagini container delle Sue applicazioni vanno aggiornati separatamente e ricostruiti o ripubblicati.

## Fonti

- [Vercel: PHP2Shell Security Bulletin](https://vercel.com/kb/bulletin/php2shell-security-bulletin)
- [Coolify: PHP Security Advisory 2026](https://coolify.io/docs/knowledge-base/php-security-advisory-2026)
- [php.net: segnalazioni di sicurezza](https://www.php.net/)