<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-08T06:53:56.686606+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-341496</id>
    <title>EUVD-2026-341496</title>
    <updated>2026-10-08T06:53:56.737610+00:00</updated>
    <content>EUVD-2026-341496</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-341496"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-63761</id>
    <title>fkie_cve-2026-63761</title>
    <updated>2026-10-08T06:53:56.737646+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>SurrealDB before 3.1.0 silently substitutes the ES384 algorithm when a JWT access method is configured with ALGORITHM ES512 (DEFINE ACCESS ... TYPE JWT ALGORITHM ES512), because the underlying jsonwebtoken crate (v10.x) has no ES512 variant and the mapping defaults to ES384 without any error, warning, or log message. Users who supply the correct P-521 key for ES512 experience authentication handshake failures due to the curve mismatch with ES384 (which expects P-384), and tokens are rejected by external systems expecting genuine ES512 signatures. The flaw cannot be used to forge tokens or compromise data confidentiality or integrity, as ES384 remains cryptographically strong.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-63761"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-fwg2-gr34-q3w8</id>
    <title>GHSA-fwg2-gr34-q3w8 — SurrealDB: ES512 silently downgraded to ES384 due to jsonwebtoken crate limitation</title>
    <updated>2026-10-08T06:53:56.737682+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: surrealdb</p>
<p>When a user configures `ALGORITHM ES512` for any JWT access method (`DEFINE ACCESS ... TYPE JWT ALGORITHM ES512`), SurrealDB silently substitutes ES384 at all four internal algorithm conversion points. This occurs because the underlying `jsonwebtoken` crate (v10.x) does not include an ES512 algorithm variant, so the mapping defaults to ES384 without raising an error, warning, or log message.
 
Users who provide the correct P-521 key type for ES512 will experience authentication handshake failures due to the curve mismatch with ES384 (which expects P-384).
 
### Impact
 
Authentication handshake failures when using ES512 with the correct P-521 key type, and when tokens are verified by external systems expecting real ES512 signatures. 
 
This vulnerability cannot be exploited to forge tokens or compromise the integrity or confidentiality of data handled by SurrealDB, as ES384 remains cryptographically strong.</p>
<p>### Patches
 
Versions prior to SurrealDB `v3.1.0` are vulnerable.
 
The patches for SurrealDB `v3.1.0` block new `DEFINE ACCESS` statements using `ALGORITHM ES512` with a clear error message and add deprecation warnings at runtime for existing stored ES512 definitions.</p>
<p>### Workarounds
 
Users should reconfigure affected JWT access methods to use a supported algorithm such as ES384 (with a P-384 key pair) or another supported algorithm. Review any `DEFINE ACCESS` statements specifying `ALGORITHM ES512` and update them accordingly.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-fwg2-gr34-q3w8"/>
  </entry>
</feed>
