# Blog: PHP2Shell, sicurezza dei server e assistenza di emergenza

> Blog su PHP2Shell e sicurezza dei server: situazione, hosting, rilevamento, hardening, sviluppo sicuro, gestione e strumenti decisionali.

Fonte: https://phpsos.de/it/blog/  
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

Inquadramento della situazione, istruzioni per amministratori e strumenti decisionali per la direzione. Ordinati per tema, ogni articolo con fonti.

- [PHP2Shell: cosa è accertato e cosa no](https://phpsos.de/it/blog/php2shell-was-belegt-ist/): Un fact check su PHP2Shell: quali affermazioni provengono da fonti primarie, quali dai media e quali asserzioni non reggono alla verifica.
- [Perché la vulnerabilità PHP è diventata nota prima della patch](https://phpsos.de/it/blog/php-luecke-vorzeitig-bekannt/): Secondo i rapporti, i dettagli su PHP2Shell sono diventati pubblici prima della fine dell'embargo. Spieghiamo lo svolgimento e che cosa significa per la Sua pianificazione delle patch.
- [Le autorità portano i siti offline: cosa ne imparano le aziende](https://phpsos.de/it/blog/behoerden-webseiten-offline/): Magonza, il governo regionale dell'Assia e il BKA hanno messo offline siti web in via precauzionale. Che cosa ne possono ricavare le aziende per la propria decisione.
- [Allerta arancione del BSI: cosa significa la classificazione](https://phpsos.de/it/blog/bsi-warnstufe-orange-erklaert/): Il BSI classifica PHP2Shell al livello 3 / arancione. Che cosa dice la scala, che cosa no, e come le aziende traducono la classificazione in decisioni.
- [Cosa consigliano CERT-EU e CERT-Bund su PHP2Shell](https://phpsos.de/it/blog/cert-eu-empfehlungen-php/): Gli enti ufficiali concordano: applicare subito la patch, altrimenti isolare. Confrontiamo le raccomandazioni e mostriamo come si presenta in pratica l'isolamento.
- [Regole di protezione Cloudflare contro PHP2Shell: cosa fanno e cosa no](https://phpsos.de/it/blog/cloudflare-waf-php2shell/): Cloudflare ha distribuito presto regole di protezione contro PHP2Shell. Perché aiutano, perché non sostituiscono comunque l'aggiornamento di PHP e quali impostazioni verificare.
- [22,6 milioni di istanze esposte: come leggere i numeri](https://phpsos.de/it/blog/exponierte-instanzen-einordnen/): Unit 42, CybelAngel e altri citano numeri molto diversi su PHP2Shell. Spieghiamo che cosa è stato contato e quale numero conta davvero per Lei.
- [PHP2Shell in cinque minuti: briefing per la direzione](https://phpsos.de/it/blog/php2shell-briefing-geschaeftsfuehrung/): La vulnerabilità PHP2Shell in una pagina per chi decide: situazione, rischio, cinque domande all'IT e le decisioni per oggi.
- [La vulnerabilità di sicurezza PHP spiegata in modo semplice](https://phpsos.de/it/blog/php-luecke-einfach-erklaert/): PHP2Shell per chi non è tecnico: con immagini quotidiane, un piccolo glossario e tre situazioni tipiche di partenza, cosa dovrebbe fare come gestore di un sito.
- [PHP2Shell: 15 domande dei clienti di hosting](https://phpsos.de/it/blog/fragen-von-hosting-kunden/): Il Suo sito è presso l'hoster e vuole sapere cosa deve fare personalmente con PHP2Shell? Ecco le 15 domande più frequenti con risposte brevi.
- [Perché un aggiornamento di WordPress non aiuta contro PHP2Shell](https://phpsos.de/it/blog/warum-wordpress-update-nicht-hilft/): Dopo i titoli molti gestori hanno aggiornato WordPress e si sentono al sicuro. Perché con PHP2Shell non serve e che cosa conta invece.
- [PHP2Shell e Log4Shell: che cosa hanno in comune le vulnerabilità](https://phpsos.de/it/blog/php2shell-und-log4shell/): Molti confrontano PHP2Shell con Log4Shell del 2021. Cosa regge del confronto, dove zoppica e quali lezioni di allora aiutano oggi.
- [Scansioni di massa alla ricerca di PHP privo di patch: come funzionano gli attacchi automatizzati](https://phpsos.de/it/blog/automatisierte-massenscans/): Dopo PHP2Shell gli aggressori setacciano Internet in modo automatizzato alla ricerca di server vulnerabili. Come funziona, perché le dimensioni non contano e che cosa protegge.
- [La finestra di tempo tra patch e attacco](https://phpsos.de/it/blog/zeitfenster-patch-angriff/): Con PHP2Shell ci sono stati tentativi di attacco già prima della patch. Spieghiamo le fasi della finestra, come misurare la Sua e come accorciarla.
- [Dopo PHP2Shell: perché altre segnalazioni sono probabili](https://phpsos.de/it/blog/weitere-php-meldungen/): PHP2Shell non si chiude con la patch del 21 ottobre. Perché sono da attendersi segnalazioni successive e come preparare il Suo team.
- [PHP2Shell: il quadro della situazione nella prima settimana](https://phpsos.de/it/blog/lagebild-erste-woche/): Una settimana dopo il primo tentativo di attacco osservato: lo stato di patch, allerte delle autorità, attacchi e spegnimenti, separato con ordine per fonti.
- [Falsi consigli pericolosi su PHP2Shell che circolano in questo periodo](https://phpsos.de/it/blog/gefaehrliche-falschtipps/): Bloccare i cookie, nascondere i messaggi di errore, aggiornare solo il CMS: nove consigli su PHP2Shell che creano una falsa sicurezza e che cosa conta davvero.
- [Cambiare la versione di PHP nell'area clienti dell'hosting](https://phpsos.de/it/blog/php-version-hosting-aendern/): Come cambiare la versione di PHP nell'area clienti del Suo hoster, quale versione scegliere e che cosa verificare prima e dopo.
- [Debian e Ubuntu: il mio pacchetto PHP è aggiornato?](https://phpsos.de/it/blog/debian-ubuntu-paket-gepatcht/): Quali pacchetti PHP Debian e Ubuntu hanno corretto contro PHP2Shell, come confrontare con precisione lo stato installato e dove fallisce la prova.
- [RHEL, AlmaLinux e Rocky Linux: verificare la patch PHP](https://phpsos.de/it/blog/rhel-almalinux-rocky-php/): Cosa ha pubblicato Red Hat su PHP2Shell, come documentare lo stato dei pacchetti su RHEL e sui cloni e perché un reload non basta.
- [Il repository sury.org: pacchetti PHP da una fonte di terze parti](https://phpsos.de/it/blog/sury-repository-php/): Molti server Debian e Ubuntu ottengono PHP dal repository sury. Cosa significa per aggiornamenti, prove e vecchie versioni di PHP dopo PHP2Shell.
- [Il repository Remi: tenere aggiornato PHP sui sistemi RHEL](https://phpsos.de/it/blog/remi-repository-php/): Remi fornisce versioni attuali di PHP per la famiglia RHEL, come modulo o installabili in parallelo. Come verificare lo stato dopo PHP2Shell ed evitare rami dimenticati.
- [Perché php -v dopo l'aggiornamento mostra lo stesso numero](https://phpsos.de/it/blog/php-v-zeigt-alte-nummer/): L'aggiornamento è andato a buon fine, ma php -v segnala la vecchia versione. Di solito è un backport e non un errore. Come distinguere i casi innocui dai problemi veri.
- [Dimostrare i numeri CVE nel changelog del pacchetto](https://phpsos.de/it/blog/cve-im-changelog-nachweisen/): Chi deve documentare una patch PHP a direzione, revisori o assicuratori ha bisogno di più di un numero di versione. Ecco come la voce del changelog diventa una prova.
- [Cambiare hoster dopo un incidente di sicurezza: a cosa fare attenzione?](https://phpsos.de/it/blog/hoster-wechseln-nach-vorfall/): Dopo un incidente il desiderio di un nuovo hoster è comprensibile. Perché il cambio non porti con sé l'aggressore, contano l'ordine dei passi e la scelta.
- [Più versioni PHP su un server: aggiornare ciascuna singolarmente](https://phpsos.de/it/blog/mehrere-php-versionen-server/): Su molti server girano affiancate tre, quattro o più installazioni di PHP. Dopo PHP2Shell ognuna va individuata, aggiornata e riavviata.
- [Disattivare le vecchie versioni di PHP nel pannello di hosting](https://phpsos.de/it/blog/alte-php-versionen-abschalten/): PHP2Shell è una buona occasione per liberarsi delle vecchie versioni di PHP. Ecco come procedere in tre fasi, perché nessun sito e nessun cron job smetta di funzionare senza che ce ne si accorga.
- [Plesk: capire gli handler PHP (FPM, FastCGI, modulo Apache)](https://phpsos.de/it/blog/plesk-php-handler/): L'handler PHP che Plesk usa per un sito determina isolamento, configurazione e rischio. Un confronto in chiave PHP2Shell.
- [CloudLinux e alt-php: cosa devono sapere i clienti dell'hosting](https://phpsos.de/it/blog/cloudlinux-alt-php/): Sui server CloudLinux i siti girano spesso con pacchetti alt-php propri. Ognuna di queste versioni richiede la propria patch, e solo il gestore del server può installarla.
- [PHP su NAS, firewall e appliance: i sistemi dimenticati](https://phpsos.de/it/blog/php-auf-nas-und-appliances/): Non solo i server web usano PHP. Possono essere interessati anche NAS, firewall e dispositivi specializzati con interfaccia web. Aggiornare, lì, di solito può solo il produttore; la raggiungibilità la regola Lei.
- [PHP presso i fornitori cloud e PaaS: chi aggiorna il runtime?](https://phpsos.de/it/blog/paas-php-laufzeit/): Sui servizi di piattaforma la patch di PHP dipende dal modello di esercizio. Conta il runtime che serve effettivamente le richieste, non l'ambiente locale né il codice dell'applicazione.
- [Immagini Docker ufficiali di PHP: tag, digest e ricostruzione](https://phpsos.de/it/blog/offizielle-php-docker-images/): Un tag dell'immagine PHP ufficiale è un puntatore che nel tempo si sposta su nuovi stati. Chi sa cosa significano tag, variante e digest sceglie l'immagine giusta e può documentare lo stato della patch.
- [CI/CD: ricostruire automaticamente le immagini PHP](https://phpsos.de/it/blog/php-images-in-ci-neu-bauen/): Un'immagine invecchia anche senza modifiche al codice. Con build pianificate, un controllo della versione e un rollout tramite digest, le patch PHP arrivano in produzione in modo affidabile.
- [Supporto a lungo termine per le vecchie versioni di PHP: opzioni e limiti](https://phpsos.de/it/blog/langzeitsupport-alte-php-versionen/): Chi non può passare subito da PHP 8.1 o precedenti trova il supporto a lungo termine presso distribuzioni, fornitori terzi e servizi commerciali. Cosa offrono queste strade, cosa Le serve per iscritto e dove stanno i limiti.
- [Aggiornare PHP su Windows](https://phpsos.de/it/blog/php-unter-windows-aktualisieren/): Su Windows non esiste un aggiornamento automatico di PHP. Chi sceglie la variante giusta, verifica il download e riavvia tutti i processi porta la patch di PHP2Shell su ogni computer in modo pulito.
- [Segnale d'allarme: il server web avvia una shell](https://phpsos.de/it/blog/webserver-startet-shell/): Se un processo PHP-FPM o del server web avvia una shell, è uno dei segnali d'allarme più forti di un'intrusione. Come verificare l'albero dei processi, inquadrare le eccezioni e monitorare il modello nel tempo.
- [Individuare processi sospetti sui server Linux](https://phpsos.de/it/blog/verdaechtige-prozesse-linux/): I processi dannosi si mimetizzano con nomi innocui, girano da cartelle temporanee o da file cancellati. Con pochi comandi di sola lettura trova le anomalie e le inquadra.
- [Riconoscere i cron job nascosti come backdoor](https://phpsos.de/it/blog/cronjobs-als-hintertuer/): Gli aggressori usano attività pianificate per tornare dopo una bonifica. Come verificare per intero crontab, directory cron, timer systemd e job at e riconoscere le voci sospette.
- [Trovare i file modificati di recente sul server web](https://phpsos.de/it/blog/geaenderte-dateien-finden/): Dopo una possibile intrusione conta ciò che sul server è cambiato. Come cercare per finestre temporali, usare correttamente mtime e ctime e confrontare con pacchetti, Git e backup.
- [File PHP nella cartella di upload: interpretare correttamente i ritrovamenti](https://phpsos.de/it/blog/php-dateien-im-upload-ordner/): Un file PHP nella cartella di upload è quasi sempre un segnale d'allarme, ma non ogni file è codice dannoso. Come valutare il ritrovamento senza distruggere le tracce e chiarire se qualcuno lo abbia richiamato.
- [Riconoscere il codice PHP offuscato](https://phpsos.de/it/blog/verschleierter-php-code/): Il codice PHP illeggibile con eval e base64_decode è un classico segno di codice dannoso inserito. Quali modelli cercare, come trovarli senza rischi e quando l'offuscamento è legittimo.
- [Verificare le connessioni in uscita di un server](https://phpsos.de/it/blog/ausgehende-verbindungen-pruefen/): Un server web risponde soprattutto a richieste. Se stabilisce da sé connessioni verso destinazioni sconosciute, può significare controllo da parte di aggressori o fuga di dati. Come verificare e limitare il traffico in uscita.
- [Trovare account admin estranei in CMS e server](https://phpsos.de/it/blog/fremde-admin-konten-finden/): Un amministratore sconosciuto è spesso la backdoor più semplice. Come cercare account estranei livello per livello, anche quelli che l'interfaccia nasconde.
- [Trovare e rimuovere chiavi SSH sconosciute](https://phpsos.de/it/blog/ssh-schluessel-pruefen/): Una chiave SSH inserita abusivamente apre la porta agli aggressori anche se tutte le password sono state cambiate. Come trovare ogni file authorized_keys e verificare ogni voce.
- [Cryptominer sul server web: segni e come procedere](https://phpsos.de/it/blog/kryptominer-auf-dem-server/): CPU costantemente al massimo senza che arrivino più visitatori: può essere un cryptominer. Come verificare il carico, trovare il processo e i suoi meccanismi di riavvio e procedere in modo ordinato.
- [Il server invia spam: trovare le cause](https://phpsos.de/it/blog/server-verschickt-spam/): Mail non consegnabili, blacklist, reclami: quando il proprio server invia spam, dietro di solito c'è uno script o una casella compromessa. Come trovare la fonte.
- [SEO spam e pagine estranee nell'indice Google](https://phpsos.de/it/blog/seo-spam-im-google-index/): All'improvviso sotto il Suo dominio si posizionano pagine su farmaci o merce contraffatta. Come scoprire da dove arriva lo SEO spam e farlo uscire dall'indice.
- [Il sito reindirizza verso pagine estranee](https://phpsos.de/it/blog/website-leitet-um/): I visitatori finiscono su concorsi a premi o negozi dubbi, ma Lei non vede nulla? Come trovare lo strato in cui si nasconde il reindirizzamento ed eliminarlo.
- [Conservare le prove prima di reinstallare il server](https://phpsos.de/it/blog/beweise-sichern-vor-neuinstallation/): Una ricostruzione elimina l'aggressore, ma anche tutte le tracce. Chi investe prima un'ora nella conservazione delle prove potrà poi dire che cosa è successo.
- [Costruire la cronologia di un incidente](https://phpsos.de/it/blog/zeitleiste-eines-vorfalls/): Quando è arrivato l'aggressore, che cosa ha fatto, quando ce ne si è accorti? Una cronologia ordinata risponde a queste domande ed è la base per notifiche, assicurazione e relazione.
- [Confrontare i file core del CMS con l'originale](https://phpsos.de/it/blog/cms-kerndateien-vergleichen/): Il confronto con un originale pulito mostra ogni file modificato, indipendentemente dal fatto che uno scanner lo conosca. Come impostare il confronto per WordPress, progetti Composer e pacchetti di sistema.
- [Verificare la presenza di codice iniettato nel database](https://phpsos.de/it/blog/datenbank-auf-schadcode-pruefen/): Chi controlla solo i file trascura metà del problema. Come cercare nel database codice iniettato in contenuti, impostazioni, trigger e account, in sola lettura e su una copia.
- [Scanner di malware per siti web: cosa trovano e cosa no](https://phpsos.de/it/blog/grenzen-von-malware-scannern/): Lo scanner non segnala nulla, quindi va tutto bene? Non necessariamente. Quali tipi di scanner di siti web esistono, che cosa vede ciascuno e che cosa non può vedere per principio.
- [Isolare i pool PHP-FPM per ogni sito](https://phpsos.de/it/blog/php-fpm-pools-isolieren/): Un pool dedicato per ogni sito è l'inizio, non la fine. Come verificare i pool esistenti e rafforzare socket, estensioni, pagine di stato, risorse e log.
- [Impostare correttamente memory_limit](https://phpsos.de/it/blog/memory-limit-richtig-setzen/): memory_limit limita la memoria per ogni richiesta PHP. Dopo PHP2Shell php.net consiglia in via transitoria il contrario. Che cosa vale in esercizio normale, nella fase transitoria e dopo l'aggiornamento.
- [Limitare in modo sensato post_max_size e upload_max_filesize](https://phpsos.de/it/blog/post-max-size-upload-limits/): I limiti di upload agiscono in tre punti: nel server web, in PHP e nell'applicazione. Come impostare i valori in modo coerente, anche con i valori transitori di php.net per PHP2Shell.
- [Disattivare session.upload_progress: nel modo giusto e per sempre](https://phpsos.de/it/blog/session-upload-progress-abschalten/): Il rimedio contro CVE-2026-115560 e una delle misure transitorie per PHP2Shell si imposta in fretta. Perché regga, deve stare nel punto giusto, essere bloccata e venire ricontrollata dopo ogni aggiornamento.
- [expose_php e header Server: nascondere le indicazioni di versione](https://phpsos.de/it/blog/expose-php-versionsangaben/): PHP, Nginx e Apache indicano per impostazione predefinita il numero di versione in ogni risposta. Non protegge dagli attacchi, ma fornisce agli scanner un comodo elenco di bersagli. Come disattivarlo e mantenere comunque il controllo.
- [display_errors off: disattivare l'output degli errori in produzione](https://phpsos.de/it/blog/display-errors-produktion/): I messaggi di errore PHP visibili rivelano percorsi, nomi di database e versioni. Come disattivarli in PHP, nel framework e nel server web senza perdere di vista gli errori.
- [php_admin_value: bloccare le impostazioni contro la sovrascrittura](https://phpsos.de/it/blog/php-admin-value-sperren/): Un'impostazione di sicurezza serve a poco se l'applicazione la modifica di nuovo con una riga di codice. Con php_admin_value e php_admin_flag fissa in modo vincolante i valori per PHP-FPM e Apache.
- [Impostare limiti di memoria con systemd e cgroup](https://phpsos.de/it/blog/speichergrenzen-systemd-cgroups/): Come misura transitoria per PHP2Shell php.net raccomanda memory_limit=-1 e un limite di memoria fuori da PHP. Come impostare questo limite con systemd e cgroup, senza che un singolo worker trascini con sé l'intero servizio.
- [Configurare Nginx per PHP in sicurezza](https://phpsos.de/it/blog/nginx-fuer-php-absichern/): La maggior parte dei punti deboli nelle configurazioni Nginx per PHP non è in Nginx, ma in poche righe della location PHP. Come configurare il passaggio a PHP-FPM in modo che vengano eseguiti solo gli script voluti.
- [Configurare Apache per PHP in sicurezza](https://phpsos.de/it/blog/apache-fuer-php-absichern/): Apache è flessibile, ed è proprio questo a renderlo esposto a configurazioni errate. Come collegare PHP tramite PHP-FPM, chiudere .htaccess come backdoor e impostare in modo sicuro le principali opzioni di base.
- [Vietare l'esecuzione di PHP nelle cartelle di upload](https://phpsos.de/it/blog/php-in-uploads-verbieten/): Una web shell ha bisogno di due cose: una cartella in cui poter essere scritta e un server che la esegue. Come toglierle la seconda, in ogni cartella scrivibile e non solo in uploads.
- [Filtrare le richieste di upload al perimetro: opportunità e rischi](https://phpsos.de/it/blog/upload-anfragen-am-rand-filtern/): Autori specializzati propongono di bloccare sul proxy, fuori dai veri percorsi di upload, le richieste di upload finché PHP non è aggiornato. Può aiutare, ma anche paralizzare moduli e ordini. Come procedere in modo controllato.
- [Usare ModSecurity e OWASP Core Rule Set](https://phpsos.de/it/blog/modsecurity-owasp-crs/): Una Web Application Firewall propria con ModSecurity e OWASP Core Rule Set è gratuita e potente, ma non va da sola. Come scegliere il motore, partire senza interruzioni e tarare le regole.
- [Configurare Fail2ban per i server web](https://phpsos.de/it/blog/fail2ban-fuer-webserver/): Fail2ban blocca gli indirizzi che compaiono ripetutamente nei log. Per i server web fornisce filtri già pronti e con poche righe se ne aggiungono di propri. Come configurarlo senza escludere sé stessi o i clienti.
- [Firewall per server web: aprire solo le porte necessarie](https://phpsos.de/it/blog/firewall-fuer-webserver/): Un server web verso l'esterno ha di solito bisogno di due sole porte. Eppure su molti server database, PHP-FPM o interfacce di amministrazione sono in ascolto su Internet. Come trovare i servizi aperti e chiudere ciò che non serve.
- [Aggiornamenti di sicurezza automatici sui server Linux](https://phpsos.de/it/blog/automatische-sicherheitsupdates/): Secondo i rapporti, le distribuzioni hanno consegnato i backport di PHP in parte già il 21 ottobre 2026, il giorno delle patch. Chi usa aggiornamenti di sicurezza automatici li aveva presto sul server. Perché funzionino servono riavvii, fonti terze e controllo.
- [Least Privilege: i permessi dell'utente del server web](https://phpsos.de/it/blog/rechte-des-webserver-benutzers/): Il codice iniettato gira con i permessi dell'utente del server web. Ciò che questo account può fare decide fin dove arriva un aggressore. Così limita shell, sudo, cron, database e file system allo stretto necessario.
- [Schermare le aree admin con IP, VPN o protezione aggiuntiva](https://phpsos.de/it/blog/admin-bereiche-abschirmen/): Perché il backend di un sito non deve essere raggiungibile da tutto il mondo e come schermarlo con una whitelist di indirizzi IP, una VPN o un accesso preliminare, senza chiudersi fuori.
- [Configurare correttamente TLS e HTTPS](https://phpsos.de/it/blog/tls-https-richtig-konfigurieren/): Quali versioni di TLS e quali cipher suite un server web dovrebbe offrire oggi, a che cosa si ispirano le raccomandazioni e come verificare Nginx, Apache e le connessioni in uscita di PHP.
- [Benchmark CIS e moduli BSI per i server web](https://phpsos.de/it/blog/cis-benchmarks-bsi-bausteine/): Quali standard di hardening esistono per i server web Linux, in che cosa differiscono i benchmark CIS e i moduli dell'IT-Grundschutz e come ricavarne una direttiva verificabile per i suoi server PHP.
- [Salvare le password in PHP in sicurezza: usare bene password_hash](https://phpsos.de/it/blog/passwoerter-in-php-speichern/): Come gli sviluppatori salvano le password in PHP con password_hash e password_verify, scelgono l'algoritmo adatto e sostituiscono i vecchi hash MD5 o SHA-1 senza un reset della password per tutti gli utenti.
- [Protezione CSRF nelle applicazioni PHP](https://phpsos.de/it/blog/csrf-schutz-php/): Come gli sviluppatori prevengono il Cross-Site Request Forgery nelle applicazioni PHP: token per ogni richiesta che modifica dati, verifica dell'origine nell'header e cookie SameSite come livello aggiuntivo.
- [Validare e filtrare gli input in PHP con filter_var](https://phpsos.de/it/blog/eingaben-validieren-php/): Come gli sviluppatori verificano gli input in PHP con filter_var, filter_input_array e liste di valori consentiti, quali filtri sono obsoleti e perché la validazione non sostituisce prepared statement e codifica dell'output.
- [Prevenire la command injection in PHP](https://phpsos.de/it/blog/command-injection-php/): Come gli sviluppatori evitano la command injection in PHP: sostituire i comandi di sistema con funzioni PHP, usare proc_open senza shell, verificare gli argomenti e trovare i punti pericolosi nel codice esistente.
- [Prevenire il Server-Side Request Forgery (SSRF) in PHP](https://phpsos.de/it/blog/ssrf-in-php/): Come gli sviluppatori impediscono che un'applicazione PHP interroghi sistemi interni per conto di estranei: liste consentite, limitazione dei protocolli, verifica dell'indirizzo risolto e limiti nella rete.
- [Prevenire gli XML External Entities (XXE) in PHP](https://phpsos.de/it/blog/xxe-in-php/): Come gli sviluppatori elaborano XML in PHP in sicurezza: comportamento predefinito di libxml, opzioni rischiose come LIBXML_NOENT, protezione con entity loader e LIBXML_NO_XXE e tipici ingressi XML nascosti.
- [Type juggling in PHP: i confronti laschi come rischio di sicurezza](https://phpsos.de/it/blog/type-juggling-php/): Perché i confronti laschi con == in PHP possono causare vulnerabilità, che cosa è cambiato con PHP 8.0 e come scrivere in modo robusto i confronti in login, token e autorizzazioni.
- [Numeri casuali e token sicuri in PHP con random_bytes](https://phpsos.de/it/blog/sichere-tokens-php/): Come gli sviluppatori generano in PHP token per link di password, chiavi API e codici monouso: fonti crittograficamente sicure, lunghezza adeguata, salvataggio come hash e validità limitata.
- [Proteggere correttamente credenziali e file .env](https://phpsos.de/it/blog/env-dateien-schuetzen/): Come proteggere nei progetti PHP password del database, chiavi API e altri segreti: file .env fuori dal webroot, blocchi nel server web, permessi stretti e sostituzione ordinata dopo un incidente.
- [Cartella .git pubblica: una fuga di dati sottovalutata](https://phpsos.de/it/blog/git-ordner-oeffentlich/): Perché un webroot distribuito con Git può rivelare l'intero codice sorgente con la cronologia, come verificarlo, bloccarlo subito e impostare il deployment in modo duraturo senza la cartella .git.
- [File di backup nel webroot: .zip, .sql e .bak](https://phpsos.de/it/blog/backup-dateien-im-webroot/): Perché dump del database, archivi e copie di sicurezza nella directory pubblica sono tra le fughe di dati più frequenti, come trovarli, bloccarli e chiarire se sono stati richiamati.
- [File phpinfo(): perché devono sparire](https://phpsos.de/it/blog/phpinfo-dateien-entfernen/): Dopo PHP2Shell molti admin creano in fretta un info.php. Perché tali file sono una fuga di dati, come trovarli e quali modi di verifica sono migliori.
- [Tenere aggiornate le dipendenze: Composer, npm e plugin](https://phpsos.de/it/blog/abhaengigkeiten-aktuell-halten/): Un progetto è composto da tre mondi di pacchetti: Composer, npm e plugin CMS. Come tenerli aggiornati tutti e tre con una cadenza fissa, responsabilità chiare e test.
- [Code review di sicurezza per i progetti PHP](https://phpsos.de/it/blog/sicherheits-code-review-php/): Come i team esaminano in modo mirato il proprio codice PHP alla ricerca di vulnerabilità: tipi di review, funzioni critiche, strumenti utili e una checklist.
- [Loggare in sicurezza: registrare gli errori senza fuga di dati](https://phpsos.de/it/blog/sicher-loggen-php/): I log aiutano nella ricerca degli errori e nella forensica, ma diventano facilmente essi stessi una fuga di dati. Che cosa le applicazioni PHP dovrebbero registrare, che cosa mai e come proteggere i log.
- [Proteggere le API REST in PHP](https://phpsos.de/it/blog/rest-api-php-absichern/): Le interfacce sono spesso protette peggio del sito che hanno davanti. Le regole più importanti per le API REST in PHP, dall'autorizzazione per oggetto alla limitazione della frequenza.
- [Contratti con i fornitori IT: regolare con chiarezza gli obblighi di sicurezza](https://phpsos.de/it/blog/dienstleistervertrag-sicherheit/): PHP2Shell ha mostrato quanto spesso non sia chiaro chi debba aggiornare. Quali obblighi di sicurezza appartengono ai contratti con agenzia, hoster e fornitore IT.
- [Trattamento dei dati per conto terzi quando i fornitori accedono ai server](https://phpsos.de/it/blog/auftragsverarbeitung-serverzugriff/): Chi lascia accedere esterni a server con dati dei clienti ha di solito bisogno di un contratto di trattamento (AVV, DPA). Che cosa richiede l'art. 28 GDPR e come organizzare gli accessi in emergenza nel rispetto della protezione dei dati.
- [Gestione delle vulnerabilità per le PMI](https://phpsos.de/it/blog/schwachstellenmanagement-mittelstand/): Nessuna PMI può elaborare subito ogni segnalazione. Un ciclo snello di rilevazione, valutazione, decisione e prova fa sì che ciò che conta di più venga fatto per primo.
- [Sapere che cosa gira: l'inventario di tutti i siti e server](https://phpsos.de/it/blog/inventar-websites-server/): Con PHP2Shell molti non sono inciampati sulla patch, ma sulla domanda di dove giri davvero PHP. Ecco come costruire un inventario di tutti i siti e server.
- [Patch management come processo, non come emergenza](https://phpsos.de/it/blog/patch-management-prozess/): Chi applica patch solo quando c'è l'incendio perde tempo nell'emergenza. Come un processo con classi, finestre e prove fisse unisce routine ed emergenza.
- [Contatti di emergenza: chi va informato e quando?](https://phpsos.de/it/blog/notfallkontakte-liste/): Nell'emergenza conta chi si raggiunge e quando. Come costruire un elenco dei contatti di emergenza IT, con eventi scatenanti, sostituti e i dati che servono a ogni telefonata.
- [Quanto costa un server violato: le voci di costo](https://phpsos.de/it/blog/kostenposten-eines-hacks/): Un server web violato causa più costi della sola riparazione. Quali voci di costo emergono e come giustificare un budget di prevenzione con cifre proprie.
- [Informare i clienti dopo un incidente](https://phpsos.de/it/blog/kunden-nach-vorfall-informieren/): Obbligo o scelta: come decidere dopo un incidente chi informare, quali canali sono sicuri e come preparare l'assistenza clienti.
- [La catena di fornitura del web: agenzia, hoster, fornitore di plugin](https://phpsos.de/it/blog/lieferkette-agentur-hoster/): PHP2Shell ha mostrato quanti anelli ci sono tra una patch e il Suo sito. Come conoscere e proteggere la catena del Suo sito e assorbire i guasti dei singoli anelli.
- [Consapevolezza della sicurezza per admin e redattori: security awareness nel team web](https://phpsos.de/it/blog/sicherheitsbewusstsein-redaktion/): Chi cura i siti decide ogni giorno di sicurezza, spesso senza accorgersene. Come formare admin e redattori in base al ruolo e senza maratone di slide.
- [Esercitazione di emergenza a tavolino: simulare un incidente su un server web](https://phpsos.de/it/blog/notfalluebung-am-tisch/): Un'esercitazione a tavolino costa un pomeriggio e mostra se il Suo piano di emergenza regge. Qui trova un copione pronto per un incidente su un server web PHP.
- [ISO 27001 e TISAX: che cosa riguarda i server web](https://phpsos.de/it/blog/iso-27001-tisax-webserver/): Chi gestisce un ISMS secondo ISO 27001 o ha un label TISAX deve considerare anche i server web. Ecco quali requisiti toccano e quali prove contano dopo PHP2Shell.
- [VdS 10000: sicurezza delle informazioni per piccole e medie imprese](https://phpsos.de/it/blog/vds-10000-kmu/): La VdS 10000 è un quadro snello per la sicurezza delle informazioni nelle PMI. Che cosa richiede, che cosa è cambiato nel 2025 e che cosa significa per siti e server web.
- [Lessons learned: migliorare dopo l'incidente](https://phpsos.de/it/blog/lessons-learned-nach-vorfall/): Dopo l'incidente viene il prossimo incidente. Una riunione strutturata, senza attribuzione di colpe, trasforma una brutta settimana in un progresso misurabile.
- [Patch, spegnimento o attesa? Una guida alla decisione per la falla PHP](https://phpsos.de/it/blog/patchen-abschalten-abwarten/): Con una falla PHP critica i responsabili devono decidere in fretta. Questa guida ordina le tre opzioni, indica i criteri e mostra quando attendere è giustificabile.
- [WAF o aggiornamento: perché servono entrambi](https://phpsos.de/it/blog/waf-oder-update/): Un Web Application Firewall può intercettare attacchi, ma non chiude una falla nell'interprete PHP. Quando una WAF aiuta, dove finisce e come combinare le due cose.
- [Reinstallare o bonificare il server? La decisione dopo un'infezione](https://phpsos.de/it/blog/neu-aufsetzen-oder-bereinigen/): Dopo un'intrusione ci sono due strade: bonificare il server o ricostruirlo. Quali criteri decidono e perché l'ordine conta più della scelta.
- [Risolvere da soli o rivolgersi a un fornitore? Una valutazione onesta](https://phpsos.de/it/blog/selbst-beheben-oder-dienstleister/): Non ogni situazione di sicurezza richiede aiuto esterno. Con questi criteri e un breve autotest decide se il Suo team affronta PHP2Shell da solo o ha bisogno di supporto.
- [Scegliere un fornitore di sicurezza IT: 12 domande prima dell'incarico](https://phpsos.de/it/blog/sicherheitsdienstleister-auswaehlen/): Sotto pressione di tempo è difficile trovare un buon fornitore di sicurezza. Queste dodici domande aiutano a confrontare le offerte in modo oggettivo, senza cadere nelle promesse pubblicitarie.
- [Managed hosting o server proprio? Il confronto sulla sicurezza](https://phpsos.de/it/blog/managed-oder-eigener-server/): PHP2Shell è stato uno stress test per ogni modello operativo. Il confronto mostra quando il managed hosting è più sicuro, quando il server proprio e quali forme miste funzionano.
- [Aggiornamento PHP o backport? La scelta per i sistemi legacy](https://phpsos.de/it/blog/php-upgrade-oder-backport/): Per le vecchie versioni di PHP, dopo PHP2Shell ci sono più strade: backport della distribuzione, fonte di terzi, patch dai sorgenti, supporto a lungo termine o aggiornamento. Quanto vale e quanto regge ciascuna.
- [Cambiare CMS dopo l'hack? Quando aiuta e quando no](https://phpsos.de/it/blog/cms-wechsel-nach-hack/): Dopo un'intrusione la fiducia nel CMS è spesso svanita. Ma un nuovo sistema risolve di rado la vera causa. Quando il cambio ha senso e come riuscirlo in modo pulito.
- [Siti web statici: meno PHP, meno superficie di attacco](https://phpsos.de/it/blog/statische-website-alternative/): Un sito statico serve file HTML già pronti e non richiede PHP sul server. Ciò riduce nettamente la superficie di attacco, ma porta con sé limiti e obblighi propri.
- [Pentest, bug bounty o scansione delle vulnerabilità? Scegliere la verifica giusta](https://phpsos.de/it/blog/pentest-bugbounty-scan/): Scansione, penetration test e bug bounty verificano i siti in modi molto diversi. Che cosa offre ciascun metodo, dove fallisce e quale ordine si adatta alla Sua azienda.