// 1 CRITICAL · 1 ZERO-DAY · 2 CVE · 4 EXPLOIT NELLE ULTIME 24H
Un errore di tipo short vs int nella libreria grafica Samsung rlottie permette esecuzione remota di codice tramite file animazione malevolo. Patch disponibile.

Il 22 giugno 2026 la Zero Day Initiative ha reso pubblico l'advisory ZDI-26-359, che documenta una vulnerabilità di esecuzione remota di codice nella libreria rlottie di Samsung. La falla nasce da un integer truncation nei contatori di strutture grafiche: tipi dati dichiarati short (16 bit) anziché int (32 bit) permettono overflow quando il parser elabora dati utente malformati. La conseguenza è scrittura out-of-bounds e corruzione di memoria, con esecuzione di codice arbitrario nel contesto del processo corrente. Samsung ha corretto il difetto il 12 maggio 2026 tramite pull request open-source su GitHub, anticipando di un mese la disclosure coordinata.

Punti chiave
  • L'advisory ZDI-26-359 conferma vulnerabilità RCE in Samsung rlottie per mancata validazione di dati utente che causa integer truncation prima della scrittura in memoria.
  • La patch open-source, mergeata il 12 maggio 2026, promuove i tipi dei contatori point/contour da short a int in tre file del motore di rendering vettoriale.
  • Il ricercatore Michael DePlante (@izobashi) ha segnalato la falla il 1 aprile 2026; la disclosure pubblica coordinata è avvenuta il 11 giugno 2026.
  • Non sono disponibili identificatore CVE, punteggio CVSS né versioni specifiche di rlottie dichiarate vulnerabili dall'advisory.

Il bug: quando un 'short' diventa troppo corto

La libreria rlottie di Samsung renderizza animazioni nel formato Lottie, un formato vettoriale basato su JSON popolare in app mobile, web e desktop per la sua leggerezza e scalabilità. Il motore di rendering sottostante, derivato da FreeType, manipola strutture dati che descrivono contorni e punti di forme vettoriali. Nella struttura SW_FT_Outline, i contatori di contorni e punti erano dichiarati come short, interi con segno a 16 bit con range massimo di 32.767 valori.

Quando il parser rlottie riceve dati utente non validati — ad esempio un file animazione Lottie crafted — valori superiori a quel range causano integer truncation: il valore viene silenziosamente tagliato, con bit superiori persi. Il risultato è un conteggio apparentemente valido ma numericamente errato, che porta il renderer a scrivere oltre i limiti dell'array allocato. La ZDI descrive questo meccanismo come "integer truncation before writing to memory", con esecuzione di codice nel contesto del processo come risultato finale.

La pull request #589 su GitHub, aperta da mihashco e mergeata nel ramo master Samsung il 12 maggio 2026, risolve il problema con un cambio di tipo sistematico. I campi n_contours e n_points passano da short a int, così come il puntatore contours da short* a int*. Il file v_ft_stroker.cpp richiede aggiornamenti dei cast corrispondenti, da (short) a (int). Il commento del commit è lapidario: "fixed integer overflow in SW_FT_Outline point/contour counters".

La timeline: tre mesi dal report alla patch, un mese alla disclosure

La coordinazione tra ricercatore e vendor ha seguito il modello standard della Zero Day Initiative. Michael DePlante, ricercatore con handle @izobashi, ha inviato il report il 1 aprile 2026. Samsung ha integrato la correzione nel repository pubblico il 12 maggio 2026, senza prevedere advisory proprio: la pubblicazione della ZDI il 11 giugno 2026 ha rappresentato la prima disclosure coordinata e pubblica del problema.

Questo intervallo di 72 giorni tra report e patch, e ulteriori 30 giorni prima della disclosure, è consistente con pratiche di coordinated vulnerability disclosure. L'assenza di un advisory proprio Samsung, tuttavia, significa che gli sviluppatori che integrano rlottie tramite distribuzioni di pacchetti o sottoforme di modulo non hanno ricevuto notifica automatica: la visibilità dipende interamente dal monitoraggio del repository GitHub o dalla consultazione dell'advisory ZDI.

L'advisory ZDI-26-359 non specifica quali versioni di rlottie siano affette, né elenca prodotti Samsung o terze parti che incorporano la libreria vulnerabile. La rlottie è utilizzata in app di sistema Samsung, in client di messaggistica che supportano sticker animati, e potenzialmente in app di terze parti che hanno adottato la libreria per rendering Lottie. La variabilità dei vettori d'attacco — "attack vectors may vary depending on the implementation", come precisa la ZDI — rende impossibile quantificare l'esposizione senza inventario delle implementazioni.

La lettura: un errore di dichiarazione tipica con conseguenza atipica

Integer truncation e overflow sono classici della programmazione C/C++ in sistemi con tipi di larghezza fissa, ma la gravità di questa falla risiede nel contesto di esecuzione. La libreria rlottie processa dati utente non attendibili — file animazione scaricati da rete, ricevuti in chat, aperti da browser. Il parser è un attack surface naturale: l'utente non deve eseguire alcun'azione esplicita di installazione, è sufficiente visualizzare il contenuto.

