RCE: cosa significa, come nasce e come difendersi

Le vulnerabilità Remote Code Execution (RCE) sono le falle che consentono a un attaccante di eseguire codice arbitrario su un sistema altrui, da remoto, senza alcun accesso fisico. Nella gerarchia della gravità occupano stabilmente il vertice: quando una RCE viene sfruttata, l’attaccante non sta più forzando una porta — è dentro, con la possibilità di impartire comandi alla macchina come se fosse seduto alla tastiera. Non a caso, le RCE più serie ricevono regolarmente i punteggi massimi della scala CVSS.

In questo articolo vediamo cosa sono le vulnerabilità RCE, da dove nascono, cosa può ottenere chi le sfrutta — con esempi molto recenti — e come le aziende possono difendersi.

1. Cos’è una vulnerabilità RCE
2. Da dove nascono le RCE: i vettori tipici
3. Anatomia di un attacco RCE: le fasi
4. Gli esempi recenti: quando il punteggio è 10 su 10
5. Le conseguenze di una RCE sfruttata
6. Come difendersi: le misure tecniche e organizzative
7. Come verificare l’esposizione dei vostri sistemi

htmlLe vulnerabilità Remote Code Execution (RCE) sono le falle che consentono a un attaccante di eseguire codice arbitrario su un sistema altrui, da remoto, senza alcun accesso fisico. Nella gerarchia della gravità occupano stabilmente il vertice: quando una RCE viene sfruttata, l’attaccante non sta più forzando una porta — è dentro, con la possibilità di impartire comandi alla macchina come se fosse seduto alla tastiera. Non a caso, le RCE più serie ricevono regolarmente i punteggi massimi della scala CVSS.

Cos’è una vulnerabilità RCE

Una RCE appartiene alla famiglia più ampia delle Arbitrary Code Execution (ACE): le vulnerabilità che permettono di far eseguire al sistema bersaglio istruzioni decise dall’attaccante. La specificità della RCE sta nell’aggettivo “remote”: lo sfruttamento avviene attraverso la rete — tipicamente con richieste costruite ad arte verso un servizio esposto — senza bisogno di accesso fisico né, nei casi peggiori, di alcuna autenticazione. Delle tecniche di esecuzione arbitraria di codice in generale abbiamo parlato nell’approfondimento sull’Arbitrary Code Execution; qui ci concentriamo sulla variante remota, che è quella che tiene svegli i responsabili IT.

La combinazione che rende le RCE così temute è precisa: massimo impatto, minima interazione. Molte richiedono solo che il servizio vulnerabile sia raggiungibile; nessun clic della vittima, nessuna credenziale rubata, nessun allegato. E con gli strumenti automatizzati di oggi, tra la pubblicazione di una RCE e le prime campagne di sfruttamento di massa passano ore, non settimane: gli attaccanti scandagliano internet alla ricerca di sistemi esposti non ancora corretti, in una corsa contro il tempo che vede spesso l’attaccante partire avvantaggiato. È lo stesso principio che rende indispensabile il monitoraggio continuo delle vulnerabilità: una falla nota e non corretta è una porta lasciata aperta con l’indirizzo scritto sopra.

Da dove nascono le RCE: i vettori tipici

Le strade che portano a una RCE sono ricorrenti. La prima è la famiglia delle falle di iniezione: input non validato che finisce per essere eseguito come codice — il meccanismo che abbiamo analizzato nell’approfondimento sulla code injection — e che nella sua forma estrema consegna all’attaccante l’esecuzione di comandi sul server. Anche una SQL injection, in certe configurazioni, può essere scalata fino alla RCE: è esattamente la catena osservata nel caso FreePBX di cui parliamo più avanti.

