PHP2Shell esplose: CVSS 9.2, il giorno prima dell'apertura, e i due fori erano in codice per 10 anni.

Innanzitutto, la conclusione è che:PHP ha prodotto un codice remoto non autorizzato per CVSS 9.2, numeri CVE-2026-109618 e CVE-2026-109619, con un soprannome PHP2Shell. Il 20 ottobre è stato reso pubblico e il 21 ottobre a 1400 patch UTC sono stati rilasciati, mentre i contenitori di miele di Amazon sono stati registrati il 17 ottobre — quattro giorni prima dell'apertura.

Ciò che è peggio di questo è l'altra cosa: questi due fori sono i primi ad arrivare a PHP 5.4, il che significa...Sono in codice da piu' di un decennio.Non lo so. E nel 2024, quando l'audit del core sviluppatore PHP ha scoperto il percorso di OOM, il team si è incontrato per discutere come risolverlo.Non eravamo d'accordo e poi non l'abbiamo risolto.Non lo so. Il motivo è che nessuno pensava che potesse essere realmente usato.

Questa frase ora sembra particolarmente ironica. La ragione per non essere in grado di farlo non è che il buco è insignificante, ma che la catena è troppo complessa per andare oltre la capacità fisica dei ricercatori umani. Poi l'IA è venuta e l'ha scritta.

In primo luogo, ottenere la parola "risposte di emergenza multinazionale" fuori strada. Guarda.

La parola preferita del titolo è "allarme globale". Non e' una esagerazione questa volta, ma e' un punteggio chiaro.

• PHP Ufficiale: Un avviso di anticipo è stato rilasciato il 20 ottobre, affermando che il 21 ottobre alle 14:00 UTC sarebbe stato rilasciato in una versione sicura se i dettagli sono stati trapelati o messi in campo. Di conseguenza, il numero CVE è stato accoltellato a Hacker News lo stesso giorno, e il rilascio previsto per il 22 ottobre è stato costretto ad un giorno prima.
• CERT-EU: consulenza di rilascio 2026-018 e includere entrambi i CVE.
• CloudflareIl 21 ottobre, il CTO Dane Knecht ha detto direttamente "l'attacco precoce è stato visto emergere", e le regole WAF sono state rilasciate in pieno, compresi gli utenti liberi. Ma ha sottolineato che era solo stopgap, e la vera soluzione era patching.
• Informazioni sulla minaccia Amazon: Le lattine di miele MadPot sono state catturate provando il 17 ottobre, e un altro lotto è stato catturato il 21 ottobre, e il carico utile e l'infrastruttura ha indicato un certo numero di diversi attaccanti. php2shell "è già ampiamente usato".
• Guarda Towr: Entrambi i fori sono riemergenti, mentre i tentativi di sfruttare entrambi sono osservati.

Quindi "l'attacco è stato trovato" non è un rendering, ma un fatto. E la risposta di emergenza multinazionale non è un colpo -- è solo che i principali soggetti della risposta sono produttori, CDN e organizzazioni di emergenza, non qualsiasi governo del paese.

Due, due buchi, due modi completamente diversi di morire.

Molte persone pensano che sia un buco con due numeri, no. Questi sono due percorsi separati di attacco, ogni CVSS 9.2.

CVE-2026-109618: Bomba quando la memoria è esaurita

L'elaborazione di una richiesta viene interrotta quando la distribuzione di memoria PHP fallisce. Il problema è:A questo punto, i dati della richiesta interna potrebbero essere stati solo semi-initializzati, e la successiva logica di pulizia avrebbe usato questo pezzo non incorporato di dati cattivi come dati validi.

Il metodo di trigger è semplice: costruire una richiesta multipart per implodere la memoria. La cosa strana è che...La dimensione della richiesta sembra corrispondere al soffitto.Non è la dimensione max post che hai impostato, è la decodifica e il consumo di elaborazione interna.

Il peggio è mod php. Mod php per Apache quando la richiesta di avvio non è riuscitaSta ancora per ripulire., in modo che questa catena può essere completata prima che qualsiasi codice applicabile esegue. Il tuo codice PHP è così pulito, non c'è scappatoia, non c'è modo di fermarlo.

PHP-FPM ucciderà il lavoratore quando non si avvia, solo per tagliare la catena, quindi ufficialmente, mod php è il rischio più alto. Ma fai attenzione, questo non significa che la FPM sia al sicuro.Dopo l'avvio di successoC'è ancora una possibilità di sfruttamento.

CVE-2026-109619: Stato sporco tra le richieste

Questo e' peggio. PHP utilizzerà il processo del lavoratore per elaborare più richieste. L'ultima richiesta di rilasciare la memoria, il puntatore rimane nello stato interno; la prossima richiesta entra,Leggi l'indirizzo vuoto prima della normale inizializzazione.Non lo so.

Errori fatali (esaurimento della memoria, timeout delle prestazioni) interrompono la pulizia dello stato. Ancora peggio, qualche diagnosi non letale durante l'arresto avrebbe sostituito lo stato sbagliato.Ridammelo.Non lo so.

