CVE-2026-5450, CVE-2026-5358 i CVE-2026-5928: što se stvarno dogodilo i zašto je Rust bitan

Kad netko kaže "to je samo jedan CVE", obično je već zakasnio. Problem nije jedna oznaka, nego obrazac koji se ponavlja.

Kod ova tri slučaja — CVE-2026-5450, CVE-2026-5358 i CVE-2026-5928 — obrazac je vrlo jasan: greške su vezane uz memory-unsafe realnost C ekosustava, posebno u legacy C bibliotekama poput glibc-a.

Ovo nije tekst za dizanje panike. Ovo je tekst za donošenje tehničkih odluka.

Što je konkretno problematično

CVE-2026-5450

Ukratko: scenarij heap overflowa u scanf putanji pod specifičnim uvjetima. Ako to zvuči poznato, to je zato što i jest poznato — ove klase bugova se u C kodu ponavljaju desetljećima.

Nije pitanje "može li se ovo dogoditi opet", nego "gdje je sljedeći rubni slučaj koji još nismo pogodili testovima".

CVE-2026-5358

Ovdje je bitna nijansa: dio izvora vodi zapis kao rejected, uz argument da u tom konkretnom toku nema stvarnog prelaska granice povjerenja u Linux distribucijskom kontekstu.

Što to znači u praksi? Ne znači da je sve "lažna uzbuna". Znači da sigurnost nije copy/paste iz naslova CVE-a. Treba gledati status, kontekst i stvarni attack surface u tvom okruženju.

CVE-2026-5928

Greška u ungetwc wide-char putanji i pointer rukovanju može završiti curenjem podataka ili rušenjem procesa. I da, "samo crash" je i dalje incident ako pogađa kritičan servis.

Zašto su ova tri slučaja povezana baš s C-om

Zajednički nazivnik nije "glibc je loš", nego:

• ručno upravljanje memorijom
• osjetljivost na pointere i offsete
• puno legacy koda koji mora ostati kompatibilan

To je teren na kojem C briljira po performansama, ali i plaća sigurnosnu cijenu.

Zašto u ovom kontekstu Rust ima smisla

Rust nije čarolija. Ali za točno ovu klasu problema daje vrlo konkretan dobitak:

1. ownership model sprječava veliki dio use-after-free grešaka u safe kodu
2. granice pristupa memoriji su sigurnije po defaultu
3. unsafe je eksplicitan i auditabilan, pa znaš gdje je najveći rizik
4. compiler te tjera da eksplicitno riješiš rubne slučajeve umjesto da se nadaš da ih korisnik neće pogoditi

Drugim riječima: Rust ne uklanja bugove, ali smanjuje najskuplje bugove.

Kako to primijeniti bez "rewrite svega"

Najgora opcija je ideološki rat jezika. Najbolja opcija je postupan inženjerski plan:

• prvo migrirati input-heavy i parser slojeve
• nove mrežne servise i agente pisati memory-safe
• legacy C/C++ ostaviti iza jasnih granica i pojačanog testiranja
• u CI dodati sigurnosne gateove (fuzzing, dependency audit, statičke provjere)

To je realan put koji ne blokira delivery, a smanjuje operativni rizik.

Zaključak bez marketinga

Ako vodiš produkciju, ova tri CVE slučaja nisu "još jedna vijest". Oni su podsjetnik da memory safety više nije akademska tema.

Pitanje nije hoće li se pojaviti novi sličan bug. Pitanje je koliko će te koštati kad se pojavi.

I baš zato Rust u ovom slučaju nije trend, nego razuman alat za smanjenje rizika.

Izvori

• NVD: CVE-2026-5450
• NVD: CVE-2026-5928
• NVD / status rasprava: CVE-2026-5358
• SUSE CVE zapis: CVE-2026-5928
• Debian security tracker: CVE-2026-5450
• RustSec (primjer da i Rust ekosustav treba audit): RUSTSEC-2026-0103