La seconda strada è la deserializzazione insicura: applicazioni che ricostruiscono oggetti da dati ricevuti dall’esterno senza verificarli, dando all’attaccante il controllo su cosa viene istanziato ed eseguito. La terza sono gli errori di gestione della memoria — i buffer overflow — tipici del software di sistema e dei linguaggi che gestiscono la memoria manualmente. E la quarta, la più frequente nella pratica aziendale, sono i componenti di terze parti vulnerabili: librerie, framework, plugin e piattaforme che l’azienda usa senza presidiare — dove la RCE non la introduce il vostro codice, ma quello che avete adottato. È il rischio al centro della categoria OWASP dei componenti vulnerabili e obsoleti, e il motivo per cui un inventario aggiornato del software in uso è una precondizione della sicurezza, non un vezzo documentale.

Un fronte in rapida crescita riguarda i componenti legati all’intelligenza artificiale: framework di orchestrazione, librerie di machine learning e piattaforme di automazione che elaborano input esterni con logiche complesse. Sono sistemi adottati in fretta dalle aziende per stare al passo, e non sempre valutati sul piano della sicurezza con lo stesso rigore riservato al software tradizionale — un divario che gli attaccanti hanno già iniziato a sfruttare.

Anatomia di un attacco RCE: le fasi

Un attacco che sfrutta una RCE segue quasi sempre la stessa progressione, ed è utile conoscerla perché ogni fase offre un’occasione di rilevamento e difesa. Si parte dalla ricognizione: l’attaccante — spesso uno scanner automatico — identifica i servizi esposti e ne rileva versioni e tecnologie, incrociandole con i cataloghi pubblici di vulnerabilità note per capire dove colpire.

Segue la consegna del payload: la richiesta costruita ad arte che raggiunge il servizio vulnerabile — una stringa in un parametro, un oggetto serializzato, un webhook manipolato. Se la falla è sfruttabile, si arriva all’esecuzione: il codice dell’attaccante viene eseguito con i privilegi del processo vulnerabile, tipicamente come primo passo un comando che conferma il controllo ottenuto o scarica strumenti aggiuntivi da un server esterno.

Da qui l’attacco quasi mai si ferma. Comincia la fase di persistenza ed escalation: l’attaccante installa una backdoor per garantirsi il rientro indipendentemente dalla falla iniziale, tenta di elevare i propri privilegi fino a quelli amministrativi, e cancella o altera i log per coprire le tracce — attività che un sistema di monitoraggio degli eventi di sicurezza può intercettare se correttamente configurato. Infine il movimento laterale: dal sistema compromesso verso il resto della rete, alla ricerca di dati, credenziali e altri bersagli. È la ragione per cui una RCE non va mai letta come “un server bucato”, ma come un potenziale punto di partenza verso l’intera infrastruttura — e per cui la segmentazione della rete, che spezza questa progressione, è una difesa tanto importante quanto la patch.

Gli esempi recenti: quando il punteggio è 10 su 10

Il caso storico che ha reso le RCE un tema da consiglio di amministrazione è Log4Shell (2021): una falla nella libreria di logging Log4j, presente in una quantità sterminata di software, sfruttabile con una semplice stringa. Ma non serve tornare al 2021: a gennaio 2026 è stata resa nota Ni8mare (CVE-2026-21858), RCE critica nella piattaforma di automazione n8n con punteggio CVSS 10 su 10 — compromissione completa dell’istanza esposta con semplici richieste costruite ad arte. E pochi mesi prima il caso FreePBX (CVE-2025-57819) ha mostrato la catena tipica: una SQL injection nei centralini aziendali trasformata in esecuzione remota di comandi.

I due casi recenti raccontano la stessa lezione: le RCE non vivono solo nei software esotici, ma negli strumenti che le aziende adottano per lavorare — l’automazione, il centralino, il CMS — e la finestra tra divulgazione e sfruttamento si misura in ore. C’è però una costante che gioca a favore di chi si difende: quasi sempre, quando la vulnerabilità diventa pubblica, la correzione è già disponibile. Il problema non è la mancanza della patch, ma il ritardo nell’applicarla — ed è un problema di processo, non di tecnologia.