Tra i percorsi ufficialmente confermati ci sono: RCEs con errore fatale quando PHP 8.5 abilitato backtrac di errore Fatal (apertura di default), e il ciclo di vita di sessione RCEs su motore php e FPM.session.upload_progress Per impostazione predefinita, è possibile agire come un consumatore precoce in uno stato di sporcizia.E non c'è bisogno di applicare call(s)Non lo so.

Questo buco è ancora attaccato.Perdita di memoriaNon lo so. Cosa stava perdendo? è la password, token, chiave API, certificato per altre richieste nella memoria di processo. Wiz direttamente rispetto a Heartbled, che non è troppo.

Timeline, più che titolo Look.

Tempo	Cos'e' successo?
Anno 2024	PHP core developer audit ha trovato OOM, quel bug, il team non aveva consenso sulla legge, metterlo in attesa.
2026-08	Ryan Austin di Calif identifica le scappatoie con OpenAI GPT-5.6 Sol; Wiz Independent Discovery
2026-10-17	Amazon MadPot, il miele può registrare un tentativo, quattro giorni prima dell'apertura.
2026-10-20	CVE numero trapelato in Hacker News e Social Media, PHP
2026-10-21	14:00 UTC Pubblicazione 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35

Il 17 ottobre deve essere eliminato.Il giorno pubblico era il 20, ma l'attacco ebbe luogo il 17.La proposta Amazon è semplice: il punto di partenza non dovrebbe essere sulla data di divulgazione, ma in avanti per almeno il 17 ottobre.

Quanto a come gli aggressori hanno ottenuto le informazioni in anticipo, l'Amazzonia ha detto "non chiaro". Non posso entrare in questo, ma devi accettare una realtà.Il giorno della rivelazione non e' mai stato il giorno dell'attacco, ma il giorno in cui lo sapevi.

Quattro, stavolta e' davvero AI.

Il blog di Wiz contiene una frase che ho letto due volte: “Questi difetti sottostanti sono esistiti per decenni, ma per dimostrare che possono essere utilizzati, hanno bisogno di una catena di passi eccezionalmente complessa, ai margini delle capacità reali dei ricercatori umani.Il modello AI Frontline riduce significativamente questa soglia.Non lo so.

Specifico: Ryan Austin, ricercatore di Calif, è stato trovato nel progetto OpenAI "Patch the Planet" con GPT-5.6 Sol. Wiz ha trovato lo stesso problema indipendentemente. Per farne uso, abbiamo bisogno di una catena di difetti e di colpire ogni bersaglio.Il layout di memoria ripetutamente calibratoWiz dice che il modello front-line consente loro di sviluppare applicazioni utilizzabili per diverse applicazioni entro ore.

Non significa "AI ha vinto di nuovo".Il punto è che la fossa del "complesso" sta fallendo.

Molte vecchie scappatoie non sono state battute negli ultimi due decenni, non perché non sono gravi, ma perché la soglia di utilizzo è troppo alta — alcune settimane di investimento da parte dei ricercatori top e un po 'di fortuna. Quindi li metti nella colonna "teoricamente rischiosa". Ora questa recinzione è sparita.

Quei buchi di dieci anni che si trovano nel vostro sistema e sono valutati come "difficili e non elaborati" devono essere rivalutati.

Cinque, a quale dovresti andare?

Branch	Versione colpita	Disposizione
PHP 8.5	< 8.5.12	Alzare a 8.5.12.
PHP 8.4	< 8.4.27	Alzati a 8.4.27.
PHP 8.3	< 8.3.36	Alzati a 8.3.36.
PHP 8.2	< 8.2.35	Alzati a 8.2.35.
PHP 7.4 / 8.0 / 8.1	Tutti	Ufficialmente inedito, livello sorgente solo
PHP 5.4 – 7.3	Tutti	EOL, il governo non lo risolve. Affari

Diversi promemoria della vita reale:

• Linux Release e LTS VendorHo una patch in anticipo.Controlla la consulenza del produttore con un pacchetto di distribuzione. Non correre il codice sorgente.
• Uso rpms.remirepo.net Nota: PHP ha ufficialmente dichiarato la fonte il 21 ottobre.Nessun aggiornamentoCosì è possibile passare a un pacchetto di distribuzione o farlo dal codice sorgente.
• Il binario Windows di PHP 8.5 è anche sulla pagina di download ufficiale.
• Non pensare che sia bene eseguire nel contenitore -- la versione PHP dello specchio contenitore deve essere controllata.

Sei, se non riesci ad avere un cerotto, fai prima questi quattro.

Primo stato:Nessuno di questi qui sotto ti farà al sicuro.La frase ufficiale PHP è "ridurre l'esposizione a specifici percorsi di attacco, ma non rendere le installazioni più sicure". Il loro valore è quello di darvi il tempo per ottenere patches.

Impostare il limite di memoria a -1