La natura open-source della libreria ha duplicato il problema. Da un lato, il repository pubblico ha permesso a chiunque di studiare il codice e identificare il pattern vulnerabile; dall'altro, ha reso la patch immediatamente verificabile e integrabile. La decisione di Samsung di non emettere CVE proprio né advisory di sicurezza separato lascia un vuoto nel tracciamento formale: sviluppatori e security team che si affidano a feed CVE o database NVD non troveranno registrazione autonoma di questa falla, ma solo la referenza ZDI.

La scelta di promuovere tipi a int piuttosto che aggiungere controlli di bounds espliciti è tecnicamente significativa. L'espansione dello spazio numerico elimina la condizione di overflow per input realisticamente craftabili, ma non introduce validazione semantica: un file Lottie con miliardi di punti dichiarati potrebbe ancora causare denial-of-service per allocazione memoria eccessiva. La patch è correttiva, non difensiva in profondità.

"The issue results from the lack of proper validation of user-supplied data, which can result in an integer truncation before writing to memory. An attacker can leverage this vulnerability to execute code in the context of the current process." — ZDI Advisory ZDI-26-359

Cosa fare adesso

Per gli sviluppatori che integrano rlottie, la priorità è verificare la versione in uso rispetto al commit dcfde72eae1b0464dc0dd760aec00ada6a148635 della pull request #589, mergeata il 12 maggio 2026. Distribuzioni che includono rlottie come submodule o dipendenza devono essere aggiornate con il codice post-merge.

Gli operatori di app che processano animazioni Lottie da fonti utente dovrebbero implementare sandboxing del parser grafico quando l'architettura lo consente: isolare rlottie in processo separato con privilegi minimi riduce l'impatto di eventuali future vulnerabilità simili. Il parsing di file multimediali complessi in processo privilegiato rimane un anti-pattern di sicurezza riconosciuto.

Per i security team, l'advisory ZDI va inserito nel monitoring nonostante l'assenza di CVE: la criticità RCE e la facilità di interazione utente richiedono tracciamento attivo. La verifica dell'eventuale presenza di rlottie in inventario software interno, tramite scansione dipendenze o analisi composizione, è necessaria per quantificare l'esposizione organizzativa.

Chi riceve animazioni Lottie da contatti non verificati — in particolare in client di messaggistica che usano sticker animati — deve considerare che la visualizzazione automatica rappresenta un vettore d'attacco concreto per questa classe di vulnerabilità. La disabilitazione dell'anteprima automatica di media da fonti sconosciute, dove l'app lo consente, riduce la superficie d'esposizione indipendente dalla patch specifica.

Perché il caso rlottie interessa oltre Samsung

La rilevanza di ZDI-26-359 trascende il singolo vendor. Lottie è diventato un formato de facto per UI animate, con implementazioni in Adobe After Effects, Telegram, WhatsApp, e framework cross-platform. La libreria rlottie di Samsung, pur non essendo l'unica implementazione, è tra le più performanti per dispositivi mobile con risorse limitate. La sua adozione in ecosistemi oltre il controllo diretto di Samsung crea una catena di dipendenza invisibile agli utenti finali.

Il caso evidenzia anche un gap nel ciclo di disclosure: senza CVE assegnato e con advisory vendor assente, la vulnerabilità rischia di rimanere invisibile a strumenti di gestione patrimonio informatico standard. La ZDI funge da fonte primaria per la documentazione, ma la sua natura di aggregatore indipendente non sostituisce il processo di tracciamento formale del vendor. Per sviluppatori che integrano codice open-source, la lezione operativa è che la sicurezza dipende tanto dalla qualità del patch management quanto dalla visibilità del canale di disclosure.

La correzione — un cambio di tre lettere in dichiarazioni di tipo, ripetuto in tre file — ha richiesto mesi di coordinamento per essere resa pubblica. La semplicità tecnica del fix contrasta con la complessità del suo dispiegamento: migliaia di app potenzialmente interessate, nessun meccanismo di aggiornamento automatico, nessuna versione di sicurezza rilasciata. Il problema del 2026 non è più la scoperta dei bug, ma la certezza che le correzioni raggiungano il codice in produzione.

Domande frequenti

È necessario aggiornare il telefono Samsung per essere protetti?
L'advisory ZDI non specifica quali prodotti Samsung integrino la versione vulnerabile di rlottie, né se gli aggiornamenti sistema di Samsung contengano già la patch. L'unica certezza è la disponibilità del fix nel repository open-source dal 12 maggio 2026.

La vulnerabilità richiede che l'utente apra un file specifico?
Secondo l'advisory ZDI, "interaction with the rlottie library is required to exploit this vulnerability but attack vectors may vary depending on the implementation". La sola visualizzazione di un'animazione Lottie in un'app che usa rlottie è sufficiente; l'utente non deve necessariamente aprire un file come allegato esplicito.

Perché non è stato assegnato un CVE?
Il dossier non documenta alcun CVE assegnato a ZDI-26-359. La ZDI può richiedere CVE in fase di disclosure, ma la mancanza nel testo dell'advisory estratto indica che non è disponibile nel formato pubblico. Questo non significa che non esista, ma che non è riportato nelle fonti accessibili.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. zerodayinitiative.com
  2. github.com