Apache Fory: două vulnerabilități de deserializare

Două vulnerabilități Apache Fory publicate pe 21 iulie merită atenția echipelor care schimbă date structurate între servicii. Fory este un framework de serializare performant, cu implementări pentru mai multe limbaje. Cele două probleme nu afectează identic fiecare implementare sau configurare, deci răspunsul util începe cu identificarea limbajului, versiunii și funcției folosite.

Advisory-urile Apache recomandă actualizarea componentelor afectate la 1.4.0 și nu raportează exploatare activă. Expunerea depinde de posibilitatea ca date serializate care nu sunt de încredere sau sunt influențate de atacator să ajungă la căile vulnerabile de deserializare.

CVE-2026-64608: corupere de memorie în compatible-mode C++

CVE-2026-64608 afectează implementarea Apache Fory C++ de la 0.14.0 până înainte de 1.4.0. În timpul deserializării compatible-mode, căile care sar peste câmpuri nu validează corect dacă tipurile declarate corespund datelor reale. O schemă inconsistentă construită special poate produce type confusion și citiri sau scrieri în afara limitelor memoriei.

Doar implementarea C++ este vizată de acest advisory. Întrebarea de securitate nu este doar dacă Fory apare într-un repository, ci dacă un serviciu C++ deserializează în compatible mode și dacă un utilizator extern, partener, producător din coadă sau serviciu upstream compromis poate influența acei octeți.

CVE-2026-64609: citire out-of-bounds în zero-copy Java

CVE-2026-64609 afectează deserializarea Java/JVM atunci când funcția opțională out-of-band zero-copy este activată. Calea readAlignedVarUint poate citi dincolo de limitele bufferului deoarece folosește sun.misc.Unsafe fără validarea necesară a limitelor.

Aplicațiile care nu activează deserializarea out-of-band zero-copy nu sunt afectate de această cale, conform advisory-ului. Pentru liniile de pachete Java afectate, destinația recomandată este Fory 1.4.0. Confirmă dependența rezolvată în artefactul construit, nu doar versiunea declarată în fișierul principal de build.

Răspuns practic pentru echipele de platformă și produs

• Caută Apache Fory și fostele coordonate Fury în repository-uri, lockfile-uri, SBOM-uri, imagini container și artefacte shaded sau vendored
• Asociază fiecare rezultat cu implementarea C++, Java sau alt limbaj; nu atribui mecanic aceeași vulnerabilitate fiecărei utilizări Fory
• Identifică deserializarea C++ compatible-mode și folosirea Java out-of-band zero-copy, apoi urmărește cine poate furniza inputul serializat
• Actualizează componentele C++ și Java afectate la 1.4.0, reconstruiește artefactele și rulează teste de interoperabilitate și input invalid
• Până la finalizarea rollout-ului, respinge la graniță payload-urile serializate care nu sunt de încredere, limitează producătorii și izolează procesul de credențiale sensibile
• Verifică crash-uri, rezultate de sanitizer, restartări anormale ale workerilor și creșteri de mesaje invalide pentru indicii că s-a ajuns pe căile vulnerabile

Lecția mai largă: un SBOM are nevoie de context runtime

Numele unei dependențe poate stabili o expunere posibilă, dar nu poate spune singur dacă o cale specifică unui limbaj și unei funcții este accesibilă. CVE-2026-64608 și CVE-2026-64609 arată de ce trierea are nevoie de versiunea activului, limbajul implementării, funcțiile activate și fluxul datelor.

Pentru un proces de vulnerability handling aliniat NIS2, păstrează dovada dependenței, serviciul afectat, granița de input, decizia de risc, responsabilul, build-ul instalat și rezultatul validării. Awarely Monitor ajută echipele să lege inventarul SBOM și pachetele de workflow-ul CVE și dovezile remedierii, fără să trateze fiecare rezultat al scannerului ca risc identic.