https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-19T08:09:31.151076+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/cnvd-2021-85296 cnvd-2021-85296 2026-10-19T08:09:31.236542+00:00 cnvd-2021-85296 https://cve.radiocsirt.org/vuln/euvd-2026-48194 EUVD-2026-48194 2026-10-19T08:09:31.236578+00:00 EUVD-2026-48194 https://cve.radiocsirt.org/vuln/fkie_cve-2020-36444 fkie_cve-2020-36444 2026-10-19T08:09:31.236592+00:00

An issue was discovered in the async-coap crate through 2020-12-08 for Rust. Send and Sync are implemented for ArcGuard<RC, T> without trait bounds on RC.

 https://cve.radiocsirt.org/vuln/ghsa-9j8q-m9x5-9g6j GHSA-9j8q-m9x5-9g6j — Data races in async-coap 2026-10-19T08:09:31.236620+00:00

Affected: crates.io: async-coap

An issue was discovered in the async-coap crate through 2020-12-08 for Rust. Affected versions of this crate implement Send/Sync for `ArcGuard<RC, T>` with no trait bounds on `RC`. This allows users to send `RC: !Send` to other threads and also allows users to concurrently access `Rc: !Sync` from multiple threads.

This can result in memory corruption from data race or other undefined behavior caused by sending `T: !Send` to other threads (e.g. dropping `MutexGuard<T>` in another thread that didn't lock its mutex).

 https://cve.radiocsirt.org/vuln/gsd-2020-36444 gsd-2020-36444 2026-10-19T08:09:31.236648+00:00 gsd-2020-36444 https://cve.radiocsirt.org/vuln/rustsec-2020-0124 RUSTSEC-2020-0124 — ArcGuard's Send and Sync should have bounds on RC 2026-10-19T08:09:31.236659+00:00

Affected: crates.io: async-coap

Affected versions of this crate implement Send/Sync for `ArcGuard<RC, T>` with no trait bounds on `RC`. This allows users to send `RC: !Send` to other threads and also allows users to concurrently access `Rc: !Sync` from multiple threads.

This can result in memory corruption from data race or other undefined behavior caused by sending `T: !Send` to other threads (e.g. dropping `MutexGuard<T>` in another thread that didn't lock its mutex).