Sari la conținut
Braincap
← Toate articolele

FastJSON: RCE zero-day exploatat activ (CVE-2026-16723) și fără patch

de Claudiu Hulea · IT Management Consultant

Ilustrație a unei execuții de cod prin deserializare JSON nesigură

O vulnerabilitate critică de tip execuție de cod la distanță (RCE) în biblioteca Java FastJSON (CVE-2026-16723) este exploatată activ în atacuri reale, în special împotriva companiilor din SUA. Problema e agravată de un detaliu neplăcut: FastJSON 1.x nu mai este menținut, deci nu există un patch. Mai jos, ce este, cum funcționează și ce faci în loc de „așteaptă actualizarea“.

Pe scurt

  • Biblioteca: FastJSON — bibliotecă open-source Java (de la Alibaba) pentru serializare/deserializare JSON, foarte răspândită.
  • Vulnerabilitate: CVE-2026-16723, RCE prin deserializare nesigură, severitate critică.
  • Afectat: FastJSON 1.2.68 – 1.2.83. Neafectate: 1.2.60 și mai vechi, fastjson2 și implementările care nu sunt „fat-JAR“.
  • Patch: nu există — FastJSON 1.x nu mai este întreținut activ.
  • Stare: exploatat activ; ținte principale în SUA (plus Singapore, Canada), în sectoare precum servicii financiare, sănătate, retail și IT.

Cum funcționează

Atacatorii abuzează procesarea @type din deserializare pentru a strecura clase malițioase în câmpuri de tip Object sau Map. Cauza de fond: logica de rezolvare a tipurilor face căutări de resurse controlate de atacator înainte de a aplica restricțiile AutoType — astfel, încărcarea unei clase malițioase e posibilă fără AutoType activat și fără lanțuri de „gadget“ din biblioteci terțe.

Două aspecte fac vulnerabilitatea deosebit de periculoasă:

  • Ocolește apărările clasice: chiar dacă specifici clasa-țintă la deserializare, nu ești protejat de CVE-2026-16723.
  • Exploatarea vizează în special implementările Spring Boot de tip fat-JAR (lansate cu java -jar xxx.jar).

De ce e periculos

Ai un RCE exploatat deja în sălbăticie, într-o bibliotecă larg folosită, care nu mai primește corecții și care ocolește configurările defensive uzuale. Combinația „exploatat activ + fără patch“ o mută din categoria „de urmărit“ în „de acționat acum“.

Ce ai de făcut acum

  1. Activează SafeMode în FastJSON imediat, sau treci la o build neafectată, ca măsură de urgență.
  2. Migrează la fastjson2, care folosește un model de deserializare polimorfică bazat pe listă permisă (allowlist-first) — mult mai sigur prin design.
  3. Inventariază unde folosești FastJSON 1.x — inclusiv ca dependență tranzitivă (adusă de alte biblioteci), nu doar directă. Aici un inventar de componente (SBOM) sau un audit ajută enorm.
  4. Monitorizează și filtrează: caută în trafic payload-uri de deserializare cu @type suspect și tratează sistemele expuse ca prioritare.

Ce reținem

Bibliotecile de deserializare sunt o suprafață clasică de RCE, iar componentele ajunse la sfârșitul vieții (EOL) sunt un risc special: când apare o vulnerabilitate, nu vine niciun patch. Inventarul dependențelor și eliminarea componentelor nementinute sunt exact genul de igienă pe care un audit de securitate IT o scoate la lumină, iar un test de penetrare confirmă ce e real exploatabil.

Surse

Întrebări frecvente

Ce este vulnerabilitatea FastJSON CVE-2026-16723?

O vulnerabilitate critică de execuție de cod la distanță (RCE) prin deserializare nesigură în biblioteca Java FastJSON, exploatată activ în atacuri reale. Afectează FastJSON 1.2.68–1.2.83; neafectate sunt 1.2.60 și mai vechi, fastjson2 și implementările care nu sunt fat-JAR.

Există un patch?

Nu. FastJSON 1.x nu mai este întreținut activ, deci nu vine nicio corecție. Combinația „exploatat activ plus fără patch" o mută din „de urmărit" în „de acționat acum".

De ce ocolește apărările clasice?

Pentru că logica de rezolvare a tipurilor face căutări de resurse controlate de atacator înainte de a aplica restricțiile AutoType — deci încărcarea unei clase malițioase e posibilă fără AutoType activat și fără lanțuri de gadget din biblioteci terțe. Chiar dacă specifici clasa-țintă la deserializare, nu ești protejat.

Ce fac dacă folosesc FastJSON 1.x?

Ca urgență, activează SafeMode sau treci la o build neafectată. Apoi migrează la fastjson2 (model allowlist-first, mai sigur prin design), inventariază unde folosești FastJSON 1.x inclusiv ca dependență tranzitivă (SBOM/audit), și monitorizează traficul pentru payload-uri de deserializare cu `@type` suspect.