CVE-2026-33184
WysokieCVSS 7.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 38 - wyżej niż 38% wszystkich znanych CVE
Streszczenie
W nimiq/core-rs-albatross (implementacja protokołu Nimiq Proof-of-Stake w Rust) przed wersją 1.3.0, procedura handshake akceptuje od peera limit równy 0 i przechowuje go bez zmian. W ścieżce HandshakeAck limit 0 powoduje zwrócenie zerowych kontaktów, co wygląda nieszkodliwie. Później, w stanie Established, obliczenie self.peer_list_limit.unwrap() jako usize - 1 przy limicie 0 powoduje zawinięcie do usize::MAX, co prowadzi do paniki przy próbie alokacji pamięci.
Ocena ryzyka
Atakujący może zdalnie spowodować awarię węzła Nimiq, co prowadzi do przerwy w działaniu sieci i potencjalnej utraty środków lub zakłócenia konsensusu.
Rekomendacja
Zaktualizuj nimiq/core-rs-albatross do wersji 1.3.0, która zawiera poprawkę.
Inne podatności w nimiq/core-rs-albatross
Zobacz wszystkie- CVE-2026-28402Wysokie
W wersjach przed 1.2.2 biblioteka nimiq/core-rs-albatross zawiera podatność, która pozwala złośliwemu lub skompromitowanemu walidatorowi na opublikowanie propozycji makro bloku z niezgodnym `header.body_root`. To może prowadzić do awarii walidatorów z powodu niezgodności weryfikacji.
- CVE-2026-34061Średnie
nimiq/core-rs-albatross przed wersją 1.3.0 zawiera podatność, w której wybrany walidator-proposer może wysłać blok makro wyborczy, którego header.interlink nie zgadza się z kanonicznym następnym interlinkiem. Uczciwi walidatorzy akceptują tę propozycję, ponieważ funkcja verify_macro_block_proposal() nie sprawdza wiązania interlink dla bloków wyborczych. Ten sam sfinalizowany blok jest później odrzucany przez verify_block() z błędem InvalidInterlink, ale dzieje się to po podjęciu decyzji przez Tendermint, co może prowadzić do problemów z konsensusem.
Oryginalny opis (angielski, źródło NVD)
nimiq/core-rs-albatross is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.3.0, the discovery handler accepts a peer-controlled limit during handshake and stores it unchanged. The immediate HandshakeAck path then honors limit = 0 and returns zero contacts, which makes the session look benign. Later, after the same session reaches Established, the periodic update path computes self.peer_list_limit.unwrap() as usize - 1. With limit = 0, that wraps to usize::MAX and then in rand 0.9.2, choose_multiple() immediately attempts Vec::with_capacity(amount), which deterministically panics with capacity overflow. This issue has been patched in version 1.3.0.