# PHP2Shell: due falle di PHP su metà dei siti analizzati Source: [Home](https://www.nfw.run/)[Articoli](https://www.nfw.run/articoli) // articolo Pubblicato: 22 ottobre 2026Aggiornato: 23 ottobre 2026Scritto da [Enrico Pasetto](https://www.linkedin.com/in/enrico-pasetto) () - [Sicurezza](https://www.nfw.run/articoli/argomento/sicurezza) - [Stato del web](https://www.nfw.run/articoli/argomento/stato-del-web) ![PHP2Shell: il 49,8% dei siti che abbiamo analizzato usa PHP, con una finestra di terminale arancione che mostra il tag di apertura di PHP](https://www.nfw.run/blog/php2shell-php-vulnerability/cover-it.webp) ## In breve: cosa significa per la tua attività PHP è il motore dietro circa la metà dei siti aziendali che analizziamo. Ogni sito WordPress funziona con PHP. Nel mondo, PHP fa girare circa sette siti su dieci tra quelli di cui si conosce il linguaggio ([W3Techs](https://w3techs.com/technologies/details/pl-php)). Questa settimana sono state rese pubbliche e corrette due falle gravi di PHP. Su un sito non aggiornato, in alcune configurazioni, uno sconosciuto potrebbe prenderne il controllo senza conoscere alcuna password. Qualcuno ha provato a sfruttarle già prima che uscisse la correzione, ma finora non è stata pubblicata nessuna compromissione confermata. La soluzione è un aggiornamento. Lo installa il tuo fornitore di hosting o chi gestisce il sito. Richiede poco tempo, ma qualcuno deve farlo. Negli stessi giorni sono arrivati aggiornamenti urgenti anche per Node.js e per GitLab, e una settimana prima per Nginx, il web server dietro circa un quarto dei siti che analizziamo. La piattaforma di hosting Railway ha inoltre segnalato una violazione dei segreti che i clienti vi conservano: se il tuo sviluppatore o il tuo hosting ne usa qualcuno, chiedi anche di questi. Tre cose da fare oggi: 1. **Chiedi al tuo hosting o al tuo sviluppatore se PHP è stato aggiornato dal 21 ottobre 2026 in poi.** Se la risposta è sì, sei a posto. Se non lo sanno, chiedi di controllare. 1. **Se il sito è vecchio, chiedi di portarlo su una configurazione attuale.** Molti siti usano ancora PHP 7, e la 7.4, l'ultima versione 7.x, ha raggiunto la fine del supporto il 28 novembre 2022. PHP 7, 8.0 e 8.1 non ricevono una versione corretta ufficiale: per la 7.4, la 8.0 e la 8.1 esistono backport del codice, e alcuni fornitori e distribuzioni Linux li applicano, ma se il tuo hosting non lo fa la falla resta aperta. È come una vecchia serratura di cui il produttore non vende più i pezzi. 1. **Fai l'[audit SEO gratuito](https://www.nfw.run/audit-seo).** Elenca le tecnologie che il tuo sito mostra all'esterno, ma non i numeri di versione, di proposito, per evitare possibili abusi. Se vuoi sapere quale versione usa il tuo sito, scrivici a e vediamo come agire. **Separatamente, controlla che anche WordPress sia aggiornato (la 7.1.3, o l'ultima versione del tuo ramo).** PHP2Shell è una falla di PHP stesso: aggiornare WordPress, plugin o temi non la risolve. Vedi la sezione su WordPress più sotto. Continua a leggere per i dettagli tecnici. ## Cosa è successo e quando PHP è un software open source e chi lo mantiene pubblica gli avvisi di sicurezza su GitHub. Wiz, una società di sicurezza, ha trovato la prima falla il 19 agosto 2026 e le ha segnalate entrambe al team di sicurezza di PHP il 24 agosto ([Wiz](https://www.wiz.io/blog/php2shell-php-rce)). I dettagli dovevano essere resi noti il 22 ottobre, ma sono trapelati prima. Il progetto PHP ha pubblicato le versioni corrette il 21 ottobre. Sullo sfruttamento i resoconti non concordano. Amazon ha registrato un tentativo su un suo honeypot, un server civetta predisposto per attirare gli attaccanti, il 17 ottobre, prima della divulgazione, e parla di falle sfruttate su larga scala. watchTowr, un'altra società di sicurezza, vede tentativi di sfruttamento di entrambe le falle sui propri honeypot ([watchTowr](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/)). Ma la PHP Foundation non ha trovato nessun exploit funzionante al momento del rilascio, e la CISA, l'agenzia americana per la cybersicurezza, il 21 ottobre ha dichiarato di non aver osservato sfruttamenti ([Tenable](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote)). Non è stata pubblicata nessuna compromissione confermata: Sophos ne ha segnalata una il 22 ottobre, poi l'ha ritirata la sera stessa, dicendo che i suoi dati mostrano scansioni e pochi tentativi falliti. Da allora [Rapid7](https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/) segnala diverse dimostrazioni pubbliche: ciascuna funziona solo con una combinazione precisa di sistema operativo, versione di PHP e web server, nessuna sembra affidabile in generale, e i tentativi di Rapid7 sono riusciti solo in condizioni di laboratorio molto strette. Un toolkit pubblico su GitHub (non linkiamo codice di attacco) sfrutta la catena tramite la funzione `session.upload_progress` di PHP su Apache con mod\_php. Al momento in cui scriviamo nessuna delle due falle compare nell'elenco americano delle vulnerabilità note e sfruttate. Wiz, la società che le ha trovate, le ha pubblicate con il nome PHP2Shell. Le due falle sono [CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) e [CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp). Ognuna vale 9,2 su 10 nella scala CVSS v4, la scala standard di gravità delle vulnerabilità. ## Cosa sono le due falle Entrambe permettono a un attaccante remoto di eseguire codice sul server. Entrambe funzionano senza autenticazione, via rete, prima ancora che parta il codice del sito. - **CVE-2026-109618, un errore di memoria che corrompe una richiesta.** Se PHP esaurisce la memoria mentre sta ancora preparando i dati di una richiesta, la preparazione si interrompe a metà. La pulizia che segue tratta quei dati incompleti come validi e un attaccante può guidare quello che succede dopo. - **CVE-2026-109619, un puntatore a memoria già liberata.** PHP conserva un puntatore alla memoria di una richiesta anche dopo che quella memoria è stata liberata. Una richiesta successiva, gestita dallo stesso processo, può far usare quel puntatore a PHP, e chi controlla quella richiesta può trasformarlo nell'esecuzione del proprio codice. ## Chi è coinvolto Sono coinvolte tutte le versioni di PHP precedenti a 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Le fonti non concordano su fino a quale versione si risalga: per Wiz dalla 5.4 in poi, per watchTowr da PHP 5 in poi. Quanto al modo in cui PHP viene eseguito, solo mod\_php, che esegue PHP dentro il web server Apache, è confermato come pienamente sfruttabile con i limiti predefiniti. PHP-FPM (un gestore di processi PHP separato), FrankenPHP, LiteSpeed (LSAPI) e php-cgi sono probabilmente esposti, ma gli exploit per questi sono parziali o non dimostrati. Considerali a rischio finché non sono aggiornati. | Ramo di PHP | Versione corretta | Siti nelle nostre scansioni con quel ramo | | -------------------- | ------------------------------------------------------------- | ----------------------------------------- | | 8.5 | 8.5.12 | 254 | | 8.4 | 8.4.27 | 849 | | 8.3 | 8.3.36 | 1.783 | | 8.2 | 8.2.35 | 1.282 | | 8.1 | Nessuna: solo backport del codice, nessuna versione ufficiale | 995 | | 8.0 | Nessuna: solo backport del codice, nessuna versione ufficiale | 317 | | 7.4 | Nessuna: solo backport del codice, nessuna versione ufficiale | 1.948 | | 7.3 e 7.x precedenti | Nessuna: nessuna correzione | 840 | | 5.x | Nessuna: nessuna correzione | 643 | | 4.x | Nessuna: nessuna correzione | 4 | Un backport è una correzione riportata a mano in codice più vecchio. Alcuni fornitori e distribuzioni Linux li applicano ai rami qui sopra, quindi un sito su un ramo vecchio può comunque essere stato corretto dal suo hosting. ## Cosa dicono le nostre scansioni Ecco cosa dicono i nostri dati. Tra i siti scansionati dal 23 settembre al 22 ottobre 2026, contando l'ultima scansione riuscita di ogni sito che risponde con una pagina funzionante, abbiamo 61.024 siti funzionanti. Di questi, **30.393 usano PHP (49,8%)** e 25.002 sono WordPress (82,3%). Per città, 12.353 dei 27.415 siti del [report su Milano](https://www.nfw.run/stato-del-web/milano-citta) usano PHP (45,1%), e 2.137 dei 4.765 del [report su Verona](https://www.nfw.run/stato-del-web/verona-citta) (44,8%). La versione di PHP è visibile solo su 8.915 di questi siti (29,3%). L'altro 70,7% la nasconde. Per confronto, W3Techs ([pagina del 22 ottobre 2026](https://w3techs.com/technologies/details/pl-php)) segnala PHP sul 69,3% di tutti i siti di cui si conosce il linguaggio sul server, in calo dal 73,4% del 1º ottobre 2025. Nel nostro campione la quota è più alta: tra i 34.196 siti funzionanti in cui siamo riusciti a capire il linguaggio sul server (contando ASP.NET), 30.393 usano PHP, circa l'89%. Le due cifre non misurano la stessa cosa: il nostro campione è fatto soprattutto di piccole attività di città italiane, e il rilevamento passivo trova PHP più facilmente di altri linguaggi. Tra i siti in cui la versione è visibile: - **4.747 (53,2%) usano un ramo senza versione corretta ufficiale**: 7.x su 2.788 siti (31,3%, di cui la sola 7.4 è 1.948), 8.0 e 8.1 su 1.312 (14,7%), 5.x su 643 (7,2%) e 4.x su 4. - 4.168 (46,8%) usano un ramo supportato, dalla 8.2 alla 8.5, e tutti hanno bisogno dell'aggiornamento. Quanto al web server dei siti PHP, Apache ne gestisce 7.725 (25,4%), Nginx 7.392 (24,3%), LiteSpeed 2.722 (9,0%) e IIS 244 (0,8%). Su circa 12.300 (40,5%) non siamo riusciti a rilevare il server. Il caso confermato è mod\_php su Apache, ma Apache può eseguire anche PHP-FPM, e da fuori non riusciamo a distinguerli. Questi numeri vanno letti con cautela: - Il rilevamento è passivo e riguarda solo la home page. Non abbiamo provato la falla su nessun sito. - Una CDN (una rete di server posta davanti al sito) può nascondere PHP, quindi la quota reale potrebbe essere più alta. - Un PHP installato da una distribuzione Linux mantiene il vecchio numero di versione anche quando la correzione è stata riportata al suo interno. Il numero di versione non è una prova, né in un senso né nell'altro. - I 61.024 sono meno degli oltre 79.000 siti citati nei nostri report sulle città: quel numero conta tutti i siti che abbiamo raggiunto, questo conta una sola volta ogni sito funzionante, alla sua ultima scansione. ## Come risolvere **Se hai un sito.** Chiedi al tuo hosting o allo sviluppatore di aggiornare PHP su WordPress, cioè di aggiornare la versione di PHP del server (non WordPress stesso), oppure controllala nel pannello dell'hosting. Su Aruba, come su molti hosting, la versione di PHP si cambia dal pannello di controllo. Su un hosting gestito di solito se ne occupa il fornitore: conferma che l'abbia fatto. Se il sito è fermo a PHP 7, 8.0 o 8.1, il passaggio a una versione supportata è la vera soluzione, e se il sito è vecchio è il momento giusto per ripensarlo (vedi il nostro servizio di [restyling sito web](https://www.nfw.run/restyling-sito-web)). **Se gestisci server.** Aggiorna a 8.2.35, 8.3.36, 8.4.27 o 8.5.12. Se usi pacchetti della distribuzione o a supporto esteso, installa l'aggiornamento dalla distribuzione: riportano la correzione senza cambiare il numero di versione, quindi controlla il changelog del pacchetto e non la versione. Sui rami senza versione ufficiale, passa a uno supportato, oppure affidati a un fornitore che riporti la correzione. Finché non puoi aggiornare, questi passi riducono il rischio ma sono parziali e non sostituiscono l'aggiornamento. Ognuno richiede il riavvio di tutti i worker PHP per avere effetto. - imposta `memory_limit=-1` a livello di amministrazione: l'[avviso di PHP](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) lo indica come la principale mitigazione di configurazione, ma toglie il tetto di memoria, quindi abbinalo ai limiti qui sotto e, se puoi, a un limite di memoria sul container; - non usare limiti `RLIMIT_AS` o `RLIMIT_DATA`: fanno fallire le richieste di memoria e peggiorano il problema; - tieni prudente `post_max_size`, abbassa `max_input_nesting_level` e limita il numero di variabili in input; - blocca le richieste multipart (quelle usate per caricare file) dove il sito non le usa; - imposta `session.upload_progress.enabled=0` (l'exploit pubblico passa da quella funzione); - usa `pm.max_requests=1` su PHP-FPM se te lo puoi permettere; - su 8.5, imposta `fatal_error_backtraces=0`; - se usi Cloudflare, controlla le sue regole WAF (un WAF è un filtro davanti al sito che blocca le richieste dannose). Sono attive per impostazione predefinita su ogni piano che include il WAF, Free compreso. Sui piani a pagamento, controlla che il Managed Ruleset sia impostato su blocco e non solo su registrazione ([Cloudflare](https://blog.cloudflare.com/php-vulnerabilities-waf-protection)). È una soluzione tampone. Impostare `expose_php=Off` nasconde l'intestazione con la versione. È buona pratica, non una correzione. Se non puoi né aggiornare né applicare le mitigazioni temporanee, l'[NCSC](https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php) britannico consiglia di valutare di mettere il sistema offline finché non è completamente mitigato. ## Vulnerabilità di WordPress: quale versione usare PHP2Shell è una falla di PHP stesso, quindi a nostro avviso aggiornare WordPress, plugin o temi non la risolve: la risolve l'aggiornamento di PHP. Ma ogni sito WordPress funziona con PHP, e per la sicurezza di WordPress va tenuto aggiornato anche il core, perché il core ha avuto le sue falle quest'anno. **wp2shell, luglio 2026.** [CVE-2026-63030](https://wiz.io/blog/wp2shell-cve-2026-63030-cve-2026-60137), una confusione nell'endpoint batch dell'API REST, concatenata con CVE-2026-60137, una SQL injection nel parametro `author__not_in` di `WP_Query`, permette a un attaccante non autenticato di eseguire codice. Wordfence l'ha definita la prima esecuzione di codice da remoto critica e non autenticata nel core di WordPress da quasi dieci anni ([Wordfence](https://www.wordfence.com/blog/2026/07/wp2shell-aftermath-the-first-critical-unauthenticated-wordpress-core-rce-in-nearly-a-decade/)). È esposto anche un sito senza nessun plugin installato. - La catena completa riguarda le versioni dalla 6.9.0 alla 6.9.4 e dalla 7.0.0 alla 7.0.1. Le versioni dalla 6.8.0 alla 6.8.5 hanno solo la SQL injection, e le versioni precedenti alla 6.8 non sono colpite da wp2shell. - La correzione è arrivata il 17 luglio 2026 con la 7.0.2, la 6.9.5 e la 6.8.6, e WordPress.org ha forzato gli aggiornamenti automatici sui siti coinvolti. - Gli attacchi sono iniziati nel giro di poche ore dalla correzione, secondo Wordfence: ha visto la prima sonda sull'endpoint batch alle 23:29 UTC del 17 luglio e il primo tentativo di SQL injection alle 23:42 UTC, e il codice di dimostrazione ha circolato il 18 e il 19 luglio. Wiz ha visto gli attaccanti installare webshell, piccoli programmi che danno all'attaccante un accesso nascosto al sito. La CISA ha aggiunto entrambe le CVE al suo catalogo delle vulnerabilità note e sfruttate. - In attesa della correzione, la mitigazione era bloccare l'accesso anonimo a `/wp-json/batch/v1` e a `?rest_route=/batch/v1`. **WordPress 7.1.3, 6 ottobre 2026.** Il [rilascio](https://wordpress.org/news/2026/10/wordpress-7-1-3-maintenance-and-security-release/) contiene sette correzioni di sicurezza: XSS memorizzato nella pagina dei commenti dell'amministrazione tramite i commenti in attesa, un denial of service in `WP_Http::make_absolute_url()`, una SQL injection nell'esportazione WXR che scatta in un secondo passaggio, gli Autori che potevano rendere un articolo in evidenza, la divulgazione senza autenticazione dei commenti su articoli privati e non pubblicati, XSS negli embed di Imgur e una collisione tra nomi di azione nell'hook `{status}_{type}`. Non sono elencate CVE e non risultano sfruttamenti. Lo stesso giorno è uscita la 7.0.7, e i backport (correzioni riportate nei rami più vecchi) arrivano a ogni ramo ancora idoneo, oggi fino alla 4.7. Solo l'ultima versione di WordPress è supportata ufficialmente. Le correzioni di sicurezza vengono riportate per cortesia fino alla 4.7. Le versioni dalla 4.1 alla 4.6 [non ricevono più correzioni da luglio 2025](https://make.wordpress.org/security/2025/06/18/security-updates-will-cease-for-wordpress-versions-4-1-through-4-6/), quelle dalla 3.7 alla 4.0 dal 1º dicembre 2022. Qualsiasi versione precedente alla 4.7 non riceve nessuna correzione. L'ultima versione di WordPress è la 7.1.3; per ogni ramo, questa è la versione da installare: | Ramo di WordPress | Stato | Versione da installare | | ------------------- | --------------------- | ----------------------------------------------------------------------- | | 7.1 | Attuale | 7.1.3 | | 7.0 | Backport per cortesia | 7.0.7 | | 6.9 | Backport per cortesia | Almeno la 6.9.5 per wp2shell; l'ultima 6.9 per le correzioni di ottobre | | 6.8 | Backport per cortesia | Almeno la 6.8.6 per wp2shell; l'ultima 6.8 per le correzioni di ottobre | | Dalla 4.7 alla 6.7 | Backport per cortesia | L'ultima versione del ramo, meglio passare alla 7.1 | | Precedenti alla 4.7 | Nessuna correzione | Passa alla 7.1 | **Cosa fare.** Devi aggiornare WordPress alla 7.1.3 e controlla anche plugin e temi. Se a luglio il sito usava una versione dalla 6.8.0 alla 7.0.1, cerca account amministratore che non riconosci e file che non hai caricato: sono segni che il sito è stato hackerato. Se il tuo sito WordPress è stato hackerato, mettilo offline e fatti aiutare da uno sviluppatore prima di ripristinare un backup. L'[audit SEO gratuito](https://www.nfw.run/audit-seo) mostra WordPress tra le tecnologie rilevate sulla tua home page, ma non il numero di versione, di proposito. Chiedilo al tuo hosting o allo sviluppatore, guarda nella bacheca di WordPress, oppure scrivici a . ## Negli stessi giorni: Node.js, Nginx, GitLab e Railway ### Node.js Il 21 ottobre 2026 anche Node.js ha pubblicato dei [rilasci di sicurezza](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases). Le versioni corrette sono 22.23.4, 24.22.1 e 26.12.1. Risolvono dieci vulnerabilità, quattro valutate come gravi (High): - **CVE-2026-111497**, una scrittura fuori dalla memoria prevista nel decodificatore Brotli (Brotli è un formato di compressione) che permette l'esecuzione di codice da remoto. Node.js esegue il codice Brotli incluso ogni volta che decomprime dati Brotli, direttamente con `node:zlib` o in automatico quando il codice chiama `fetch()` su una risposta compressa con Brotli: un'applicazione è esposta dove decomprime dati Brotli controllati da un attaccante, come il corpo di una richiesta o una risposta scaricata da un altro server. La gravità è alta, non critica. Secondo [The Hacker News](https://thehackernews.com/2026/10/nodejs-brotli-decoder-bug-could-allow.html), la dimostrazione pubblica del 22 ottobre è arrivata all'esecuzione di codice solo su una build di prova volutamente indebolita; su una build standard l'autore ha riportato un crash e una lettura limitata della memoria del processo. - **CVE-2026-106069** e **CVE-2026-105483**, in cui i controlli sul nome host dei certificati TLS possono essere aggirati. - **CVE-2026-105482**, in cui `dns.resolve` tronca i nomi al carattere NUL. Node.js non ha pubblicato punteggi CVSS. Nelle nostre scansioni Node.js compare su 235 siti e Next.js, che di solito gira su Node.js, su 1.144. Il rilevamento da fuori sottostima Node.js, e un sito Next.js esportato in modo statico non ha nessun server Node.js. Se usi Node.js, aggiorna a una delle tre versioni corrette. Su una piattaforma gestita come Vercel o Netlify, controlla l'avviso del fornitore. ### Nginx Una settimana prima, il 14 ottobre 2026, F5, che sviluppa Nginx, ha pubblicato una notifica di sicurezza fuori dal calendario abituale (vedi [nginx.org](https://nginx.org/en/security_advisories.html) e [F5](https://my.f5.com/manage/s/article/K000163408)). La notifica di F5 elenca 11 CVE nei suoi prodotti NGINX (Plus, Open Source, Gateway Fabric, Ingress Controller e il modulo njs); le cinque qui sotto riguardano NGINX Open Source, e nginx.org elenca le stesse cinque. Le correzioni sono in Nginx 1.30.6 e 1.31.7: - **CVE-2026-15176**, un buffer overflow quando `alias` è usato con `rewrite`. - **CVE-2026-93479**, un buffer overflow nella valutazione degli script (F5 lo intitola vulnerabilità della direttiva map e del confronto con regex di NGINX), che dipende da un `map` con catture regex. - **CVE-2026-97205**, un use after free (uso di memoria dopo che è stata rilasciata) con l'I/O asincrono su file. - **CVE-2026-97629**, falsificazione di sessione quando si usano i ticket di sessione TLS (F5: una vulnerabilità del modulo `ngx_http_ssl_module`). - **CVE-2026-95101**, iniezione nel corpo della richiesta in HTTP/3 (F5: una vulnerabilità del modulo `ngx_http_v3_module`). Le prime tre sono errori di memoria che possono mandare in crash Nginx e, in alcune configurazioni, potrebbero permettere a un attaccante di eseguire codice. La quarta può indebolire i controlli sui certificati client. La quinta fa arrivare byte in più a un backend via HTTP/3. La gravità è riportata in modo diverso. nginx.org le valuta tutte e cinque di livello medio, mentre F5 ne valuta tre (CVE-2026-15176, CVE-2026-97205 e CVE-2026-93479) critiche, 9,2 su CVSS v4. La maggior parte dipende da una configurazione specifica: `alias` con `rewrite`, I/O asincrono su file, `map` con catture regex, oppure HTTP/3. Alcune ci sono da molto tempo: CVE-2026-15176 riguarda le versioni dalla 0.1.29 e CVE-2026-97205 dalla 0.8.11. Nelle nostre scansioni Nginx compare su 15.089 dei 61.024 siti funzionanti (24,7%), la stessa popolazione dei dati su PHP. La versione è visibile su 1.476 di essi. Solo 4 mostrano una versione corretta e 1.353 usano un ramo precedente alla 1.30, per il quale nginx.org non pubblica correzioni. Le distribuzioni Linux riportano le correzioni senza cambiare il numero di versione, quindi vale la stessa cautela. Molte di queste scansioni sono precedenti al 14 ottobre. Per risolvere, aggiorna a 1.30.6 o 1.31.7, oppure installa il pacchetto aggiornato della tua distribuzione, e controlla le configurazioni indicate sopra. ### GitLab Il 21 ottobre 2026 GitLab ha pubblicato un [aggiornamento di sicurezza](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/) critico: 19.5.1, 19.4.3 e 19.3.6, con backport alle 19.2.9, 19.1.9, 19.0.10 e 18.11.13. La falla principale, **CVE-2026-110264** (critica, CVSS 10,0), è un integer overflow nella compilazione di un'espressione regolare costruita ad arte. In certe condizioni può permettere a un utente non autenticato di eseguire codice sul server GitLab. Riguarda tutte le versioni dalla 7.0, circa dodici anni di rilasci. La stessa versione corregge altri undici problemi, due dei quali gravi (High): **CVE-2026-15723** (8,2, un difetto di autenticazione nel collegamento automatico tra OmniAuth e LDAP) e **CVE-2026-112212** (7,5, avvelenamento della cache negli endpoint di discovery OAuth e OIDC). GitLab.com e GitLab Dedicated sono già aggiornati. Devono intervenire solo le installazioni che gestisci in proprio. GitLab è il posto dove gli sviluppatori tengono il codice, non un sito aziendale, quindi non compare nelle nostre scansioni (0 siti). Ti riguarda se il tuo sviluppatore o la tua agenzia ha un server GitLab proprio con il codice del tuo sito: chiedi a loro. ### Railway Questo non è un difetto del software ma una violazione di una piattaforma. Railway è una piattaforma dove gli sviluppatori pubblicano le applicazioni. Il 21 ottobre 2026 ha rilevato un'attività insolita sui sistemi che custodiscono le variabili d'ambiente dei clienti. Nel suo avviso di sicurezza, citato da [GitGuardian](https://securityboulevard.com/2026/10/railway-october-2026-incident-treat-every-environment-variable-as-exposed/), Railway dice che una terza parte non autorizzata "may have accessed encrypted environment variables" e che, "for some of them, obtained the decrypted values", cioè per alcune ha ottenuto i valori in chiaro. Le variabili d'ambiente sono il posto dove gli sviluppatori tengono chiavi API, credenziali dei database e credenziali dei registri privati. Lo stesso avviso dice che l'impatto è limitato a una parte degli utenti, che saranno contattati via email, e collega l'episodio a una serie di attacchi a società di piattaforme mirati a raggiungere i fornitori di inferenza AI. La risposta di Railway, dalla sua [pagina di stato](https://status.railway.com/incident/QH8L8B3E): le sessioni OAuth sono state invalidate e gli utenti devono accedere di nuovo, tutte le credenziali dei bucket sono state ruotate e il 22 ottobre tutti i token API di Railway sono stati invalidati, quindi bisogna crearne di nuovi. L'ultimo aggiornamento, delle 23:22 UTC del 22 ottobre, dice che build e distribuzioni sono tornate a una velocità circa normale su tutti i livelli, che le nuove registrazioni sono sospese e che è in arrivo un rapporto preliminare sull'incidente. Railway chiede a tutti i clienti di ruotare le variabili d'ambiente. GitGuardian elenca le guide pubblicate da Railway per le credenziali di AWS, GCP e GitHub. Nelle nostre scansioni 9 dei 61.024 siti funzionanti sono serviti da Railway, come risulta dalle intestazioni di risposta. Railway ospita soprattutto applicazioni e backend, non i siti aziendali che analizziamo, quindi l'esposizione sta in ciò che gira dietro un sito. Se il tuo sviluppatore ha pubblicato su Railway qualcosa che ti riguarda, chiedi se ogni segreto è stato ruotato. ## Controlla il tuo sito L'[audit SEO gratuito](https://www.nfw.run/audit-seo) elenca le tecnologie rilevate sulla tua home page, ma non i numeri di versione. Per sapere quale versione di PHP usa il tuo sito, scrivici a e vediamo come agire. Se il sito è su PHP 7 e preferisci ripartire da zero invece di rattopparlo, il nostro servizio di [restyling sito web](https://www.nfw.run/restyling-sito-web) lo ricostruisce su uno stack attuale. Per un sito nuovo, vedi il nostro servizio di [realizzazione siti web](https://www.nfw.run/creazione-siti-web). Le versioni di PHP sono elencate su [php.net](https://www.php.net/downloads.php). ## Servizi collegati Se vuoi passare dalla lettura al lavoro: - [Realizzazione siti web](https://www.nfw.run/creazione-siti-web) - [Restyling sito web](https://www.nfw.run/restyling-sito-web) ## Altri articoli [Tutti gli articoli](https://www.nfw.run/articoli) ![Aziende di Milano: velocità, Google e AI misurate a ottobre 2026, con il contorno della città](https://www.nfw.run/blog/milan-websites-state-of-the-web/cover-it.webp) 20 ottobre 2026Stato del webPresenza online ### [I siti web delle aziende di Milano: cosa abbiamo trovato](https://www.nfw.run/articoli/siti-web-aziende-milano-stato-del-web) Abbiamo scansionato 27.460 siti di attività di Milano: le stesse pagine mobile lente di Verona, un divario nella leggibilità AI, pochi dati strutturati. Leggi l'articolo ![Aziende di Verona: velocità, Google e AI misurate a ottobre 2026, con il contorno della città](https://www.nfw.run/blog/verona-websites-state-of-the-web/cover-it.webp) 14 ottobre 2026Stato del webPresenza online ### [I siti web delle aziende di Verona: cosa abbiamo trovato](https://www.nfw.run/articoli/siti-web-aziende-verona-stato-del-web) Abbiamo scansionato quasi 5.000 siti di attività di Verona: pagine mobile lente, pochi dati strutturati, immagini in formati vecchi e siti senza HTTPS. Leggi l'articolo ![Homepage di Ricerca Perdite 1972, azienda di ricerca perdite a Verona, con il titolare accanto al suo furgone](https://www.nfw.run/blog/landing-page-vs-website/ricerca-perdite-1972-homepage.webp) 16 ottobre 2026Landing pagePresenza online ### [Landing page o sito web: quale serve alla tua attività?](https://www.nfw.run/articoli/landing-page-o-sito-web) Landing page o sito completo? Come scegliere in base a cosa vendi e a chi ti legge, quanto costano e perché partire in piccolo non è un vicolo cieco. Leggi l'articolo ## Hai un progetto in mente? Parliamone. [Tutti gli articoli](https://www.nfw.run/articoli) [Prenota una chiamata](https://www.nfw.run/contatti)