POP Chain e deserializzazione non sicura: una tecnica introdotta oltre 15 anni fa e ancora efficace

Le POP Chain rappresentano una tecnica di attacco che sfrutta la deserializzazione non sicura di oggetti in PHP, concatenando gadget già presenti nell’applicazione per eseguire operazioni non autorizzate. Il caso recente di una vulnerabilità in GiveWP dimostra come queste catene possano ancora compromettere sistemi moderni, anche tramite dipendenze di terze parti. La difesa richiede l’eliminazione della deserializzazione di dati non fidati, il monitoraggio delle attività anomale e l’adozione di pratiche di sicurezza come code review e penetration testing.

La deserializzazione di dati non attendibili rappresenta una delle superfici d’attacco più note e persistenti nelle applicazioni PHP. Quando un’applicazione ricostruisce oggetti a partire da input controllabili da un attaccante, possono essere attivati magic methods e concatenate sequenze di chiamate a funzionalità già presenti nell’applicazione, note come POP Chain. Questa tecnica, descritta e resa popolare da Stefan Esser nel 2010, può ancora avere conseguenze gravi, inclusa l’esecuzione di codice arbitrario. La recente vulnerabilità di GiveWP dimostra come la deserializzazione non sicura resti un problema concreto anche nelle applicazioni moderne.

Deserializzazione non sicura: il punto di partenza delle POP Chain

La serializzazione è un meccanismo utilizzato da molti linguaggi, incluso PHP, per trasformare oggetti complessi in una rappresentazione che può essere salvata nel database, nelle sessioni o trasmessa tra applicazioni. Il processo inverso, chiamato deserializzazione, ricostruisce il dato originale e, nel caso degli oggetti, ne ripristina lo stato.

Il problema nasce quando l’applicazione deserializza dati controllabili da un attaccante. In PHP, questo processo può ricostruire oggetti ed eseguire automaticamente alcuni metodi, detti magic methods, che vengono richiamati automaticamente in particolari momenti del ciclo di vita di un oggetto, senza una chiamata diretta da parte dello sviluppatore. Se gli oggetti provengono da input non fidati, questa esecuzione automatica può diventare il punto di partenza per comportamenti inattesi e trasformare la deserializzazione in una superficie di attacco rilevante. Il problema rientra nella classificazione CWE-502 (Deserialization of Untrusted Data), che descrive la deserializzazione di dati non fidati senza sufficienti garanzie sulla validità del risultato. Come descritto anche dalla documentazione ufficiale PHP, la deserializzazione di input non fidati è considerata una pratica ad alto rischio per la sicurezza.

Cosa sono i gadget e come nasce una POP Chain

Una POP Chain (Property-Oriented Programming Chain) può essere considerata l’equivalente applicativo delle più note tecniche ROP (Return-Oriented Programming). Nelle ROP l’attaccante concatena frammenti di codice macchina (assembly) già presenti in memoria. Nelle POP Chain, l’attaccante concatena invece chiamate ai metodi dell’applicazione, manipolando le proprietà degli oggetti in modo da guidarne il comportamento.

Il concetto chiave è il riuso di funzionalità già presenti nell’applicazione. L’attaccante le combina in una sequenza non prevista dagli sviluppatori, inducendo il software a compiere operazioni non autorizzate. I singoli componenti di questa sequenza sono chiamati gadget (piccoli frammenti di funzionalità già presenti nel codice), che, se attivati nel contesto giusto, possono produrre effetti utili all’attaccante, come l’inclusione di file, la scrittura su disco o l’esecuzione di comandi. Nelle applicazioni moderne, però, questi gadget non si trovano necessariamente nel codice scritto dal team di sviluppo, spesso emergono infatti dalle dipendenze dell’applicazione, come framework o librerie di terze parti. L’intera catena viene costruita modificando le proprietà degli oggetti serializzati, da cui deriva il termine Property-Oriented Programming. Perché l’attacco funzioni, i componenti di codice usati nella catena d’attacco devono essere già caricati dall’applicazione oppure poter essere caricati automaticamente durante la deserializzazione. Deve inoltre esistere una sequenza che l’attaccante possa sfruttare per raggiungere un’operazione non autorizzata.

Il caso GiveWP e perché le POP Chain restano rilevanti

