# Misure immediate se non può ancora applicare la patch

> Workaround per la vulnerabilità PHP2Shell: le misure provvisorie di php.net, impostate correttamente, con i loro limiti e indicazioni per arrivare alla patch.

Fonte: https://phpsos.de/it/php2shell/sofortmassnahmen-ohne-patch/  
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:** un workaround per la vulnerabilità di sicurezza PHP2Shell può ridurre il rischio, ma non sostituisce l'aggiornamento. php.net indica a tal fine limiti fissi di memoria e di upload, la disattivazione di session upload progress e, con PHP 8.5, `fatal_error_backtraces=0`. Se anche questo non è possibile a breve, il BSI raccomanda di scollegare temporaneamente dalla rete il web server.

## Che cosa può fare un workaround e che cosa no

Le misure provvisorie di php.net servono a rendere più difficili le condizioni in cui le vulnerabilità CVE-2026-109618 e CVE-2026-109619 sono sfruttabili. Sono esplicitamente **una protezione non completa**. Le vulnerabilità sono corrette solo in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 oppure in un backport confermato dal Suo fornitore.

Le misure sono sensate quando l'aggiornamento non è possibile per un motivo concreto: una finestra di manutenzione è ancora da fissare, un'applicazione deve prima essere testata, oppure gestisce PHP 8.1 o precedente, per cui non esiste più un aggiornamento ufficiale. Sono allora un ponte, non un traguardo.

Pianifichi quindi insieme al workaround anche l'aggiornamento: chi lo attua, in quale finestra di manutenzione e chi verifica poi che tutti i worker siano stati riavviati? Una fase transitoria senza data di fine rischia di diventare una condizione permanente.

## Opzione 1: scollegare temporaneamente il server dalla rete

Il BSI ha dichiarato il livello di allerta 3 (arancione) e raccomanda di scollegare temporaneamente dalla rete i web server interessati, se l'aggiornamento non è subito possibile. Alcuni fornitori lo hanno fatto per precauzione; ciò non significa che quei siti siano stati hackerati.

Per molte imprese l'indisponibilità dello shop o del portale è costosa. Può essere sensata una valutazione: accesso solo tramite VPN o indirizzi IP abilitati, una pagina di manutenzione statica al posto dell'applicazione PHP o la disattivazione di singoli siti web non necessari sul server. Quanto meno PHP è raggiungibile dall'esterno, tanto più piccola è la superficie di attacco.

È importante prendere la decisione in modo consapevole e annotarla: chi ha deciso, e quando, di lasciare il server online, e con quali misure di protezione? Questo aiuta in seguito nei confronti di assicuratore, protezione dei dati e direzione.

## Le misure provvisorie di php.net

| Misura | Valore | Nota |
|---|---|---|
| `memory_limit` | `-1`, non sovrascrivibile | impostare poi il limite di memoria tramite container o cgroup |
| `post_max_size` | `8M` senza upload, `32M` con upload | `upload_max_filesize` inferiore |
| Limite di memoria | tramite container/cgroup | non tramite `RLIMIT_AS` o `RLIMIT_DATA` |
| `session.upload_progress.enabled` | `0` | in php.ini, pool o configurazione del server, non tramite `ini_set()` o `.user.ini` |
| `fatal_error_backtraces` | `0` | solo PHP 8.5 |

L'impostazione `session.upload_progress.enabled=0` è al tempo stesso il rimedio per la vulnerabilità segnalata il 23 ottobre, [CVE-2026-115560](https://phpsos.de/it/php2shell/cve-2026-115560/).

## Impostare correttamente il workaround per la vulnerabilità PHP

Decisivo è il luogo. I valori devono essere impostati in modo che un'applicazione non possa sovrascriverli. Percorsi e nomi dei servizi variano a seconda della distribuzione; gli esempi presuppongono PHP 8.3.

**PHP-FPM, nel pool** (ad es. `/etc/php/8.3/fpm/pool.d/www.conf`):