Le conseguenze di una RCE sfruttata

Chi ottiene esecuzione di codice remoto eredita, come minimo, i privilegi dell’applicazione compromessa — e da lì lavora per salire. Gli esiti tipici: il furto dei dati raggiungibili dal sistema; l’installazione di una backdoor per garantirsi il rientro anche dopo la correzione della falla; l’arruolamento della macchina in una botnet; il movimento laterale verso il resto della rete aziendale; e, sempre più spesso, il ransomware come monetizzazione finale — con i costi che abbiamo quantificato nell’analisi su quanto costa un attacco informatico a una PMI.

C’è un dettaglio che rende le RCE particolarmente insidiose per le aziende: lo sfruttamento riuscito è spesso silenzioso. Nessun blocco, nessun messaggio: il sistema continua a funzionare mentre l’attaccante consolida la posizione. La scoperta arriva settimane o mesi dopo, quando il danno è fatto. E le conseguenze non sono solo tecniche: una compromissione che espone dati personali fa scattare gli obblighi di notifica del GDPR e, per i soggetti nel perimetro, della NIS2 — come abbiamo visto parlando di chi è tenuto a conformarsi alla NIS 2. Alla perdita tecnica si somma quella reputazionale e, potenzialmente, quella sanzionatoria.

Come difendersi: le misure tecniche e organizzative

La difesa dalle RCE è fatta di poche cose, applicate con disciplina. La prima e più redditizia è il patch management: la stragrande maggioranza degli sfruttamenti reali colpisce vulnerabilità note e già corrette, su sistemi che non hanno applicato la correzione — la finestra tra pubblicazione della patch e sua applicazione è il campo di battaglia vero. La seconda è la riduzione della superficie di attacco: censire cosa è esposto su internet e chiedersi, servizio per servizio, se debba davvero esserlo; ogni servizio raggiungibile in meno è un vettore di attacco eliminato alla radice.

La terza misura è il contenimento, che agisce non sulla probabilità ma sull’impatto: il principio del minimo privilegio, per cui applicazioni e servizi girano con i permessi strettamente necessari e una compromissione eredita poco; e la segmentazione della rete, perché una macchina compromessa non si traduca automaticamente nella rete intera compromessa. A questo si affiancano le difese perimetrali applicative — un web application firewall che filtra i payload malevoli più comuni — e, sul piano dello sviluppo, la validazione rigorosa degli input e l’analisi statica del codice, che intercetta i pattern all’origine delle iniezioni prima che il software vada in produzione.

Nessuna di queste misure, presa singolarmente, è sufficiente: è la loro combinazione a costruire la profondità di difesa che rende un attacco RCE difficile da portare a termine e, quando riesce, contenuto nei danni.

Come verificare l’esposizione dei vostri sistemi

Tutte le misure precedenti presuppongono una cosa: sapere cosa avete, dove è esposto e in che stato è. È il punto in cui la difesa dalle RCE smette di essere teoria e diventa verifica. Un vulnerability assessment periodico confronta i vostri sistemi — esposti e interni — con il catalogo delle vulnerabilità note: è lo strumento che trova la RCE nota non corretta prima che la trovino gli scanner degli attaccanti, ed è il presidio più diretto contro il vettore numero uno. Per le applicazioni web esposte, la verifica si affina con un web vulnerability assessment, mirato sulle falle sfruttabili dall’esterno.

Per i sistemi critici c’è un livello ulteriore: verificare non solo che le falle note siano chiuse, ma cosa otterrebbe davvero un attaccante determinato — concatenando debolezze minori, sfruttando configurazioni, muovendosi lateralmente come nelle fasi descritte sopra. È il lavoro del penetration test: la simulazione controllata che misura la tenuta reale delle difese, RCE comprese, e restituisce non un elenco di falle ma il racconto di cosa succederebbe davvero.