https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 08:18:19 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-248512 EUVD-2026-248512 https://cve.radiocsirt.org/vuln/euvd-2026-248512 https://cve.radiocsirt.org/vuln/fkie_cve-2022-50237 <p>The ed25519-dalek crate before 2 for Rust allows a double public key signing function oracle attack. The Keypair implementation leads to a simple computation for extracting a private key.</p> <p>The ed25519-dalek crate before 2 for Rust allows a double public key signing function oracle attack. The Keypair implementation leads to a simple computation for extracting a private key.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2022-50237 https://cve.radiocsirt.org/vuln/ghsa-w5vr-6qhr-36cc <p><strong>Affected:</strong> crates.io: ed25519-dalek</p> <p>Versions of `ed25519-dalek` prior to v2.0 model private and public keys as separate types which can be assembled into a `Keypair`, and also provide APIs for serializing and deserializing 64-byte private/public keypairs.</p> <p>Such APIs and serializations are inherently unsafe as the public key is one of the inputs used in the deterministic computation of the `S` part of the signature, but not in the `R` value. An adversary could somehow use the signing function as an oracle that allows arbitrary public keys as input can obtain two signatures for the same message sharing the same `R` and only differ on the `S` part.</p> <p>Unfortunately, when this happens, one can easily extract the private key.</p> <p>Revised public APIs in v2.0 of `ed25519-dalek` do NOT allow a decoupled private/public keypair as signing input, except as part of specially labeled &#34;hazmat&#34; APIs which are clearly labeled as being dangerous if misused.</p> <p><strong>Affected:</strong> crates.io: ed25519-dalek</p> <p>Versions of `ed25519-dalek` prior to v2.0 model private and public keys as separate types which can be assembled into a `Keypair`, and also provide APIs for serializing and deserializing 64-byte private/public keypairs.</p> <p>Such APIs and serializations are inherently unsafe as the public key is one of the inputs used in the deterministic computation of the `S` part of the signature, but not in the `R` value. An adversary could somehow use the signing function as an oracle that allows arbitrary public keys as input can obtain two signatures for the same message sharing the same `R` and only differ on the `S` part.</p> <p>Unfortunately, when this happens, one can easily extract the private key.</p> <p>Revised public APIs in v2.0 of `ed25519-dalek` do NOT allow a decoupled private/public keypair as signing input, except as part of specially labeled &#34;hazmat&#34; APIs which are clearly labeled as being dangerous if misused.</p> https://cve.radiocsirt.org/vuln/ghsa-w5vr-6qhr-36cc https://cve.radiocsirt.org/vuln/opensuse-su-2026:11838-1 <p>pijul-1.0.0~beta.23-1.1 on GA media</p> <p>pijul-1.0.0~beta.23-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11838-1 https://cve.radiocsirt.org/vuln/rustsec-2022-0093 <p><strong>Affected:</strong> crates.io: ed25519-dalek</p> <p>Versions of `ed25519-dalek` prior to v2.0 model private and public keys as separate types which can be assembled into a `Keypair`, and also provide APIs for serializing and deserializing 64-byte private/public keypairs.</p> <p>Such APIs and serializations are inherently unsafe as the public key is one of the inputs used in the deterministic computation of the `S` part of the signature, but not in the `R` value. An adversary could somehow use the signing function as an oracle that allows arbitrary public keys as input can obtain two signatures for the same message sharing the same `R` and only differ on the `S` part.</p> <p>Unfortunately, when this happens, one can easily extract the private key.</p> <p>Revised public APIs in v2.0 of `ed25519-dalek` do NOT allow a decoupled private/public keypair as signing input, except as part of specially labeled &#34;hazmat&#34; APIs which are clearly labeled as being dangerous if misused.</p> <p><strong>Affected:</strong> crates.io: ed25519-dalek</p> <p>Versions of `ed25519-dalek` prior to v2.0 model private and public keys as separate types which can be assembled into a `Keypair`, and also provide APIs for serializing and deserializing 64-byte private/public keypairs.</p> <p>Such APIs and serializations are inherently unsafe as the public key is one of the inputs used in the deterministic computation of the `S` part of the signature, but not in the `R` value. An adversary could somehow use the signing function as an oracle that allows arbitrary public keys as input can obtain two signatures for the same message sharing the same `R` and only differ on the `S` part.</p> <p>Unfortunately, when this happens, one can easily extract the private key.</p> <p>Revised public APIs in v2.0 of `ed25519-dalek` do NOT allow a decoupled private/public keypair as signing input, except as part of specially labeled &#34;hazmat&#34; APIs which are clearly labeled as being dangerous if misused.</p> https://cve.radiocsirt.org/vuln/rustsec-2022-0093 https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50237 <p><strong>Affected:</strong> Ubuntu:25.10: rust-curve25519-dalek, Ubuntu:26.04:LTS: rust-curve25519-dalek</p> <p>The ed25519-dalek crate before 2 for Rust allows a double public key signing function oracle attack. The Keypair implementation leads to a simple computation for extracting a private key.</p> <p><strong>Affected:</strong> Ubuntu:25.10: rust-curve25519-dalek, Ubuntu:26.04:LTS: rust-curve25519-dalek</p> <p>The ed25519-dalek crate before 2 for Rust allows a double public key signing function oracle attack. The Keypair implementation leads to a simple computation for extracting a private key.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50237