```ini
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; solo PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
```

**Apache con mod_php,** nella configurazione del server o nel VirtualHost:

```apache
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
```

**Limite di memoria tramite cgroup,** qui con systemd per il servizio FPM. Il valore lo adatti al Suo server:

```ini
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
```

Poi riavviare tutti i worker, altrimenti nulla di tutto ciò ha effetto: `systemctl restart php8.3-fpm` oppure, con mod_php, Apache. Come verificare che non giri più alcun vecchio processo è spiegato alla pagina [Riavviare PHP-FPM e tutti i worker](https://phpsos.de/it/php2shell/php-fpm-neustart/). L'hardening generale della configurazione è descritto alla pagina [Configurare php.ini in modo sicuro](https://phpsos.de/it/ratgeber/php-ini-sicher-konfigurieren/).

> **Importante:**
> Dopo il passaggio testi upload e moduli grandi. Un `post_max_size` troppo ridotto può bloccare ordini, moduli di candidatura o upload di contenuti multimediali. È un motivo per non rimandare a lungo l'aggiornamento.

## Livelli di protezione aggiuntivi

Una Web Application Firewall o il virtual patching possono aiutare come livello ulteriore. Cloudflare ha distribuito regole di protezione, ma avverte essa stessa che le regole basate sui soli dati della richiesta non bastano. Una WAF è quindi un complemento, non un sostituto. Maggiori informazioni alla pagina [WAF e virtual patching](https://phpsos.de/it/leistungen/waf-virtuelles-patching/).

Salvi inoltre i log del server a partire dal 20 ottobre. Secondo i resoconti dei media, un primo tentativo di attacco è stato osservato già il 17 ottobre; i log sono la base se in seguito dovrà chiarire se prima della patch sia successo qualcosa.

## Come aiuta concretamente PHP SOS?

- **Chiarire la situazione:** verifichiamo se un aggiornamento sia possibile a breve o se serva una fase transitoria, e discutiamo con Lei l'opzione di scollegare dalla rete alcune parti.
- **Impostare le misure:** inseriamo i valori di php.net nel punto giusto, impostiamo il limite cgroup e riavviamo tutti i worker.
- **Testare il funzionamento:** dopo il passaggio verifichiamo moduli, upload e processi d'ordine.
- **Portare alla patch:** con il [servizio di patch PHP](https://phpsos.de/it/leistungen/php-patch-service/) pianifichiamo l'aggiornamento e poi ritiriamo in modo controllato i valori transitori dove disturbano.


## Domande frequenti

**Il workaround protegge completamente da PHP2Shell?**  
No. php.net definisce esplicitamente le misure come transitorie e non come protezione completa. Riducono il rischio finché l'aggiornamento non è installato. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda di scollegare temporaneamente dalla rete i server senza patch.

**Posso impostare i valori tramite .htaccess o .user.ini?**  
Per session.upload_progress.enabled php.net esclude esplicitamente ini_set() e .user.ini. Anche per memory_limit vale: il valore deve essere impostato in modo che l'applicazione non possa sovrascriverlo. Ci si riesce in php.ini, nel pool FPM con php_admin_value o nella configurazione del server Apache.

**Una Web Application Firewall basta come workaround?**  
Come livello aggiuntivo può aiutare. Cloudflare ha distribuito regole di protezione, ma fa notare essa stessa che le regole basate sui soli dati della richiesta non bastano. Una WAF non sostituisce né l'aggiornamento né le misure provvisorie sul server.

**Che cosa faccio se ho solo hosting condiviso?**  
In tal caso php.ini e riavvio sono in mano all'hoster. Chieda in modo concreto se l'aggiornamento sia stato installato o le misure provvisorie siano state impostate e se tutti i processi PHP siano stati riavviati.

## Fonti

- [php.net: bollettini di sicurezza](https://www.php.net/)
- [BSI: Ufficio federale tedesco per la sicurezza informatica](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