La recente vulnerabilità (CVE-2026-82222) che ha interessato il plugin GiveWP per WordPress dimostra come questa tecnica sia ancora attuale. Secondo il record ufficiale della vulnerabilità e l’analisi tecnica pubblicata da Patchstack, il problema non derivava semplicemente dalla presenza di una POP Chain, ma dalla possibilità di introdurre e successivamente riattivare oggetti controllati dall’attaccante attraverso il sistema di gestione delle sessioni. In termini pratici, il processo di sfruttamento può essere descritto come una sequenza composta da un deserialization entry point, cioè il punto in cui l’applicazione accetta e deserializza dati controllabili, da uno o più gadget intermedi che propagano l’esecuzione e da un sink finale, ossia la funzionalità sensibile che determina l’impatto reale della vulnerabilità. Una volta recuperati ed elaborati dall’applicazione, questi oggetti potevano attivare una catena di gadget già presenti nel software fino a raggiungere funzionalità in grado di eseguire codice sul server.

Ciò che rende le POP Chain particolarmente interessanti dal punto di vista difensivo è che il loro sfruttamento può risultare difficile da riconoscere nelle fasi iniziali. L’attaccante utilizza componenti già presenti nell’applicazione e segue percorsi di esecuzione apparentemente legittimi, rendendo potenzialmente meno immediata l’identificazione dell’attacco, soprattutto in assenza di un adeguato monitoraggio applicativo. Inoltre, poiché molti gadget utili all’attaccante non si trovano nel codice proprietario ma nelle librerie e nelle dipendenze caricate dall’applicazione, l’analisi non dovrebbe limitarsi al solo codice sviluppato internamente, ma includere anche il comportamento delle classi effettivamente presenti nel contesto applicativo. L’impatto di una vulnerabilità di questo tipo dipende dalle funzionalità raggiungibili. Anche senza arrivare all’esecuzione di codice arbitrario, la deserializzazione non sicura può consentire a un attaccante di alterare dati o impostazioni dell’applicazione o compromettere la disponibilità del servizio. L’aggiornamento dell’applicazione e delle sue dipendenze resta fondamentale, ma rappresenta solo una parte della strategia di difesa. La misura preventiva più efficace consiste nell’evitare la deserializzazione di oggetti provenienti da dati non fidati. Diventa altrettanto importante la capacità di individuare attività anomale, tentativi di exploit, escalation di privilegi e comportamenti incompatibili con il normale funzionamento dell’ambiente. È inoltre fondamentale intervenire tempestivamente per ridurre il tempo di rilevamento e contenimento e limitare l’impatto di una compromissione.

Olympos Consulting: il partner strategico per la sicurezza applicativa

Il caso GiveWP conferma una lezione che la sicurezza informatica ripete da tempo: le vulnerabilità più insidiose spesso non nascono da tecniche nuove, ma dalla combinazione tra pratiche di sviluppo consolidate e superfici di attacco sottovalutate. Le POP Chain, come dimostra questo caso, non richiedono codice malevolo: sfruttano ciò che l’applicazione contiene già, ricomponendo in modo imprevisto funzionalità legittime, spesso presenti nelle dipendenze di terze parti piuttosto che nel codice proprietario.

Individuare in anticipo questo tipo di rischio richiede tempo e competenze specifiche, ed è proprio su questo che Olympos Consulting affianca aziende e team di sviluppo: attività di security code review per individuare pattern di deserializzazione non sicura e possibili catene di gadget, penetration testing applicativo per verificare se le funzionalità esposte possano essere effettivamente concatenate in uno scenario di attacco, e un supporto sul fronte del monitoraggio, utile a intercettare comportamenti anomali prima che si trasformino in un incidente conclamato.

Nessun intervento elimina del tutto il rischio, ma affidarsi a un partner come Olympos Consulting, con competenze verticali su questo tipo di minacce, può fare la differenza tra individuare per tempo una vulnerabilità e subirne le conseguenze.

Redazione

La Redazione di Red Hot Cyber fornisce aggiornamenti quotidiani su bug, data breach e minacce globali. Ogni contenuto è validato dalla nostra community di esperti come Pietro Melillo, Massimiliano Brolli, Sandro Sana, Olivia Terragni e Stefano Gazzella. Grazie alla sinergia con i nostri Partner leader nel settore (tra cui Accenture, CrowdStrike, Trend Micro e Fortinet), trasformiamo la complessità tecnica in consapevolezza collettiva, garantendo un'informazione accurata basata sull'analisi di fonti primarie e su una rigorosa peer-review tecnica.