<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 02:28:04 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-275956</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-275956</link>
      <description>EUVD-2026-275956</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-275956</guid>
    </item>
    <item>
      <title>fkie_cve-2026-32322</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-32322</link>
      <description>&lt;p&gt;soroban-sdk is a Rust SDK for Soroban contracts. Prior to 22.0.11, 23.5.3, and 25.3.0, The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., &amp;gt;= r). The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations. Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values. This vulnerability is fixed in 22.0.11, 23.5.3, and 25.3.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;soroban-sdk is a Rust SDK for Soroban contracts. Prior to 22.0.11, 23.5.3, and 25.3.0, The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., &amp;gt;= r). The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations. Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values. This vulnerability is fixed in 22.0.11, 23.5.3, and 25.3.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-32322</guid>
    </item>
    <item>
      <title>GHSA-x2hw-px52-wp4m — rs-soroban-sdk: `Fr` scalar field equality comparison bypasses modular reduction</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-x2hw-px52-wp4m</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: soroban-sdk&lt;/p&gt;
&lt;p&gt;# Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;Missing modular reduction in `Fr` causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;The `Fr` (scalar field) types for BN254 and BLS12-381 in `soroban-sdk` compared values using their raw `U256` representation without first reducing modulo the field modulus `r`. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., &amp;gt;= `r`).&lt;/p&gt;
&lt;p&gt;The vulnerability requires an attacker to supply crafted `Fr` values through contract inputs, and compare them directly without going through host-side arithmetic operations.&lt;/p&gt;
&lt;p&gt;Smart contracts that rely on `Fr` equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;`Fr` types for both curves are wrappers around `U256`. The `PartialEq` implementation compared the raw `U256` values directly. However, the constructors (`from_u256`, `from_bytes`, `From&amp;lt;U256&amp;gt;`) accepted arbitrary `U256` values without reducing them modulo `r`. This meant two `Fr` values representing the same field element (e.g., `1` and `r + 1`) could have different internal representations and compare as not-equal.&lt;/p&gt;
&lt;p&gt;This issue was…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: soroban-sdk&lt;/p&gt;
&lt;p&gt;# Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;Missing modular reduction in `Fr` causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;The `Fr` (scalar field) types for BN254 and BLS12-381 in `soroban-sdk` compared values using their raw `U256` representation without first reducing modulo the field modulus `r`. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., &amp;gt;= `r`).&lt;/p&gt;
&lt;p&gt;The vulnerability requires an attacker to supply crafted `Fr` values through contract inputs, and compare them directly without going through host-side arithmetic operations.&lt;/p&gt;
&lt;p&gt;Smart contracts that rely on `Fr` equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;`Fr` types for both curves are wrappers around `U256`. The `PartialEq` implementation compared the raw `U256` values directly. However, the constructors (`from_u256`, `from_bytes`, `From&amp;lt;U256&amp;gt;`) accepted arbitrary `U256` values without reducing them modulo `r`. This meant two `Fr` values representing the same field element (e.g., `1` and `r + 1`) could have different internal representations and compare as not-equal.&lt;/p&gt;
&lt;p&gt;This issue was…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-x2hw-px52-wp4m</guid>
    </item>
  </channel>
</rss>
