Glossario: PHP e sicurezza IT

125 termini tecnici in parole semplici, ciascuno con rinvio alla pagina di approfondimento corrispondente.

#A B C D E F G H I J L M N O P R S T U V W X Z

#

2FA: La 2FA (autenticazione a due fattori) richiede, al momento dell'accesso, oltre alla password una seconda prova, ad esempio un codice da un'app o una chiave di sicurezza. Una password rubata da sola non basta più. Per tutti gli accessi admin a CMS, pannello di hosting e server la 2FA dovrebbe essere lo standard. Impostare l'autenticazione a due fattori per gli accessi admin →

A

Analisi forense: L'analisi forense IT esamina con metodo, dopo un incidente, che cosa è successo: come è entrato l'aggressore, che cosa ha fatto e quali dati sono coinvolti. Si basa su copie protette di supporti di memoria, memoria di lavoro e log. I risultati sono importanti per obblighi di notifica, assicurazione e denuncia. Analisi forense IT dopo un attacco a un web server →
Apache: L'Apache HTTP Server è uno dei server web più vecchi e diffusi. PHP vi gira o come modulo (mod_php) o tramite PHP-FPM con FastCGI. Con i file .htaccess la configurazione si può adattare directory per directory. Mettere in sicurezza Apache con mod_php →
Assicurazione cyber: Un'assicurazione cyber copre, a seconda del contratto, i costi dopo un attacco, ad esempio per analisi forense, ripristino o interruzione dell'attività. Molti contratti prevedono obblighi come aggiornamenti tempestivi e immediata denuncia del sinistro. Che cosa valga nel singolo caso lo chiarisca con il Suo assicuratore. Assicurazione cyber: cosa conta in caso di sinistro →

B

