In breve: se il Suo server PHP dà problemi e vuole parlare direttamente con un esperto, ci chiami o ci scriva su WhatsApp. È stato colpito? Ci chiami. La aiutiamo. Chiariamo da remoto se dietro ci sia un guasto, un errore di configurazione o un attacco, e ce ne occupiamo dal primo messaggio, fino alla conclusione e alla documentazione dell'incidente.
Ora non cancelli nulla e non reinstalli nulla. Anche un riavvio o un rollback può cancellare tracce. Ci descriva prima ciò che vede. Segnali l'emergenza: poi stabiliremo il passo successivo.
È stato colpito? Questi disservizi sono un caso per noi
Non ogni disservizio è un attacco, ma in questi giorni conviene controllare. Ci contatti se nel Suo sistema PHP si verifica quanto segue:
- I processi PHP o il web server si interrompono, si riavviano di continuo o vengono terminati dal sistema (stato di uscita 137).
- Il carico aumenta senza motivo riconoscibile o la memoria si esaurisce.
- Le pagine restituiscono risposte vuote, errori 500 o messaggi di errore che prima non c'erano.
- Sotto il web server o PHP-FPM girano processi che avviano una shell.
- Nella cartella di upload o di cache ci sono file PHP che non conosce.
- Dopo un aggiornamento di PHP un'applicazione non funziona più.
- Il Suo hoster ha bloccato l'accesso o spento il sito.
La differenza tra guasto e attacco emerge di solito solo nei log. Le prime indicazioni su che cosa conta le descrive l'articolo Il web server avvia una shell.
Che cosa fare subito
- Osservare prima di intervenire. Annoti ora, messaggi di errore e che cosa è stato modificato per ultimo (aggiornamento, plugin, configurazione).
- Salvare i log. Copi altrove i registri di web server, PHP e sistema prima che ruotino. La stampa specializzata consiglia di conservare i log a partire dal 20/10/2026.
- Non riavviare alla cieca. Un riavvio risolve certi guasti, ma distrugge tracce volatili. Riavvii se l'esercizio lo richiede e annoti che cosa ha fatto.
- Valutare la raggiungibilità. Se sospetta un attacco, isolare o spegnere è spesso giusto. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) lo consiglia quando un aggiornamento non è subito possibile.
- Accertare la versione di PHP.
php -vmostra la versione, ma non sempre quella dell'ambiente di esecuzione del web server. - Chiamare o scrivere. Quanto più precisamente riesce a descrivere la situazione, tanto più in fretta arriviamo al nocciolo.
In concreto, come aiuta PHP SOS?
Lavoriamo da remoto, senza trasferte, in tutta la Germania e in Europa.
- Quadro della situazione: nel primo colloquio ascoltiamo e chiediamo in modo mirato: sistemi, modalità di esecuzione di PHP, momento, ultime modifiche. Dopo saprà se vediamo un guasto o il sospetto di un attacco.
- Salvare e chiudere: salviamo lo stato, eliminiamo la causa e, se serve, chiudiamo la vulnerabilità con aggiornamento, riavvio e misure provvisorie.
- Verificare e bonificare: se emerge un'intrusione, rimuoviamo il codice dannoso e controlliamo accessi e segreti. Altrimenti documentiamo la causa e facciamo tornare l'esercizio regolare.
- Rafforzare e riferire: riceve una breve relazione e raccomandazioni perché il disservizio non si ripeta.
Se dietro c'è di più, passiamo all'assistenza urgente per sito web violato o alla Incident response strutturata.
Memoria, interruzioni e il nuovo limite
Dalle release di sicurezza del 21/10/2026 (8.5.12, 8.4.27, 8.3.36, 8.2.35) esiste la direttiva memory_hard_limit_percent. Da allora memory_limit è un limite morbido. Senza impostazione propria, come limite rigido vale il doppio di memory_limit fino a 1G, oltre tale soglia memory_limit più 1G. Se viene superato, il processo termina all'istante con stato di uscita 137. Un esercizio che prima dell'aggiornamento girava al limite può quindi mostrare improvvise interruzioni. Non è un attacco, ma una conseguenza della correzione, e la soluzione è adattare correttamente l'applicazione o il limite, non annullare l'aggiornamento.
Vale anche il contrario: chi vede processi bloccati e non ha ancora applicato la patch non dovrebbe archiviarli come casualità, perché la vulnerabilità CVE-2026-109618 è collegata a una condizione di Out-of-Memory. Se nel Suo caso abbia un ruolo, lo mostrano i log. Approfondimenti sulla gestione della memoria in Out-of-Memory in PHP, possibili segni di intrusione in Processi sospetti sotto Linux.
Se interviene l'hoster
Alcuni fornitori bloccano account o mettono offline i siti in via precauzionale. Ciò non significa automaticamente che sia stato violato, ma può essere la conseguenza di anomalie. Chieda il motivo e il momento, chieda i log e annoti che cosa pretende il fornitore. Ci coordiniamo con il Suo hoster, se lo desidera. È utile chiarire in anticipo chi presso il fornitore può prendere decisioni e se vi siano registri del server che Lei stesso non può consultare. Dati di questo tipo, ad esempio gli accessi a livello di rete, possono diventare decisivi in seguito, quando si tratta di circoscrivere il momento di una possibile intrusione.
Che cosa dovrebbe inviarci
- breve descrizione: che cosa non funziona o è anomalo, da quando?
- tipo di sistema (server proprio, pacchetto di hosting, container) e hoster
- output di
php -v, modalità di esecuzione e web server, per quanto noti - messaggi di errore o estratti dei log
- momento dell'ultimo aggiornamento di PHP e delle ultime modifiche
- persona di riferimento con potere decisionale per i riavvii
Perché PHP SOS
Lavoriamo Made in Germany e da oltre 25 anni, con la nostra rete di partner di professionisti della cybersicurezza, ci specializziamo nella sicurezza informatica. Parla con un interlocutore fisso anziché con un sistema di ticket. Lavoriamo da remoto, documentiamo ciò che vediamo e facciamo, e diciamo apertamente che cosa è provato e che cosa no. Per i casi acuti legati alla vulnerabilità esiste inoltre l'assistenza urgente PHP2Shell.
È stato colpito? Ci chiami. La aiutiamo.
Se il Suo server PHP dà problemi, non aspetti il prossimo guasto. Ci chiami o ci scriva su WhatsApp. Ce ne occupiamo dal primo messaggio. Segnali subito l'emergenza.
Domande frequenti
Il mio server PHP è improvvisamente lento o si blocca: è un attacco?
Non necessariamente. I guasti hanno spesso cause banali, come poca memoria, un aggiornamento difettoso o un sovraccarico. Solo uno sguardo a log e processi mostra se si tratta di un attacco; segnali d'allarme sono ad esempio processi shell sotto il web server o nuovi file PHP sconosciuti.
Che cosa significa lo stato di uscita 137 nei processi PHP?
Lo stato 137 indica un processo terminato all'istante. Secondo il manuale di PHP, un processo termina con 137 quando supera il limite rigido di memoria della nuova direttiva memory_hard_limit_percent; può però anche essere stato terminato dal sistema per mancanza di memoria. La causa si chiarisce guardando i log.
Posso telefonare a un esperto prima di cambiare qualcosa?
Sì, l'assistenza urgente serve proprio a questo. Ci chiami o ci scriva su WhatsApp e descriva ciò che nota. Le diremo che cosa è meglio non fare e che cosa può fare senza rischi.
Devo semplicemente riavviare il servizio PHP?
Un riavvio può risolvere un guasto, ma cancella indizi nella memoria di lavoro. Se un'intrusione è possibile, salvi prima i log e si faccia consigliare. Dopo un aggiornamento di PHP, invece, il riavvio è obbligatorio.
Lavorate anche se il mio server è presso un hoster?
Sì, lavoriamo da remoto con l'accesso che Lei ha e, se serve, ci coordiniamo con il Suo hoster. Quali verifiche siano possibili dipende dai Suoi diritti.