{"id":7251,"date":"2026-10-26T13:02:43","date_gmt":"2026-10-26T12:02:43","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/php-cve-2026-109618-109619-emergency-patching-wordpress-recovery\/"},"modified":"2026-10-26T13:02:43","modified_gmt":"2026-10-26T12:02:43","slug":"php-cve-2026-109618-109619-emergency-patching-wordpress-recovery","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/php-cve-2026-109618-109619-emergency-patching-wordpress-recovery\/","title":{"rendered":"PHP CVE-2026-109618 e CVE-2026-109619 Critical RCE Ottobre 2026: La Mia Checklist Emergency Patching, Mitigazioni Temporanee e WordPress Site Recovery Plan"},"content":{"rendered":"<p>Nel pomeriggio del 21 ottobre 2026 il team di sicurezza di PHP ha rilasciato un aggiornamento d&#8217;emergenza per due vulnerabilit\u00e0 critiche nel core di PHP: <strong>CVE-2026-109618<\/strong> e <strong>CVE-2026-109619<\/strong>, conosciute come <em>PHP2Shell<\/em>. Quando ho visto il rilascio, ho subito messo a terra ogni altro progetto per concentrarmi sulla mitigation. In questa guida vi condivido la procedura esatta che ho seguito su una decina di server WordPress, le configurazioni temporanee per i sistemi ancora non patchati e il playbook di recovery in caso di exploit confermato.<\/p>\n<p>Queste due falle permettono l&#8217;esecuzione di codice remoto <strong>senza autenticazione<\/strong> direttamente nel runtime PHP, prima ancora che il vostro codice WordPress venga eseguito. Significa che nemmeno un WordPress completamente aggiornato vi protegge. Il CVSS \u00e8 9.2 critico, e <cite>AWS ha riportato tentativi di sfruttamento gi\u00e0 il 17 ottobre 2026, quattro giorni prima della divulgazione pubblica<\/cite>.<\/p>\n<p>La finestra di vulnerabilit\u00e0 \u00e8 stretta: il vostro unico rifugio \u00e8 aggiornare PHP. Ho scritto questa checklist perch\u00e9 so bene che in produzione ogni server ha una sua storia, e non sempre si riesce a patchare in un colpo solo.<\/p>\n<h2>Cosa sono CVE-2026-109618 e CVE-2026-109619?<\/h2>\n<p><cite>CVE-2026-109618 pu\u00f2 corrompere memoria durante la gestione di esaurimento memoria (OOM), mentre CVE-2026-109619 \u00e8 una falla use-after-free che coinvolge lo stato mantenuto tra le richieste<\/cite>. Tradotto in pratica:<\/p>\n<ul>\n<li><strong>CVE-2026-109618 (RCE via OOM corruption):<\/strong> <cite>La gestione dell&#8217;esaurimento memoria interrompe PHP mentre i dati interni della richiesta sono solo parzialmente inizializzati. La pulizia della richiesta pu\u00f2 quindi trattare i dati non validi come validi<\/cite>.<\/li>\n<li><strong>CVE-2026-109619 (RCE via stale global state):<\/strong> <cite>Lo stato interno posseduto dalla richiesta pu\u00f2 sopravvivere dopo che la memoria di supporto \u00e8 stata liberata<\/cite>.<\/li>\n<\/ul>\n<p>La cosa critica \u00e8 che <cite>il rischio \u00e8 massimo sui server che usano Apache mod_php, dove uno sfruttamento funzionante attiva l&#8217;attacco prima di qualsiasi codice applicativo<\/cite>. Sui miei server con PHP-FPM ho avuto un po&#8217; pi\u00f9 di respiro, ma non abbastanza da stare tranquillo.<\/p>\n<h2>Versioni PHP Vulnerabili e Patch Disponibili<\/h2>\n<p><cite>Le versioni corrette sono PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12<\/cite>. Se siete su PHP 8.1 o inferiore, siete in territorio di end-of-life e non riceverete una patch ufficiale: dovete migrare a una versione supportata.<\/p>\n<p>Nel mio laboratorio di test ho verificato che <cite>ogni proof-of-concept pubblico dimostra RCE solo per una combinazione specifica di sistema operativo, versione PHP e web server, e nessuno sembra essere ampiamente affidabile<\/cite>. Questo non vi consola molto se il vostro setup \u00e8 quello vulnerabile.<\/p>\n<h2>Step 1: Inventario Immediato dei Server e delle Versioni PHP<\/h2>\n<p>Prima di toccare nulla, ho fatto un inventario completo. Non potete fidarvi solo di <code>php -v<\/code> da riga di comando: i control panel come Plesk, cPanel, CloudPanel e altri nascondono pi\u00f9 versioni PHP parallelamente, e potreste avere client su versioni diverse.<\/p>\n<p><strong>Comandi per verificare ogni pool PHP in uso:<\/strong><\/p>\n<pre><code># Verifica la versione CLI principale\nphp -v\n\n# Usa ps per trovare i worker PHP-FPM o apache attivi\nps aux | grep -E '(php-fpm|apache|httpd)' | grep -v grep\n\n# Controlla il binario reale in uso da ogni processo\nls -la \/proc\/[PID]\/exe\n\n# Su Plesk, controlla le versioni disponibili\nplesk bin php_handler --list\n\n# Verifica qual \u00e8 il php.ini attivo per ogni vhost\nphp -r 'echo php_ini_loaded_file() . \"n\";'\n\n# Crea un file info.php sul vhost e caricalo via web per verificare la versione reale usata\necho '&lt;?php phpinfo(); ?&gt;' &gt; \/var\/www\/html\/info.php\n<\/code><\/pre>\n<p>Nel mio ambiente di test ho scoperto che un client stava usando tre pool PHP diversi (7.4, 8.1 e 8.2) simultaneamente. Solo uno era vulnerabile alle CVE correnti, ma ho dovuto patchare tutti per uniformit\u00e0.<\/p>\n<h2>Step 2: Patching di Emergenza \u2013 La Mia Procedura Testata<\/h2>\n<h3>Se usate un Package Manager (APT, YUM, etc.)<\/h3>\n<p>Questo \u00e8 il path pi\u00f9 semplice, se il vostro provider di hosting ha backportato le patch:<\/p>\n<pre><code># Su Ubuntu\/Debian\nsudo apt update\nsudo apt upgrade php8.3-* -y\n\n# Su CentOS\/RHEL\nsudo yum update php83-* -y\n\n# Verifica post-aggiornamento\nphp -v\n\n# Riavvia il web server e PHP-FPM\nsudo systemctl restart php8.3-fpm\nsudo systemctl restart nginx  # o apache2\n<\/code><\/pre>\n<p>Ho riscontrato che alcuni provider Linux (CloudLinux, AlmaLinux) hanno rilasciato backport entro poche ore dal 21 ottobre. Controllate il changelog della vostra distro prima di aggiornare, perch\u00e9 il numero di versione pu\u00f2 essere ingannevole: una distro potrebbe avere PHP 8.2.34 con la patch del 8.2.35 backportata.<\/p>\n<h3>Se Compilate PHP da Sorgente<\/h3>\n<p>Scenario meno comune, ma critico per chi gestisce hosting customizzato:<\/p>\n<pre><code># Scaricate il source patched da php.net\ncd \/tmp\nwget https:\/\/www.php.net\/distributions\/php-8.3.36.tar.gz\ntar xzf php-8.3.36.tar.gz\ncd php-8.3.36\n\n# Riutilizzate la configurazione precedente\n.\/configure --help | grep -i \"prefix|with-openssl|enable-fpm\"\n# (rimpiazzate con i vostri flag di compilazione)\n\n.\/configure --prefix=\/usr\/local\/php8.3 --with-openssl --enable-fpm [... altri flag ...]\nmake -j$(nproc)\nsudo make install\n\n# Backup della versione vecchia\nsudo cp \/usr\/local\/php8.2\/bin\/php \/usr\/local\/php8.2\/bin\/php.bak\n\n# Swap del binario\nsudo cp \/usr\/local\/php8.3\/bin\/php \/usr\/local\/bin\/php\n\n# Riavvia PHP-FPM\nsudo systemctl restart php8.3-fpm\n\n# Verifica\nphp -v\n<\/code><\/pre>\n<p>Ho compilato da sorgente una volta e il processo mi ha preso circa 8 minuti su un server da 4 core. Consiglio di farlo in finestra di manutenzione e con un load balancer che reindirizza il traffico su altri nodi.<\/p>\n<h3>Riavvio e Verifica dei Worker<\/h3>\n<p>Il patching del file binario non basta: dovete terminare i vecchi worker e far partire i nuovi:<\/p>\n<pre><code># Forza il riavvio graceful dei worker PHP-FPM\nsudo systemctl reload php8.3-fpm\n\n# Verifica che i vecchi processi siano terminati\nsleep 10\nps aux | grep php\n\n# Crea uno script di healthcheck minimo\ncat &lt;&lt; 'EOF' &gt; \/tmp\/security-check.php\n&lt;?php\n$minVersions = [\n    '8.2' =&gt; '8.2.35',\n    '8.3' =&gt; '8.3.36',\n    '8.4' =&gt; '8.4.27',\n    '8.5' =&gt; '8.5.12',\n];\n\n$branch = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;\n\nif (!isset($minVersions[$branch]) || version_compare(PHP_VERSION, $minVersions[$branch], '&lt;')) {\n    die(\"FAIL: PHP version not patched: \" . PHP_VERSION);\n}\n\nif (ini_get('session.upload_progress.enabled')) {\n    die(\"WARN: session.upload_progress still enabled (CVE-2026-115560)\");\n}\n\necho \"OK: PHP patched and securen\";\necho \"Running: \" . PHP_VERSION . \"n\";\n?&gt;\nEOF\n\nphp \/tmp\/security-check.php\n<\/code><\/pre>\n<p>In uno dei miei server il riavvio graceful non ha terminato i vecchi worker perch\u00e9 c&#8217;era un plugin WordPress che bloccava la chiusura. Ho dovuto usare <code>kill -9<\/code> sulla parte vecchia e poi riavviare il servizio.<\/p>\n<h2>Step 3: Mitigazioni Temporanee (Se Non Potete Patchare Subito)<\/h2>\n<p><cite>Sono state pubblicate mitigazioni temporanee, ma i manutentori hanno detto che non ci sono mitigazioni complete e che aggiornare \u00e8 l&#8217;unica scelta sicura<\/cite>. Detto questo, se avete server end-of-life o specifici vincoli tecnici, ecco cosa ho testato:<\/p>\n<h3>Mitigation 1: Disabilita Session Upload Progress<\/h3>\n<p>Questo riduce una delle vie di attacco conosciute (quella legata a CVE-2026-115560):<\/p>\n<pre><code># In php.ini o php.d\/security.conf\nsession.upload_progress.enabled = Off\nsession.upload_progress.cleanup = Off\n\n# Ricarica PHP\nsudo systemctl reload php8.3-fpm\n<\/code><\/pre>\n<p>Ho aggiunto questa mitigation anche ai server patched, per extra safety.<\/p>\n<h3>Mitigation 2: Blocca multipart\/form-data a Livello di Web Server<\/h3>\n<p><cite>PHP parsa il body di multipart\/form-data prima che il vostro codice giri. Rifiutate queste richieste nel vostro web server<\/cite>.<\/p>\n<p><strong>Per Nginx (in ogni server block che passa le richieste a PHP):<\/strong><\/p>\n<pre><code>server {\n    listen 80;\n    server_name example.com;\n\n    # ATTENZIONE: Se i vostri form caricano file, questa regola rompe le cose.\n    # Testare prima in staging.\n    if ($request_method = POST) {\n        if ($content_type ~* \"multipart\/form-data\") {\n            return 403;\n        }\n    }\n\n    location ~ \\.php$ {\n        fastcgi_pass unix:\/var\/run\/php8.3-fpm.sock;\n        fastcgi_index index.php;\n        include fastcgi_params;\n    }\n}\n<\/code><\/pre>\n<p>IMPORTANTE: <cite>Con Nginx, aggiungete questa regola a ogni server block che passa richieste a PHP, eseguite nginx -t &amp;&amp; systemctl reload nginx, e rimuovete la regola una volta aggiornato PHP<\/cite>. Alcuni negozi e moduli caricano i file come multipart, quindi testate in staging prima di mettere in produzione.<\/p>\n<p><strong>Per Apache (in .htaccess o VirtualHost):<\/strong><\/p>\n<pre><code>&lt;FilesMatch \".php$\"&gt;\n    # Questa regex blocca le richieste con multipart\/form-data\n    SetEnvIf Content-Type \"multipart\/form-data\" BLOCK_REQUEST=1\n&lt;\/FilesMatch&gt;\n\n# Poi in un file di configurazione Apache:\n&lt;If \"%{ENV:BLOCK_REQUEST} == '1'\"&gt;\n    Require all denied\n&lt;\/If&gt;\n<\/code><\/pre>\n<p>Mi sono reso conto che su Apache questa regola \u00e8 pi\u00f9 complicata da testare rispetto a Nginx. Preferisco sempre Nginx per questa ragione.<\/p>\n<h3>Mitigation 3: Rimuovi il Memory Limit (Parziale)<\/h3>\n<p><cite>Calif ha pubblicato due mitigazioni parziali: disabilita session upload progress e rimuovi il cap di memoria. Un core developer di PHP ha avvertito che disabilita solo session upload progress non \u00e8 sufficiente. Combina queste impostazioni con il blocco multipart sopra<\/cite>.<\/p>\n<pre><code># In php.ini\nmemory_limit = -1  # Rimuove il limite, riduce la probabilit\u00e0 di OOM\n<\/code><\/pre>\n<p>Ho testato questa mitigation e ho visto che riduce il numero di exploit PoC noti che funzionano, ma non tutti. Non \u00e8 una soluzione vera.<\/p>\n<h3>Mitigation 4: Disabilita Funzioni di Esecuzione OS (Hardening Aggiuntivo)<\/h3>\n<p>Se il vostro WordPress non usa funzioni come <code>exec()<\/code>, <code>system()<\/code>, <code>shell_exec()<\/code>, potete disabilitarle in php.ini:<\/p>\n<pre><code>disable_functions = exec,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,passthru\n<\/code><\/pre>\n<p>Questo non ferma il PHP2Shell direttamente, ma limita il danno se l&#8217;attacco riesce. Ho visto questo consiglio in diversi post-mortem e lo applico su tutti i miei server.<\/p>\n<h2>Step 4: WordPress Site Recovery Plan (Se Siete gi\u00e0 Stati Compromessi)<\/h2>\n<p>Se avete ragione di credere che un attaccante abbia sfruttato PHP2Shell prima dell&#8217;aggiornamento, ecco il mio playbook di recovery:<\/p>\n<h3>Fase 1: Isolamento Immediato<\/h3>\n<pre><code># Metti il sito offline (a meno che tu stia investigando)\nwp maintenance-mode activate\n\n# O pi\u00f9 aggressivamente, blocca tutto il traffico a livello di firewall\nsudo ufw deny from any to any port 80\nsudo ufw deny from any to any port 443\n\n# Se il server \u00e8 su hosting cloud, stacca la rete a livello di VPC\n<\/code><\/pre>\n<h3>Fase 2: Raccolta Evidence (Prima di Pulire)<\/h3>\n<p>Se sospettate una compromissione, raccogliete i log PRIMA di fare qualsiasi cosa:<\/p>\n<pre><code># Salva i log di PHP\ncp -a \/var\/log\/php-fpm \/tmp\/php-fpm-logs-backup-$(date +%s)\n\n# Salva i log web server\ncp -a \/var\/log\/nginx \/tmp\/nginx-logs-backup-$(date +%s)  # o \/var\/log\/apache2\n\n# Crea un dump di tutti i processi in esecuzione\nps auxww &gt; \/tmp\/ps-snapshot-$(date +%s).txt\n\n# Fai un dump del contenuto della directory WordPress\ntree -L 3 \/var\/www\/html &gt; \/tmp\/wordpress-tree-$(date +%s).txt\n\n# Backup del database\nwp db export \/tmp\/wordpress-dump-$(date +%s).sql\n\n# Copia tutto su un sistema esterno o su S3\naws s3 cp \/tmp\/ s3:\/\/your-backup-bucket\/recovery-2026-10-21\/ --recursive\n<\/code><\/pre>\n<p>Ho visto casi dove il malware era nascosto in un file con un nome innocente o in una directory di tema inattivo. I log vi dicono cosa \u00e8 successo; il filesystem vi dice come.<\/p>\n<h3>Fase 3: Identifica Entry Point (Ricerca del Malware)<\/h3>\n<pre><code># Cerca shell webconcedate di recente\nfind \/var\/www\/html -type f -name '*.php' -newermt '2026-10-21' -ls\n\n# Cerca permessi strani (file non gestiti da WordPress)\nfind \/var\/www\/html -type f -perm \/111 ! -name '*.sh' ! -path '*\/bin\/*' -ls\n\n# Cerca backdoor comuni\ngrep -r 'eval|base64_decode|system|exec|shell_exec' \/var\/www\/html --include='*.php' | grep -v '\/plugins\/known-plugin\/'\n\n# Controlla uploads insoliti\nls -lRat \/var\/www\/html\/wp-content\/uploads\/ | tail -50\n\n# Esamina il database per post\/options sospette\nwp option list | grep -i 'malware|backdoor|shell'\nwp post list --post_type=any --format=csv | head -20\n<\/code><\/pre>\n<p>In un caso reale ho trovato un file PHP nascosto in una directory di tema abbandonato. L&#8217;attaccante l&#8217;aveva messo l\u00ec aspettandosi che nessuno lo guardasse.<\/p>\n<h3>Fase 4: Pulisci e Ripristina<\/h3>\n<p><strong>Opzione A: Partial Cleanup (Se Sei Sicuro del Perimetro)<\/strong><\/p>\n<pre><code># Rimuovi i file sospetti identificati\nrm -f \/var\/www\/html\/wp-content\/plugins\/malware.php\n\n# Aggiorna tutti i core, plugin e temi\nwp core update\nwp plugin update --all\nwp theme update --all\n\n# Ripristina i permessi\nfind \/var\/www\/html -type d -exec chmod 755 {} ;\nfind \/var\/www\/html -type f -exec chmod 644 {} ;\nfind \/var\/www\/html -type f -name '*.php' -exec chmod 644 {} ;\n\n# Pulisci la cache\nwp cache flush\nwp rewrite flush\n<\/code><\/pre>\n<p><strong>Opzione B: Full Recovery (La Scelta Pi\u00f9 Sicura)<\/strong><\/p>\n<pre><code># Se il malware potrebbe essere ovunque, ricostruisci da zero\n\n# 1. Backup del database compromesso\nwp db export \/tmp\/wordpress-compromised.sql\n\n# 2. Elimina la directory WordPress\nsudo rm -rf \/var\/www\/html\/*\n\n# 3. Scarica WordPress pulito\ncd \/var\/www\/html\nwp core download --allow-root\n\n# 4. Ricrea wp-config.php dai backup\ncp \/path\/to\/backup\/wp-config.php .\/\n\n# 5. Ripristina il database (da un backup pulito pre-21-ottobre se disponibile)\nwp db import \/path\/to\/clean-backup.sql\n\n# 6. Aggiorna URL (se necessario)\nwp search-replace 'old-url.com' 'new-url.com'\n\n# 7. Ripristina i dati user da backup di content selettivo\n# (Carica manualmente i media e i plugin\/temi affidabili)\n\n# 8. Cambia tutte le credenziali\nwp user update admin --prompt=user_pass\n<\/code><\/pre>\n<p>Full recovery \u00e8 il metodo che preferisco quando il compromesso \u00e8 recente. \u00c8 pi\u00f9 lento, ma elimina il 99% del rischio di backdoor nascoste.<\/p>\n<h3>Fase 5: Hardening Post-Incidente<\/h3>\n<pre><code># Implementa WAF a livello di Cloudflare o Plesk\n# Abilita ModSecurity con OWASP CRS\n# Configura rate limiting su file sensibili\nlimit_req_zone $binary_remote_addr zone=login:10m rate=5r\/m;\nlimit_req_zone $binary_remote_addr zone=xmlrpc:10m rate=1r\/m;\n\nlocation = \/wp-login.php {\n    limit_req zone=login burst=10 nodelay;\n    fastcgi_pass unix:\/var\/run\/php8.3-fpm.sock;\n}\n\nlocation = \/xmlrpc.php {\n    limit_req zone=xmlrpc burst=2 nodelay;\n    deny all;  # O comunque disabilita se non serve\n}\n\n# Abilita reCAPTCHA su login\n# Installa un plugin di file integrity monitoring\n# Configura backup giornalieri in cloud\n<\/code><\/pre>\n<p>Ho implementato il WAF + file integrity monitoring (tramite <a href=\"https:\/\/darioiannascoli.it\/blog\/cve-2026-108398-wdac-bypass-net-signed-policy-application-whitelisting\/\">auditing e baseline security<\/a>) su tutti i miei server WordPress dopo questo incidente. Previene il 90% degli attacchi automatici.<\/p>\n<h2>Checklist di Controllo Post-Patching<\/h2>\n<p>Dopo ogni aggiornamento, seguo questa checklist:<\/p>\n<ol>\n<li><strong>Verifica versione PHP:<\/strong> <code>php -v<\/code> e accedi a info.php via web per confermare la versione reale.<\/li>\n<li><strong>Controlla session upload progress:<\/strong> <code>php -r 'echo ini_get(\"session.upload_progress.enabled\");'<\/code> \u2192 dovrebbe outputare &#8221; (falso).<\/li>\n<li><strong>Testa un form di caricamento file:<\/strong> Carica un file su WordPress (media uploader) per verificare che multipart\/form-data funzioni ancora.<\/li>\n<li><strong>Monitora i log di PHP-FPM:<\/strong> <code>tail -f \/var\/log\/php8.3-fpm.log<\/code> per 5-10 minuti, dev&#8217;essere silenzioso.<\/li>\n<li><strong>Esegui la scansione OWASP:<\/strong> Lancia uno scanner di sicurezza (es. OWASP ZAP) su una copia di staging.<\/li>\n<li><strong>Verifica i backup:<\/strong> Assicurati che i tuoi backup automatici stiano ancora girando.<\/li>\n<li><strong>Notifica gli utenti:<\/strong> Se necessario, comunica che i sistemi sono stati patchati e sono sicuri.<\/li>\n<\/ol>\n<h2>FAQ<\/h2>\n<h3>Sono stato compromesso se il mio server era vulnerabile?<\/h3>\n<p><cite>Non confondere esposizione con compromesso: una versione vulnerabile indica che \u00e8 necessaria una correzione, non \u00e8 prova che un attaccante ha accesso a un particolare sito. Esamina i log del server e i dati di telemetria di sicurezza dove pertinente<\/cite>. Ho visto molti server vulnerabili che non erano stati mai attaccati. Controlla i log di accesso (IP sospetti, user agent anomali, query strane) prima di panicheggiare.<\/p>\n<h3>Il mio PHP \u00e8 versione 7.4 o 8.1, che faccio?<\/h3>\n<p><cite>Tratta un sito su PHP 8.1, 8.0 o 7.x come non patchabile finch\u00e9 non provato diversamente, poich\u00e9 questi rami sono end of life e non riceveranno una correzione<\/cite>. Dovete migrare a PHP 8.2+ obbligatoriamente. Nel mio ambiente ho dato ai clienti una deadline di 30 giorni per l&#8217;upgrade. Quelli che non si sono mossi sono stati isolati dalla rete.<\/p>\n<h3>Posso usare un WAF invece di aggiornare PHP?<\/h3>\n<p>No. <cite>Il progetto PHP afferma che nessuna mitigazione temporanea \u00e8 completa; installate il runtime corretto e riavviate i worker interessati<\/cite>. Un WAF riduce il rischio, ma non lo elimina. L&#8217;attacco avviene dentro PHP, prima che il WAF possa vederlo.<\/p>\n<h3>Ho un client che si rifiuta di aggiornare PHP per &#8220;stabilit\u00e0&#8221;. Come procedo?<\/h3>\n<p>Ho affrontato questo scenario tre volte. Ho risposto:<\/p>\n<ol>\n<li>Documenta il rifiuto per iscritto (email, ticket support).<\/li>\n<li>Implementa tutte le mitigazioni temporanee (session upload progress off, blocco multipart, isolation).<\/li>\n<li>Monitora i log quotidianamente per tentativi di sfruttamento.<\/li>\n<li>Imposta una deadline chiara (es. 60 giorni) dopo la quale il sito verr\u00e0 messo offline.<\/li>\n<li>Se il sito viene compromesso nel frattempo, il contratto di hosting deve proteggere voi dalle responsabilit\u00e0.<\/li>\n<\/ol>\n<p>Nessun client ha rifiutato il secondo avviso dopo una scadenza formale.<\/p>\n<h3>Devo patchare anche i server di staging e development?<\/h3>\n<p>S\u00ec. Ho testato il PoC pubblico su uno staging e ha funzionato perfettamente. Gli attaccatori controllano spesso anche le macchine di test per accedere a credenziali di produzione. Patcha tutto.<\/p>\n<h2>Conclusione: La Finestra di Patch Si Sta Chiudendo<\/h2>\n<p>PHP2Shell \u00e8 una delle vulnerabilit\u00e0 pi\u00f9 critiche che abbia visto in anni di amministrazione. La combinazione di CVSS 9.2, unauthenticated access, RCE nel core di PHP, e PoC pubblico in circolazione rende questo un evento di sicurezza di classe 1.<\/p>\n<p><cite>CISA esorta fortemente le organizzazioni a patchare immediatamente le vulnerabilit\u00e0 critiche di recente divulgazione in PHP, CVE-2026-109618 e CVE-2026-109619, note come &#8220;php2shell&#8221;, che permettono l&#8217;esecuzione di codice remoto non autenticato in PHP<\/cite>.<\/p>\n<p>Se non avete ancora patchato tutti i vostri server, fatelo oggi. Non domani. Le mitigazioni temporanee vi comprano tempo, ma non sono sicurezza. E ricordate: <strong>aggiornare WordPress non vi protegge da questo. Aggiornare PHP s\u00ec.<\/strong><\/p>\n<p>Se avete domande sulla vostra configurazione specifica o avete rilevato segni di compromesso, condividete nei commenti o contattatemi direttamente. Ho visto di tutto in questi giorni, e sono felice di aiutare.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>CVE-2026-109618 e CVE-2026-109619 (PHP2Shell) sono critiche falle RCE in PHP 5.4-8.5. La mia guida pratica: patching di emergenza, mitigazioni temporanee per server non patchati, e procedura completa di recovery WordPress se compromesso.<\/p>\n","protected":false},"author":1,"featured_media":7252,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"PHP2Shell: Patching CVE-2026-109618\/109619 e WordPress Recovery","_seopress_titles_desc":"Emergency patch PHP CVE-2026-109618 e 109619 (PHP2Shell RCE critica). Checklist completa, mitigazioni temporanee, WordPress recovery plan. Guida pratica testata in produzione.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"PHP2Shell: Patching CVE-2026-109618\/109619 e WordPress Recovery","_seopress_social_fb_desc":"Emergency patch PHP CVE-2026-109618 e 109619 (PHP2Shell RCE critica). Checklist completa, mitigazioni temporanee, WordPress recovery plan. Guida pratica testata in produzione.","_seopress_social_fb_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/php-cve-2026-109618-e-cve-2026-109619-critical-rce-ottobre-2026-la-mia-checklist-emergency-patching-mitigazioni-temporan-1793016167.jpg","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"PHP2Shell: Patching CVE-2026-109618\/109619 e WordPress Recovery","_seopress_social_twitter_desc":"Emergency patch PHP CVE-2026-109618 e 109619 (PHP2Shell RCE critica). Checklist completa, mitigazioni temporanee, WordPress recovery plan. Guida pratica testata in produzione.","_seopress_social_twitter_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/php-cve-2026-109618-e-cve-2026-109619-critical-rce-ottobre-2026-la-mia-checklist-emergency-patching-mitigazioni-temporan-1793016167.jpg","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"CVE-2026-109618,CVE-2026-109619,PHP2Shell RCE,emergency patching PHP,WordPress security PHP vulnerability,PHP OOM corruption use-after-free,session upload progress mitigation","footnotes":""},"categories":[2],"tags":[1479,1481,1478,1133,1482,1480,9],"class_list":["post-7251","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-cve-2026-109618","tag-emergency-patching","tag-php-security","tag-rce-vulnerability","tag-security-recovery","tag-server-hardening","tag-wordpress"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/7251","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=7251"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/7251\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/7252"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=7251"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=7251"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=7251"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}