Backdoor: Una backdoor (porta di servizio nascosta) è un accesso occulto attraverso cui gli aggressori possono rientrare dopo un'intrusione. Può essere un file, un account admin, un cronjob o una chiave SSH. Per questo ogni bonifica comprende la ricerca di tutti i tipi di accesso, non solo dei file. Trovare backdoor in WordPress: individuarle in modo sistematico →
Backport: Un backport trasferisce una correzione di sicurezza in una versione più vecchia di un programma, senza passare alla versione nuova. Le distribuzioni Linux e gli hoster lo fanno spesso; il numero di versione visualizzato resta allora lo stesso. Se un backport sia stato applicato lo documentano il changelog del pacchetto e la conferma del fornitore, non il numero. Aggiornamento PHP o backport? La scelta per i sistemi legacy →
Backup 3-2-1: La regola 3-2-1 raccomanda tre copie dei dati su due supporti diversi, di cui una in un altro luogo. Almeno una copia dovrebbe essere non modificabile dal server, affinché gli aggressori non possano cancellarla o cifrarla. Un backup conta solo quando il ripristino è stato testato. Strategia di backup per server: backup secondo la regola 3-2-1 →
Brute force: In un attacco brute force l'aggressore prova in modo automatizzato molte password per un account. Il bersaglio sono spesso gli accessi admin di CMS, SSH o FTP. La protezione è offerta da password robuste, autenticazione a due fattori e blocchi automatici come Fail2ban. Proteggere i login admin dal brute force: protezione brute force per ogni login →
BSI: Il BSI (Bundesamt für Sicherheit in der Informationstechnik, l'Ufficio federale tedesco per la sicurezza informatica) è l'autorità federale tedesca per la cybersicurezza. Pubblica avvisi, raccomandazioni e standard come l'IT-Grundschutz. Per PHP2Shell il BSI ha dichiarato il livello di allerta 3 (arancione) e raccomandato l'aggiornamento immediato. Che cosa raccomanda il BSI su PHP2Shell →

C

CDN: Un CDN (Content Delivery Network) distribuisce i contenuti tramite molti server dislocati e si trova quindi davanti al sito web vero e proprio. Molti CDN offrono inoltre regole WAF, ad esempio Cloudflare contro PHP2Shell. La protezione vale solo per il traffico che passa dal CDN e non sostituisce un aggiornamento di PHP. Regole di protezione Cloudflare contro PHP2Shell: cosa fanno e cosa no →
CERT-Bund: CERT-Bund è il Computer Emergency Response Team dell'amministrazione federale tedesca, presso il BSI. Pubblica servizi di allerta e informazione sulle vulnerabilità e avvisa i gestori di rete dei sistemi vulnerabili. CERT-Bund ha lanciato un'allerta anche su PHP2Shell. Cosa consigliano CERT-EU e CERT-Bund su PHP2Shell →
CERT-EU: CERT-EU è il team di cybersicurezza per le istituzioni, gli organismi e le agenzie dell'Unione europea. Secondo i resoconti, CERT-EU ritiene possibile che con PHP2Shell siano interessate le versioni a partire da PHP 5. Raccomanda di isolare le applicazioni raggiungibili pubblicamente se non possono essere aggiornate in tempi brevi. Cosa consigliano CERT-EU e CERT-Bund su PHP2Shell →
CGI: CGI (Common Gateway Interface) è una vecchia interfaccia in cui il server web avvia un programma esterno per ogni richiesta e ne restituisce l'output. È semplice ma lenta e per PHP è stata in gran parte sostituita da FastCGI. Vecchie configurazioni CGI si trovano ancora su alcuni sistemi di hosting e Windows. CGI e FastCGI: le basi →
cgroups: I cgroups (control groups) sono una funzione del kernel Linux con cui si possono limitare memoria, CPU e altre risorse per gruppi di processi. Container e systemd li usano, ad esempio con MemoryMax. Come misura provvisoria contro PHP2Shell php.net raccomanda un limite di memoria tramite container o cgroup, anziché tramite RLIMIT_AS o RLIMIT_DATA. Impostare limiti di memoria con systemd e cgroup →
Chain of custody: La chain of custody (catena di custodia) documenta senza lacune chi ha acquisito, consegnato ed elaborato un elemento di prova, e quando. Integrata da checksum, dimostra che i dati non sono stati modificati. Senza questa documentazione le tracce perdono valore in tribunale o nei confronti degli assicuratori. Analisi forense IT dopo un attacco a un web server →
Changelog: Un changelog elenca le modifiche di una versione di programma o di pacchetto, per le correzioni di sicurezza di solito con il numero CVE. Su Debian e Ubuntu apt-get changelog mostra il changelog del pacchetto, nella famiglia RHEL rpm -q --changelog. Così un backport si può documentare anche a parità di numero di versione. Dimostrare i numeri CVE nel changelog del pacchetto →
Ciclo di rilascio: Ogni versione di PHP riceve dapprima correzioni di bug e poi, per un certo periodo, solo correzioni di sicurezza. Quando termina ciascuna versione lo pubblica il progetto PHP su php.net, tra le versioni supportate. Secondo php.net PHP 8.2 raggiunge la fine del supporto il 31/12/2026. Versioni di PHP e ciclo di rilascio →
CLI: CLI (Command Line Interface) è PHP da riga di comando, ad esempio per cronjob, comandi di console dei CMS e Composer. Il PHP della CLI può essere una versione diversa da quella che serve le pagine web. Il comando php -v mostra quindi solo la versione della riga di comando; entrambi i percorsi devono essere aggiornati. PHP dalla riga di comando (CLI) →
CloudLinux: CloudLinux è una distribuzione Linux per l'hosting condiviso che separa i clienti in ambienti limitati. Con alt-php mette a disposizione affiancate molte versioni di PHP, anche vecchie. Ognuna di queste versioni deve essere aggiornata singolarmente. CloudLinux e alt-php: cosa devono sapere i clienti dell'hosting →
Command injection: Nella command injection l'input arriva senza controlli in un comando di sistema che l'applicazione esegue. L'aggressore può così avviare comandi propri con i privilegi del server web. La protezione consiste nel rinunciare, dove possibile, alle chiamate alla shell e nel fare un escaping sistematico con escapeshellarg(). Prevenire la command injection in PHP →
Composer: Composer è il gestore di pacchetti di PHP. Installa le librerie secondo quanto indicato in composer.json e registra le versioni esatte in composer.lock. Con composer audit si possono verificare i pacchetti installati alla ricerca di vulnerabilità note; le vulnerabilità di PHP stesso il comando non le trova. Composer: il gestore di pacchetti per PHP →
Conservazione delle prove: La conservazione delle prove significa preservare le tracce di un incidente prima che vadano perse con la bonifica, il riavvio o la reinstallazione. Ne fanno parte file di log, immagini dei supporti di memoria e, a seconda del caso, la memoria di lavoro. Dopo PHP2Shell la stampa specializzata consiglia di conservare i log del server dal 20/10/2026. Conservare le prove prima di reinstallare il server →
Container: Un container è un ambiente di esecuzione isolato che avvia un'applicazione con tutte le dipendenze a partire da un'immagine, ad esempio con Docker. Il PHP nel container proviene dall'immagine, non dal sistema ospite. Un aggiornamento sull'host quindi non lo aggiorna; l'immagine va ricostruita e il container riavviato. Gestire PHP nei container →
cPanel: cPanel è un pannello di gestione per il web hosting, con WHM come interfaccia per l'amministratore del server. Le versioni di PHP vi sono di solito fornite tramite pacchetti propri (EasyApache). Quali build siano aggiornate lo confermano lo stato dei pacchetti e l'hoster. cPanel e WHM: mettere in sicurezza PHP →
Credential stuffing: Nel credential stuffing gli aggressori provano su altri servizi credenziali provenienti da precedenti fughe di dati. Funziona perché molte persone usano più volte la stessa password. La protezione è offerta da password uniche per ogni servizio e dall'autenticazione a due fattori. Impostare l'autenticazione a due fattori per gli accessi admin →
Cryptominer: Un cryptominer è un malware che calcola criptovaluta su server altrui. Segni tipici sono un carico di CPU costantemente alto e processi sconosciuti. Un miner indica che un aggressore può eseguire codice; il server andrebbe quindi considerato compromesso. Cryptominer sul server web: segni e come procedere →
CSP: CSP (Content Security Policy) è un header che stabilisce da quali fonti una pagina può caricare script, immagini e altri contenuti. Rende più difficili XSS e l'introduzione di script estranei, ad esempio nello skimming. Una CSP rigorosa va testata con cura affinché il sito web continui a funzionare. Security header per i siti web: impostare correttamente gli header di sicurezza →
CSRF: CSRF (Cross-Site Request Forgery) induce il browser di un utente autenticato a eseguire involontariamente un'azione su un altro sito web. Sono tipiche le modifiche nelle aree di amministrazione. La protezione è offerta da token casuali nei moduli e da cookie con attributo SameSite. Protezione CSRF nelle applicazioni PHP →
CVE: CVE (Common Vulnerabilities and Exposures) è un elenco usato in tutto il mondo che assegna un numero univoco a ogni vulnerabilità di sicurezza nota, ad esempio CVE-2026-109618. Il numero rende confrontabili i bollettini di produttori, autorità e distribuzioni. Tramite il numero CVE si può anche verificare nel changelog del pacchetto se una correzione è stata applicata. Dimostrare i numeri CVE nel changelog del pacchetto →
CVSS: CVSS (Common Vulnerability Scoring System) valuta la gravità di una vulnerabilità su una scala da 0 a 10. La valutazione considera, ad esempio, se un attacco è possibile via rete e senza autenticazione. Le vulnerabilità PHP2Shell hanno CVSS v4.0 9,2 ciascuna; il valore da solo non dice nulla sul rischio concreto nel Suo ambiente.

D

DDoS: Un attacco DDoS (Distributed Denial of Service) sovraccarica un servizio con richieste provenienti da molte fonti, finché non è più raggiungibile. In genere i dati non vengono sottratti. Un DDoS va distinto da un exploit, che sfrutta in modo mirato una vulnerabilità. DDoS o attacco hacker? Come inquadrare correttamente gli attacchi →
Defacement: Nel defacement gli aggressori modificano in modo visibile la home page o i contenuti di un sito web, ad esempio con messaggi o immagini. È vistoso, ma spesso è solo il segno visibile di un'intrusione più profonda. Fino a chiarimento, il sito web andrebbe trattato come compromesso. Sito web hackerato, cosa fare? Assistenza urgente da remoto →
Deserializzazione: La deserializzazione riconverte in oggetti dati salvati, in PHP ad esempio con unserialize(). Se i dati provengono dagli utenti, gli aggressori possono costruire oggetti in modo che al caricamento venga eseguito codice indesiderato. Per i dati degli utenti JSON è la scelta più sicura. Deserializzazione non sicura in PHP: unserialize e sicurezza →
disable_functions: disable_functions è un'impostazione di php.ini con cui si disattivano singole funzioni PHP, tipicamente quelle per l'esecuzione di comandi di sistema. Si può impostare solo nel php.ini, non nel codice dell'applicazione. Rende la vita più difficile agli aggressori, ma non sostituisce né gli aggiornamenti né permessi corretti. Usare correttamente PHP disable_functions →
display_errors: display_errors stabilisce se PHP mostra i messaggi di errore direttamente nel browser. In produzione il valore va impostato su Off e gli errori vengono invece scritti in un registro con log_errors. I messaggi visibili rivelerebbero altrimenti percorsi, versioni e frammenti di codice. display_errors off: disattivare l'output degli errori in produzione →
DPA (art. 28 GDPR): Un contratto di trattamento dei dati (in tedesco AVV, Auftragsverarbeitungsvertrag) ai sensi dell'art. 28 GDPR è necessario quando un fornitore tratta dati personali per conto del cliente o può accedervi. Spesso vale anche per hoster, agenzie e fornitori IT con accesso al server. Il contratto disciplina, tra l'altro, istruzioni, misure di protezione e canali di notifica. Trattamento dei dati per conto terzi quando i fornitori accedono ai server →

E

EDR: EDR (Endpoint Detection and Response) è un software su server e postazioni di lavoro che osserva processi, accessi ai file e connessioni di rete e segnala o ferma comportamenti sospetti. Sui server web può riconoscere, ad esempio, che PHP-FPM avvia una shell. Poiché per PHP2Shell non esistono IOC confermati, questa analisi del comportamento è particolarmente importante. Segnale d'allarme: il server web avvia una shell →
Embargo: Un embargo è il termine concordato entro cui i dettagli di una vulnerabilità restano riservati finché non sono pronte le patch. In questo modo produttori e distribuzioni possono preparare gli aggiornamenti. Per PHP2Shell, secondo diversi resoconti, i dettagli sono diventati pubblici prima della scadenza dell'embargo; php.net ha quindi annunciato le patch il 20/10/2026. Perché la vulnerabilità PHP è diventata nota prima della patch →
End of Life: End of Life (EOL) significa che una versione di software non riceve più aggiornamenti dal produttore, nemmeno correzioni di sicurezza. PHP 8.1 e precedenti non ricevono più aggiornamenti ufficiali dal progetto PHP; per 7.4, 8.0 e 8.1 esistono solo backport minimi del codice sorgente. I sistemi con software EOL richiedono un piano di aggiornamento. PHP end of life: rischi delle versioni obsolete →
Exploit: Un exploit è codice o una procedura che sfrutta concretamente una specifica vulnerabilità. Quando esce una patch, gli aggressori possono analizzarla e ricavarne exploit. Per questo, dopo la pubblicazione di una patch, il tempo che precede gli attacchi spesso si accorcia sensibilmente. La finestra di tempo tra patch e attacco →
expose_php: expose_php controlla se PHP rivela la propria versione nell'header HTTP X-Powered-By. In produzione l'impostazione dovrebbe essere su Off, così gli aggressori non vedono subito quale versione di PHP è in esecuzione. È una protezione delle informazioni, non un sostituto dell'aggiornamento. expose_php e header Server: nascondere le indicazioni di versione →
Extension: Un'estensione (extension) arricchisce PHP di funzioni, ad esempio per database, immagini o crittografia. Le estensioni girano nello stesso processo di PHP e hanno gli stessi privilegi. Disattivare le estensioni non necessarie riduce la superficie di attacco. Capire le estensioni PHP (extension) →

F

Fail2ban: Fail2ban legge i file di log e blocca temporaneamente nel firewall gli indirizzi IP dopo ripetuti tentativi falliti. Ambiti d'uso tipici sono SSH, posta e accessi admin dei siti web. Contro attacchi distribuiti da molti indirizzi aiuta solo in misura limitata. Configurare Fail2ban per i server web →
FastCGI: FastCGI è un protocollo con cui un server web inoltra le richieste a processi che restano in esecuzione in modo continuativo, ad esempio PHP-FPM. A differenza del CGI classico, non viene avviato un nuovo processo per ogni richiesta. Poiché i processi gestiscono più richieste una dopo l'altra, dopo gli aggiornamenti è importante un riavvio pulito. CGI e FastCGI: le basi →
FrankenPHP: FrankenPHP è un moderno application server per PHP basato sul server web Caddy. PHP vi è incorporato direttamente e, in modalità worker, l'applicazione resta in memoria tra una richiesta e l'altra. Secondo il team PHP, FrankenPHP rientra tra le modalità di esecuzione interessate; dopo l'aggiornamento il server deve essere riavviato con il nuovo PHP. Mettere in sicurezza FrankenPHP →

G

GDPR art. 33: L'art. 33 GDPR obbliga i titolari del trattamento a notificare all'autorità di controllo competente, se possibile entro 72 ore dalla presa di conoscenza, una violazione della protezione dei dati personali. L'obbligo viene meno solo se è improbabile che la violazione comporti un rischio per gli interessati. Nel singolo caso consigliano i responsabili della protezione dei dati o gli avvocati. Obbligo di notifica GDPR: 72 ore dall'incidente →
GDPR art. 34: L'art. 34 GDPR disciplina la comunicazione agli interessati stessi. È necessaria quando una violazione dei dati è suscettibile di comportare un rischio elevato per i loro diritti e libertà. Se ciò ricorra, andrebbe valutato con i responsabili della protezione dei dati o con gli avvocati. Obbligo di notifica GDPR: 72 ore dall'incidente →
GHSA: GHSA è l'identificativo di una GitHub Security Advisory, cioè di un bollettino di sicurezza nel database di GitHub. Molti progetti open source, anche PHP, pubblicano lì i loro bollettini oltre al numero CVE. Per PHP2Shell sono GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp.

H

Hardening: Hardening significa configurare un sistema in modo che offra la minor superficie di attacco possibile: solo i servizi necessari, privilegi ridotti, impostazioni predefinite sicure. Nei server PHP ne fanno parte, ad esempio, pool separati, funzioni bloccate e nessuna esecuzione di PHP nelle cartelle di upload. L'hardening limita i danni ma non sostituisce gli aggiornamenti. Hardening del server per web server PHP →
Header di sicurezza: Gli header di sicurezza sono intestazioni di risposta HTTP che impongono al browser regole di protezione, ad esempio Content-Security-Policy, Strict-Transport-Security o X-Content-Type-Options. Proteggono i visitatori da determinati attacchi nel browser. Contro le vulnerabilità sul server come PHP2Shell non servono. Security header per i siti web: impostare correttamente gli header di sicurezza →
Hosting condiviso: Nell'hosting condiviso (shared hosting) molti clienti si dividono un server gestito dall'hoster. L'hoster è responsabile di PHP, sistema operativo e server web, il cliente della propria applicazione. Con PHP2Shell significa: chiedere all'hoster lo stato della patch e verificare sul proprio sito web la presenza di tracce. Shared hosting: che cosa fa l'hoster e che cosa deve fare Lei →
HSTS: HSTS (HTTP Strict Transport Security) è un header con cui un sito web comunica al browser di essere raggiungibile, per un certo periodo, solo tramite HTTPS. Impedisce che le connessioni vengano riportate al HTTP non cifrato. Prima di attivarlo, HTTPS dovrebbe funzionare in modo affidabile su tutti i domini interessati. Security header per i siti web: impostare correttamente gli header di sicurezza →
.htaccess: I file .htaccess sono file di configurazione per singola directory per Apache e server compatibili come LiteSpeed. I CMS li usano per reindirizzamenti e protezione degli accessi, gli aggressori per reindirizzamenti nascosti. Nginx non valuta .htaccess; le regole di protezione devono quindi andare nella configurazione del server. Configurare Apache per PHP in sicurezza →

I

Image digest: Un image digest è un valore hash (sha256) che identifica in modo univoco il contenuto di un'immagine di container. A differenza di un tag come php:8.3-fpm, che può essere spostato su nuove build, un digest non cambia mai. Chi fissa le immagini tramite digest deve aggiornarlo consapevolmente dopo un aggiornamento di sicurezza. Immagini Docker ufficiali di PHP: tag, digest e ricostruzione →
Incident response: L'incident response è la gestione ordinata di un incidente di sicurezza: riconoscere, contenere, preservare le tracce, bonificare, ripristinare e fare il punto a posteriori. Una procedura definita impedisce che nella fretta si distruggano prove o si trascurino backdoor. Sono importanti responsabilità chiare e una documentazione senza lacune. Incident response per attacchi ai server →
ini_set(): ini_set() è una funzione PHP con cui uno script modifica impostazioni durante l'esecuzione. Che cosa uno script possa modificare dipende dalla modalità di modifica dell'impostazione. Poiché anche il codice dannoso può richiamare ini_set(), le impostazioni di protezione vanno nella configurazione del server o del pool, non nel codice dell'applicazione. Il php.ini spiegato: struttura, livelli e precedenza →
IOC: Gli IOC (Indicator of Compromise) sono tracce concrete di un attacco, ad esempio nomi di file, valori hash, indirizzi IP o domini. Con essi si possono verificare in modo mirato i sistemi rispetto a un attacco noto. Per PHP2Shell non esistono IOC pubblicati e confermati; il rilevamento si basa sull'analisi del comportamento. Sono già stato compromesso? Segni dopo PHP2Shell →
ISO 27001: ISO/IEC 27001 è lo standard internazionale per i sistemi di gestione della sicurezza delle informazioni (ISMS). Richiede una gestione ordinata di rischi, misure e miglioramenti, compresa la gestione di vulnerabilità e incidenti. Le imprese possono farsi certificare secondo questo standard. ISO 27001 e TISAX: che cosa riguarda i server web →
IT-Grundschutz: L'IT-Grundschutz del BSI è una metodologia con moduli e requisiti per la sicurezza delle informazioni in imprese e amministrazioni. Esistono moduli specifici, ad esempio per server web e applicazioni web. Può essere usato come base per un ISMS o per una certificazione. Benchmark CIS e moduli BSI per i server web →

J

JIT: JIT (Just-in-Time compiler) traduce in codice macchina, durante l'esecuzione, il codice PHP eseguito più spesso. È arrivato con PHP 8.0 ed è parte di OPcache. Per i siti web tipici il vantaggio in termini di prestazioni è di solito modesto, per i compiti ad alto carico di calcolo è maggiore. JIT e prestazioni in PHP 8 →

L

Least privilege: Least privilege (principio del privilegio minimo) significa che ogni utente e ogni processo riceve solo i privilegi di cui ha realmente bisogno. Se PHP gira con privilegi ridotti, dopo un'intrusione un aggressore può fare meno danni. Riguarda utenti di sistema, permessi dei file, account di database e accessi admin. Least Privilege: i permessi dell'utente del server web →
Lessons learned: Lessons learned è l'analisi a posteriori di un incidente: che cosa è successo, che cosa ha funzionato, che cosa deve cambiare? L'obiettivo sono misure concrete con responsabili e scadenze, non attribuzioni di colpa. I risultati confluiscono in piano di emergenza, processo di patch e formazione. Lessons learned: migliorare dopo l'incidente →
LFI: LFI (Local File Inclusion) si verifica quando un'applicazione include un file locale il cui percorso può essere influenzato dall'aggressore. Così si possono leggere file di configurazione o, in certe circostanze, eseguire codice introdotto. La protezione è offerta da elenchi di consentiti fissi al posto di nomi di file tratti dall'input dell'utente. Prevenire la local file inclusion in PHP: LFI e RFI →
Linea temporale: Una linea temporale (timeline) ordina cronologicamente tutte le tracce di un incidente: voci di log, modifiche ai file, accessi, processi. Mostra quando è iniziato l'attacco e che cosa è successo, in quale ordine. È importante un fuso orario uniforme, meglio se UTC. Costruire la cronologia di un incidente →
LiteSpeed: LiteSpeed è un server web in gran parte compatibile con le configurazioni di Apache come .htaccess e che collega PHP tramite la propria interfaccia LSAPI. È diffuso tra gli hoster; OpenLiteSpeed è la variante libera. Secondo il team PHP, LiteSpeed rientra tra le modalità di esecuzione interessate da PHP2Shell. LiteSpeed e LSAPI: aggiornare PHP →
Livello di allerta: Nei bollettini di sicurezza il BSI classifica la situazione di minaccia in livelli, contrassegnati anche con colori. Il livello 3 (arancione) indica una situazione critica per l'attività, con possibile grave compromissione dell'operatività ordinaria. Per PHP2Shell vale il livello di allerta 3 / arancione. Allerta arancione del BSI: cosa significa la classificazione →

M

memory_limit: memory_limit limita la quantità di memoria che un singolo script PHP può occupare; il valore predefinito è 128 MB. Quando il limite viene raggiunto, PHP si interrompe con un errore di esaurimento della memoria. Contro CVE-2026-109618 php.net consiglia in via provvisoria memory_limit=-1, impostato in modo fisso, e un limite di memoria tramite container o cgroup. Impostare correttamente memory_limit →
mod_php: mod_php è il modulo PHP per il server web Apache. PHP gira direttamente nel processo di Apache e di solito con i suoi privilegi. Il team PHP classifica il rischio di PHP2Shell come il più alto proprio per mod_php: è stato dimostrato un exploit prima ancora che venga eseguito il codice dell'applicazione. mod_php spiegato: PHP nel processo Apache →
ModSecurity: ModSecurity è una WAF open source molto diffusa che gira come modulo in Apache, Nginx o altri server web. Valuta le richieste in base a regole e può registrarle o bloccarle. Di norma si usa insieme all'OWASP Core Rule Set. Usare ModSecurity e OWASP Core Rule Set →
Monitoraggio: Il monitoraggio è la sorveglianza continua dei sistemi, ad esempio raggiungibilità, carico, file di log e modifiche ai file. Il monitoraggio di sicurezza cerca in modo mirato anomalie come nuovi file PHP o shell avviate dal server web. Serve solo se qualcuno valuta le segnalazioni in tempi rapidi. Security monitoring per web server →

N

Nginx: Nginx è un server web e reverse proxy diffuso. Non esegue PHP da sé, ma inoltra le richieste a PHP-FPM tramite FastCGI. È importante una configurazione che passi a PHP solo file PHP autentici ed escluda le cartelle di upload. Mettere in sicurezza Nginx con PHP-FPM →
NIS2: NIS2 è una direttiva dell'UE che stabilisce, per molte imprese e organizzazioni, obblighi di gestione del rischio e di notifica degli incidenti di sicurezza. Riguarda molti più settori e dimensioni aziendali della disciplina precedente. Se la Sua azienda sia interessata va chiarito in base al recepimento nazionale e con una consulenza legale. NIS2 e sicurezza dei web server →

O

OPcache: OPcache è la cache di bytecode fornita con PHP. Conserva nella memoria condivisa il codice già tradotto, così i file PHP non vengono ricompilati a ogni richiesta. Dopo un aggiornamento o una bonifica la cache va svuotata o PHP riavviato, altrimenti può continuare a girare codice vecchio. OPcache spiegata: la cache di bytecode di PHP →
open_basedir: open_basedir limita le directory a cui gli script PHP possono accedere con le funzioni sui file. Sui server con più siti web impedisce che un sito legga semplicemente i file di un altro. Non è un isolamento completo; servono anche utenti di sistema e pool FPM separati. open_basedir e isolamento per sito →
Out of Memory: Out of Memory indica la condizione in cui un programma non ottiene altra memoria e deve interrompersi. In PHP accade quando si supera memory_limit. Con CVE-2026-109618 un'interruzione di questo tipo può fermare PHP mentre i dati della richiesta sono inizializzati solo in parte. memory_limit e Out-of-Memory: che cosa accade all'interno →
OWASP CRS: L'OWASP Core Rule Set (CRS) è un insieme di regole liberamente disponibile per ModSecurity e WAF compatibili. Riconosce classi di attacco tipiche come SQL injection o command injection. Le regole vanno adattate all'applicazione, altrimenti bloccano anche richieste legittime. Usare ModSecurity e OWASP Core Rule Set →
OWASP Top 10: L'OWASP Top 10 è un elenco, aggiornato periodicamente, dei rischi principali per le applicazioni web, pubblicato dalla OWASP Foundation, organizzazione senza scopo di lucro. Serve da base per sviluppo, verifiche e formazione. In aggiunta OWASP offre i Cheat Sheet con contromisure concrete.

P

Patch: Una patch è una correzione del produttore che chiude una vulnerabilità nel codice del programma. Ha effetto solo quando è installata e tutti i processi in esecuzione sono stati riavviati. Una patch non rimuove il malware già introdotto e non dimostra che prima non sia successo nulla. Servizio patch PHP: aggiornamento installato, con riavvio e prova →
PECL: PECL (PHP Extension Community Library) è il repository delle estensioni PHP scritte in C e non comprese nella dotazione standard. Tali estensioni devono corrispondere alla versione di PHP installata. Dopo un cambio della versione principale di PHP spesso vanno ricompilate o sostituite. Capire le estensioni PHP (extension) →
PHP: PHP è un linguaggio di scripting che gira soprattutto sui server web, dove genera le pagine. Molti CMS e sistemi di shop diffusi come WordPress, TYPO3 o Shopware sono scritti in PHP. Una vulnerabilità nell'interprete PHP riguarda quindi tutte le applicazioni che ne dipendono, a prescindere dal loro stato di aggiornamento. Cos'è PHP? Il linguaggio di programmazione spiegato →
php-cgi: php-cgi è il programma PHP per l'esecuzione tramite CGI o FastCGI. Secondo il team PHP rientra tra le modalità di esecuzione interessate da PHP2Shell. Dove php-cgi è ancora in uso, vale la pena verificare se sia possibile passare a PHP-FPM. php-cgi: un'eredità del passato a rischio →
PHP-FPM: PHP-FPM (FastCGI Process Manager) è un servizio autonomo che gestisce i processi PHP in pool e accetta le richieste del server web tramite FastCGI. Oggi è la modalità di esecuzione abituale con Nginx e su molti server Apache. Dopo un aggiornamento di PHP, PHP-FPM va riavviato perché non continuino a girare processi vecchi. PHP-FPM spiegato: gestore di processi, pool e worker →
php.ini: Il php.ini è il file di configurazione centrale di PHP. Definisce limiti e impostazioni di sicurezza e di errore, ad esempio memory_limit o display_errors. Spesso esiste un php.ini distinto per ogni SAPI (FPM, CLI, Apache) e va gestito separatamente. Il php.ini spiegato: struttura, livelli e precedenza →
PHP2Shell: PHP2Shell è il nome di due vulnerabilità critiche in PHP stesso, CVE-2026-109618 e CVE-2026-109619, ciascuna con CVSS v4.0 9,2. Consentono l'esecuzione di codice dannoso da remoto senza autenticazione. Sono corrette in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, pubblicate il 21/10/2026. Che cos'è PHP2Shell? La vulnerabilità spiegata in modo semplice →
php_admin_value: php_admin_value imposta un'impostazione PHP nel pool FPM o nella configurazione di Apache in modo che le applicazioni non possano sovrascriverla con ini_set() o .htaccess. Per gli interruttori esiste php_admin_flag. php.net raccomanda questa via per le misure provvisorie contro PHP2Shell, ad esempio per memory_limit. php_admin_value: bloccare le impostazioni contro la sovrascrittura →
Piano di emergenza: Un piano di emergenza IT stabilisce chi fa che cosa in caso di incidente: contatti, percorsi decisionali, primi passi, ripartenza. Deve essere disponibile anche offline, nel caso i sistemi si fermino. Esercitazioni periodiche mostrano se funziona nel caso reale. Creare un piano di emergenza IT per i web server →
Plesk: Plesk è un pannello di gestione diffuso per server web, con cui si impostano domini, versioni di PHP e handler per ogni sito web. Include pacchetti PHP propri, ma può anche usare i pacchetti PHP della distribuzione. Con i backport Plesk può continuare a mostrare un numero più vecchio come 8.2.34 anche se il sistema è aggiornato. Server Plesk: verificare e aggiornare le versioni di PHP →
Pool FPM: Un pool è un gruppo di processi PHP-FPM con configurazione propria, socket proprio e, idealmente, un utente di sistema proprio. Un pool separato per ogni sito web tiene i siti isolati l'uno dall'altro, così un'intrusione in un sito non raggiunge direttamente i file degli altri. Nel pool le impostazioni si possono fissare con php_admin_value. Isolare i pool PHP-FPM per ogni sito →
post_max_size: post_max_size stabilisce la dimensione massima complessiva del contenuto di una richiesta POST; il valore predefinito è 8 MB. Come misura provvisoria contro PHP2Shell php.net indica 8M per i siti senza upload e 32M con upload. upload_max_filesize deve essere inferiore. Limitare in modo sensato post_max_size e upload_max_filesize →
Proof of Concept: Un proof of concept (PoC) è la dimostrazione che una vulnerabilità è sfruttabile, spesso sotto forma di semplice codice dimostrativo. Serve a produttori e ricercatori per la valutazione, ma può anche fare da modello per gli aggressori. Un PoC pubblicato aumenta quindi di norma l'urgenza dell'aggiornamento.

R

Ransomware: Il ransomware cifra i dati e chiede un riscatto per la decifrazione, spesso accompagnato dalla minaccia di pubblicare i dati sottratti. Un server web compromesso può essere il punto di ingresso. La protezione più efficace sono backup separati e testati e un piano di emergenza. Strategia di backup per server: backup secondo la regola 3-2-1 →
RCE: RCE (Remote Code Execution) significa che un aggressore può eseguire da remoto codice proprio su un sistema altrui. Se per farlo non serve alcuna autenticazione si parla di RCE non autenticata, la classe più grave di vulnerabilità dei server web. Con una RCE l'aggressore può leggere dati, creare backdoor e abusare ulteriormente del server. Che cos'è PHP2Shell? La vulnerabilità spiegata in modo semplice →
Reverse proxy: Un reverse proxy accoglie le richieste da Internet e le inoltra a uno o più server retrostanti. Può farsi carico di TLS, distribuire i carichi e fungere da sede per regole di filtraggio o per una WAF. Offre protezione solo se i server retrostanti non sono raggiungibili anche direttamente. Filtrare le richieste di upload al perimetro: opportunità e rischi →
RFI: RFI (Remote File Inclusion) è la variante in cui un'applicazione carica ed esegue codice da un indirizzo esterno. In PHP l'impostazione allow_url_include=Off, da tempo predefinita, impedisce di includere file remoti. Applicazioni e configurazioni vecchie andrebbero controllate in proposito. Prevenire la local file inclusion in PHP: LFI e RFI →
Root server: Un root server è un server in affitto su cui il cliente ha pieni diritti di amministratore. Con ciò la piena responsabilità per aggiornamenti, hardening e sorveglianza ricade sul cliente. Il fornitore mette a disposizione solo hardware e rete. Mettere in sicurezza da soli root server e vServer →

S

SAPI: SAPI (Server Application Programming Interface) è l'interfaccia con cui PHP dialoga con il proprio ambiente, ad esempio con Apache, PHP-FPM o la riga di comando. La SAPI in uso determina come i processi PHP vengono avviati, riutilizzati e riavviati. Con PHP2Shell, secondo il team PHP, sono interessate più modalità di esecuzione, con mod_php al rischio più alto. SAPI spiegata: come PHP dialoga con il server web →
SEO spam: Lo SEO spam è costituito da pagine, link o reindirizzamenti introdotti con cui gli aggressori posizionano nei motori di ricerca offerte altrui. Spesso solo i motori di ricerca o i visitatori provenienti da Google vedono i contenuti manipolati. Oltre alla bonifica, in seguito serve una verifica in Google Search Console. SEO spam e pagine estranee nell'indice Google →
serialize_handler: session.serialize_handler determina in quale formato PHP salva i dati di sessione, ad esempio php, php_binary o php_serialize. L'avviso su CVE-2026-115560 riguarda solo una configurazione insolita, in cui questo formato viene cambiato durante l'esecuzione e session upload progress è attivo. La soluzione fino al prossimo bugfix release è session.upload_progress.enabled=0. CVE-2026-115560: avviso su session upload progress →
Server gestito: Con un server gestito (managed server) il fornitore mette a disposizione un server dedicato e si assume per contratto parti definite della gestione, spesso gli aggiornamenti del sistema operativo e di PHP. Che cosa ne faccia parte esattamente è scritto nel contratto e varia molto tra i fornitori. Nel dubbio la responsabilità per le patch andrebbe confermata per iscritto. Managed server: chiarire le responsabilità →
Server origin: Il server origin è il vero e proprio server web dietro un CDN o un reverse proxy. Se è raggiungibile anche direttamente tramite il proprio indirizzo IP, gli aggressori possono aggirare la protezione anteposta. Per questo l'origin dovrebbe accettare solo connessioni dal CDN o dal proxy. Regole di protezione Cloudflare contro PHP2Shell: cosa fanno e cosa no →
session.upload_progress: Session upload progress è una funzione di PHP che salva nella sessione l'avanzamento dei caricamenti di file in corso; è attiva per impostazione predefinita. php.net consiglia in via provvisoria session.upload_progress.enabled=0 in php.ini, nel pool FPM o nella configurazione del server, poi di riavviare tutti i worker. Secondo i resoconti degli esperti, l'impostazione da sola non chiude entrambe le vulnerabilità PHP2Shell; l'aggiornamento resta obbligatorio. Disattivare session.upload_progress: nel modo giusto e per sempre →
Sessione: Una sessione collega più richieste dello stesso visitatore, ad esempio per l'accesso o il carrello. PHP salva i dati lato server e assegna al browser un ID di sessione, per impostazione predefinita nel cookie PHPSESSID. Chi conosce l'ID di sessione di un altro può, in certe circostanze, presentarsi come quell'utente. Sessioni e cookie in PHP →
SIEM: Un SIEM (Security Information and Event Management) raccoglie centralmente i dati di log di molti sistemi e li analizza alla ricerca di eventi di sicurezza. Così si riconoscono correlazioni che nei singoli log passerebbero inosservate. Un SIEM richiede regole curate e persone che elaborino le segnalazioni. Security monitoring per web server →
Skimming: Nello skimming nei negozi online gli aggressori introducono nel checkout JavaScript che legge e invia i dati di pagamento e dei clienti. Il codice si nasconde spesso nei file del tema, negli script di tracciamento o nelle voci del database. I clienti non se ne accorgono, il commerciante spesso solo grazie alle segnalazioni dei fornitori di pagamento. Negozio online hackerato? Sicurezza IT per i rivenditori →
SQL injection: In una SQL injection l'aggressore introduce in un'applicazione, tramite l'input, comandi di database propri. In questo modo si possono leggere o modificare dati. La protezione è offerta dalle istruzioni preparate (prepared statements) con segnaposto al posto di testi SQL assemblati. Prevenire la SQL injection in PHP →
SSRF: SSRF (Server-Side Request Forgery) induce un'applicazione a inviare, per conto dell'aggressore, richieste ad altri indirizzi, anche a sistemi interni. In questo modo diventano raggiungibili servizi che dall'esterno dovrebbero essere schermati. La protezione è offerta da elenchi di destinazioni consentite e dal blocco degli intervalli di indirizzi interni. Prevenire il Server-Side Request Forgery (SSRF) in PHP →
Superglobals: I superglobals sono variabili che PHP mette a disposizione in ogni script, ad esempio $_GET, $_POST, $_COOKIE, $_FILES, $_SERVER e $_SESSION. Contengono i dati della richiesta corrente, in gran parte provenienti dal visitatore. Tutto ciò che contengono va trattato come non attendibile e verificato. Superglobali: $_GET, $_POST, $_FILES e le altre →
sury.org: sury.org è un repository di pacchetti di Ondřej Surý con versioni di PHP attuali e meno recenti per Debian e Ubuntu. È un'offerta di terze parti e non l'archivio di sicurezza di Debian. Secondo i resoconti vi sono state rese disponibili build per tutti i rami dalla 5.6 alla 8.5. Il repository sury.org: pacchetti PHP da una fonte di terze parti →

T

Threat hunting: Il threat hunting è la ricerca attiva di aggressori nella propria rete senza che ci sia un allarme. Il punto di partenza sono ipotesi, ad esempio: un processo del server web ha avviato una shell dal 20/10? In questo modo si trovano intrusioni che gli strumenti automatici non rilevano. Segnale d'allarme: il server web avvia una shell →
TISAX: TISAX è una procedura di verifica e di scambio per la sicurezza delle informazioni nell'industria automobilistica. Si basa su un catalogo di requisiti dell'associazione tedesca dell'industria automobilistica (VDA) ed è gestita dalla ENX Association. I fornitori devono dimostrare con essa ai costruttori il proprio livello di sicurezza. ISO 27001 e TISAX: che cosa riguarda i server web →
TLS: TLS (Transport Layer Security) cifra la connessione tra browser e server; lo si riconosce da HTTPS. Attualmente sono raccomandati TLS 1.2 e 1.3, le versioni più vecchie del protocollo andrebbero disattivate. TLS protegge i dati in transito, non dalle vulnerabilità del server stesso. Configurare correttamente TLS e HTTPS →
Type juggling: Si chiama type juggling la conversione automatica dei tipi in PHP, ad esempio nel confronto debole con ==. Così valori diversi possono risultare uguali, il che diventa pericoloso nei controlli di password o token. La protezione è offerta da confronti rigorosi con === e da hash_equals() per i segreti. Type juggling in PHP: i confronti laschi come rischio di sicurezza →

U

upload_max_filesize: upload_max_filesize limita la dimensione di un singolo file caricato; il valore predefinito è 2 MB. Il valore deve essere inferiore a post_max_size, perché il file è parte della richiesta POST. Valori troppo generosi ampliano la superficie di attacco senza alcun vantaggio. Limitare in modo sensato post_max_size e upload_max_filesize →
.user.ini: I file .user.ini contengono impostazioni PHP per singola directory, valutate da PHP-FPM e CGI. Permettono ai gestori di un sito web di modificare singoli valori senza accesso al server, ma solo quelli che PHP rende modificabili. Secondo php.net, impostazioni rilevanti per la sicurezza come session.upload_progress.enabled=0 contro PHP2Shell non vanno applicate tramite .user.ini. Il php.ini spiegato: struttura, livelli e precedenza →

V

VdS 10000: VdS 10000 è una linea guida della VdS Schadenverhütung per la sicurezza delle informazioni nelle piccole e medie imprese. È più snella della ISO 27001 e tarata sulle possibilità delle PMI. È possibile una certificazione secondo questa linea guida. VdS 10000: sicurezza delle informazioni per piccole e medie imprese →
Verifica di integrità: In una verifica di integrità i file vengono confrontati con uno stato originale noto, di solito tramite checksum. Molti CMS offrono comandi propri a questo scopo, ad esempio per WordPress, Nextcloud o Matomo. File personalizzati, upload e contenuti del database non sono coperti da un simile confronto. Confrontare i file core del CMS con l'originale →
Virtual patching: Il virtual patching blocca gli attacchi a una vulnerabilità nota davanti all'applicazione, di solito con una WAF, senza modificare il codice vulnerabile. Fa guadagnare tempo finché non è possibile l'aggiornamento vero e proprio. Per PHP2Shell, ad esempio, Cloudflare avverte che le regole basate sui soli dati della richiesta non bastano; l'aggiornamento resta obbligatorio. WAF e virtual patching per PHP →
vServer: Un vServer (server virtuale) è una macchina virtuale su hardware condiviso, con sistema operativo proprio e di solito accesso root. Per la sicurezza vale lo stesso che per il root server: aggiornamenti e hardening spettano al cliente. Molti vServer girano con pannelli preinstallati come Plesk. Mettere in sicurezza da soli root server e vServer →

W

WAF: Una WAF (Web Application Firewall) esamina le richieste HTTP prima dell'applicazione e blocca i modelli di attacco noti. Può funzionare come servizio cloud, come proxy o come modulo del server web. Fa guadagnare tempo ma non sostituisce un aggiornamento, e viene aggirata se il server è raggiungibile anche direttamente. WAF e virtual patching per PHP →
Web shell: Una web shell è uno script che gli aggressori depositano su un server web per controllarlo da remoto tramite il browser. Spesso è piccola, offuscata e nascosta in cartelle di upload o di cache. Una web shell resta anche dopo un aggiornamento di PHP o del CMS e va cercata in modo mirato. Riconoscere e rimuovere una webshell →

X

XSS: XSS (cross-site scripting) significa che JavaScript estraneo viene eseguito, tramite un sito web, nel browser di altri visitatori. Così si possono dirottare sessioni o leggere ciò che viene digitato nei moduli. La protezione è offerta dalla codifica sistematica di tutti gli output e da una Content Security Policy. Prevenire XSS in PHP: difendersi con sicurezza dal cross-site scripting →
XXE: XXE (XML External Entities) sfrutta il fatto che i parser XML possono caricare riferimenti esterni presenti nei documenti. In certe circostanze ciò permette di leggere file dal server o di innescare richieste interne. La protezione consiste nel disattivare il caricamento di entità esterne quando si elaborano dati XML non attendibili. Prevenire gli XML External Entities (XXE) in PHP →

Z

ZAC: Le Zentrale Ansprechstellen Cybercrime (ZAC) della polizia tedesca sono punti di contatto specializzati per aziende e autorità vittime di un attacco informatico. Esistono in tutti i Länder e presso il BKA, l'ufficio federale di polizia criminale. Ricevono le denunce e forniscono consulenza sui passi successivi. Sporgere denuncia: i punti di contatto centrali Cybercrime →
Zend Engine: La Zend Engine è il cuore dell'interprete PHP. Traduce il codice PHP in istruzioni interne (opcode), le esegue e gestisce la memoria. Gli errori nella Zend Engine hanno effetto su ogni applicazione PHP e si correggono solo con un aggiornamento di PHP. La Zend Engine: il cuore di PHP →
Zero-day: Uno zero-day è una vulnerabilità che viene sfruttata o è di dominio pubblico prima che il produttore metta a disposizione una patch. I gestori hanno quindi zero giorni di anticipo. Fino alla patch aiutano solo misure provvisorie, isolamento e monitoraggio. La finestra di tempo tra patch e attacco →

Contatto immediato

Ogni ora conta. Ci scriva adesso.

Descriva brevemente sistema, versione di PHP e quanto osservato. Ci faremo sentire, chiariremo la situazione e lavoreremo da remoto fino alla chiusura e alla documentazione dell'incidente.

Emergenza WhatsApp Chiama