Scopo: Per eliminare il tappo di memoria PHP prevedibile fallito, cioè CVE-2026-109618 ha confermato la condizione di trigger su cui dipende.

Il punto e'...Come?: da fissare in luoghi in cui la domanda è inalterata, come ad esempio il FPM Pool php_admin_value o configurazione Apache. È necessario verificare che non ci sono pop, directory, impostazioni di applicazione per aggiungere il limite indietro.Poi riavvia ogni lavoratore.

Il prezzo è chiaro: sei fuori dalla recinzione di memoria del PHP, e il fallimento di distribuzione inferiore può ancora essere su quel percorso pericoloso. Quindi deve essere un contenitore o un gruppo per limitare la copertura, ma è solo una strategia per "uccidere le persone colpite".Non utilizzare i dati RLIMIT AS o RLIMITQuesti due sono proprio il tipo di guasti di distribuzione che creano le scappatoie.

Ridurre la dimensione massima

Siti senza file 8M per file 32M e garantiti upload_max_filesize Meno di questo. Allo stesso tempo, i limiti vengono aggiunti al server web o allo strato proxy - il volume delle richieste decodificate, il numero di campi, il numero di parti multipart, il numero di teste, la profondità dei nidi.Queste restrizioni devono coprire richieste che non sono valide Content-LengthO ci andremo.

3. Disattivare il processo di sessione.upload

session.upload_progress.enabled = 0

È scritto nella configurazione php.ini, FPM o server.Deve essere efficace prima della richiesta.Non lo so. Uso ini_set() O FPM. .user.ini Era troppo tardi, era sporco. Il cambiamento è anche quello di riavviare tutti i lavoratori.

PHP 8.5 Ancora uno

fatal_error_backtraces = 0

Questo blocco ha confermato solo tracce di errore fatale, senza altre varianti. Inoltre richiedono impostazioni di livello amministratore + riavviare il lettore.

Inoltre, la menzione ufficiale che molti ignoreranno:Fissare gli errori fatali che gli aggressori possono attivare ed eseguire il tempo fuori., inclusi back-up, upload, elaborazione delle importazioni, guasti di pulizia. E...Eliminare configurazioni obsolete o illegali imposte su base richiesta per richiesta- Hanno sputato le informazioni diagnostiche prima che siano inizializzate e alimentano la perdita.

Quest'ultima frase è più facilmente frainteso:Non funziona nascondere la diagnosi con la segnalazione di errori, errori di visualizzazione o @.Non sta succedendo.

VII. REALIZZAZIONI

Non voglio finire scrivendo "Chiudi la patch". Certo che e' una toppa. E' oggi. Ma alcuni giudizi devono cambiare.

1. Il termine "difficile da usare" non è più lo stesso di "prescritto".PHP questa catena di accesso di foro è abbastanza complicato da avere bisogno dell'aiuto di AI, che ha già aiutato. I vecchi buchi nella vostra lista di asset che segnano "rischio teorico" dovrebbero essere rivalutati.
2. La lingua funziona in un unico punto.WordPress, Drupal, Joomla, Magento, MediaWiki tutti funzionano su PHP, il vostro controllo del codice di applicazione è pulito, e il core PHP è nei guai. Ritmo compensativo degli strati infrastrutturali, con strati di applicazione separati.
3. "Il codice dell'applicazione è rotto senza eseguire." La WAF può solo ritardare.Cloudflare stesso ha detto che era stopgap. Mettere WAF come soluzione equivale a dare vita alla copertura di regola.
4. Ci sono un sacco di vecchi siti nel paese utilizzando PHP.Quelle stazioni che corrono su PHP 5.6/7.0, che sono state molto tempo fa non mantenute e impiccate su un mainframe cloud, sono in questa esposizione di 1,3 a 1,9 milioni. Non riceveranno alcun avviso.

Le tarature dei dati sono registrate: W3Techs dice che i PHP rappresentano il 69,3 per cento delle lingue conosciute al servizio, e Wiz 70 per cento; gli host di esposizione, il ricercatore di sicurezza Silas Cutler stimano oltre 1,3 milioni, e la ricerca Shodan di Henk Poley è superiore a 1,9 milioni. Questi numeri sono di calibri diversi e non li usano come valori precisi, ma la scala è la stessa -Milioni, a livello globale.

Un altro dettaglio vale la pena ricordare: quando il numero CVE è stato trapelato, i punti CVSS che è uscito erano 10,0, PHP è stato ufficialmente confermato.Quel punteggio era sbagliato.In realtà è 9.2. Nessuno avrebbe saputo nulla di questo dettaglio, ma sarà sempre in circolazione. Vedendo le 10, sai qual e' l'onda.

Un buco di 10 anni, due mesi di ricerca assistita dall'IA, quattro giorni di utilizzo precoce, una finestra di patch di un giorno. Questo timescale è il normale di tutti i software di base che segue.

Controlla subito la versione.php -vO guarda i tuoi specchi per container al tag. Non aspettare domani.