<?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>Sun, 04 Oct 2026 17:09:16 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-255247</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-255247</link>
      <description>EUVD-2026-255247</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-255247</guid>
    </item>
    <item>
      <title>fkie_cve-2025-62495</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-62495</link>
      <description>&lt;p&gt;An integer overflow vulnerability exists in the QuickJS regular expression engine (libregexp) due to an inconsistent representation of the bytecode buffer size.&lt;/p&gt;
&lt;p&gt;*  The regular expression bytecode is stored in a DynBuf structure, which correctly uses a $\text{size}\_\text{t}$ (an unsigned type, typically 64-bit) for its size member.&lt;/p&gt;
&lt;p&gt;*  However, several functions, such as re_emit_op_u32 and other internal parsing routines, incorrectly cast or store this DynBuf $\text{size}\_\text{t}$ value into a signed int (typically 32-bit).&lt;/p&gt;
&lt;p&gt;*  When a large or complex regular expression (such as those generated by a recursive pattern in a Proof-of-Concept) causes the bytecode size to exceed $2^{31}$ bytes (the maximum positive value for a signed 32-bit integer), the size value wraps around, resulting in a negative integer when stored in the int variable (Integer Overflow).&lt;/p&gt;
&lt;p&gt;*  This negative value is subsequently used in offset calculations. For example, within functions like re_parse_disjunction, the negative size is used to compute an offset (pos) for patching a jump instruction.&lt;/p&gt;
&lt;p&gt;*  This negative offset is then incorrectly added to the buffer pointer (s-&amp;gt;byte\_code.buf + pos), leading to an out-of-bounds write on the first line of the snippet below:&lt;/p&gt;
&lt;p&gt;put_u32(s-&amp;gt;byte_code.buf + pos, len);&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;An integer overflow vulnerability exists in the QuickJS regular expression engine (libregexp) due to an inconsistent representation of the bytecode buffer size.&lt;/p&gt;
&lt;p&gt;*  The regular expression bytecode is stored in a DynBuf structure, which correctly uses a $\text{size}\_\text{t}$ (an unsigned type, typically 64-bit) for its size member.&lt;/p&gt;
&lt;p&gt;*  However, several functions, such as re_emit_op_u32 and other internal parsing routines, incorrectly cast or store this DynBuf $\text{size}\_\text{t}$ value into a signed int (typically 32-bit).&lt;/p&gt;
&lt;p&gt;*  When a large or complex regular expression (such as those generated by a recursive pattern in a Proof-of-Concept) causes the bytecode size to exceed $2^{31}$ bytes (the maximum positive value for a signed 32-bit integer), the size value wraps around, resulting in a negative integer when stored in the int variable (Integer Overflow).&lt;/p&gt;
&lt;p&gt;*  This negative value is subsequently used in offset calculations. For example, within functions like re_parse_disjunction, the negative size is used to compute an offset (pos) for patching a jump instruction.&lt;/p&gt;
&lt;p&gt;*  This negative offset is then incorrectly added to the buffer pointer (s-&amp;gt;byte\_code.buf + pos), leading to an out-of-bounds write on the first line of the snippet below:&lt;/p&gt;
&lt;p&gt;put_u32(s-&amp;gt;byte_code.buf + pos, len);&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-62495</guid>
    </item>
    <item>
      <title>GHSA-g8rq-rjvv-4hcc</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-g8rq-rjvv-4hcc</link>
      <description>&lt;p&gt;An integer overflow vulnerability exists in the QuickJS regular expression engine (libregexp) due to an inconsistent representation of the bytecode buffer size.&lt;/p&gt;
&lt;p&gt;*  The regular expression bytecode is stored in a DynBuf structure, which correctly uses a $\text{size}\_\text{t}$ (an unsigned type, typically 64-bit) for its size member.&lt;/p&gt;
&lt;p&gt;*  However, several functions, such as re_emit_op_u32 and other internal parsing routines, incorrectly cast or store this DynBuf $\text{size}\_\text{t}$ value into a signed int (typically 32-bit).&lt;/p&gt;
&lt;p&gt;*  When a large or complex regular expression (such as those generated by a recursive pattern in a Proof-of-Concept) causes the bytecode size to exceed $2^{31}$ bytes (the maximum positive value for a signed 32-bit integer), the size value wraps around, resulting in a negative integer when stored in the int variable (Integer Overflow).&lt;/p&gt;
&lt;p&gt;*  This negative value is subsequently used in offset calculations. For example, within functions like re_parse_disjunction, the negative size is used to compute an offset (pos) for patching a jump instruction.&lt;/p&gt;
&lt;p&gt;*  This negative offset is then incorrectly added to the buffer pointer (s-&amp;gt;byte\_code.buf + pos), leading to an out-of-bounds write on the first line of the snippet below:&lt;/p&gt;
&lt;p&gt;put_u32(s-&amp;gt;byte_code.buf + pos, len);&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;An integer overflow vulnerability exists in the QuickJS regular expression engine (libregexp) due to an inconsistent representation of the bytecode buffer size.&lt;/p&gt;
&lt;p&gt;*  The regular expression bytecode is stored in a DynBuf structure, which correctly uses a $\text{size}\_\text{t}$ (an unsigned type, typically 64-bit) for its size member.&lt;/p&gt;
&lt;p&gt;*  However, several functions, such as re_emit_op_u32 and other internal parsing routines, incorrectly cast or store this DynBuf $\text{size}\_\text{t}$ value into a signed int (typically 32-bit).&lt;/p&gt;
&lt;p&gt;*  When a large or complex regular expression (such as those generated by a recursive pattern in a Proof-of-Concept) causes the bytecode size to exceed $2^{31}$ bytes (the maximum positive value for a signed 32-bit integer), the size value wraps around, resulting in a negative integer when stored in the int variable (Integer Overflow).&lt;/p&gt;
&lt;p&gt;*  This negative value is subsequently used in offset calculations. For example, within functions like re_parse_disjunction, the negative size is used to compute an offset (pos) for patching a jump instruction.&lt;/p&gt;
&lt;p&gt;*  This negative offset is then incorrectly added to the buffer pointer (s-&amp;gt;byte\_code.buf + pos), leading to an out-of-bounds write on the first line of the snippet below:&lt;/p&gt;
&lt;p&gt;put_u32(s-&amp;gt;byte_code.buf + pos, len);&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-g8rq-rjvv-4hcc</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-62495</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-62495</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:24.04:LTS: quickjs, Ubuntu:25.10: quickjs, Ubuntu:26.04:LTS: quickjs&lt;/p&gt;
&lt;p&gt;An integer overflow vulnerability exists in the QuickJS regular expression engine (libregexp) due to an inconsistent representation of the bytecode buffer size.   *  The regular expression bytecode is stored in a DynBuf structure, which correctly uses a $\text{size}\_\text{t}$ (an unsigned type, typically 64-bit) for its size member.   *  However, several functions, such as re_emit_op_u32 and other internal parsing routines, incorrectly cast or store this DynBuf $\text{size}\_\text{t}$ value into a signed int (typically 32-bit).   *  When a large or complex regular expression (such as those generated by a recursive pattern in a Proof-of-Concept) causes the bytecode size to exceed $2^{31}$ bytes (the maximum positive value for a signed 32-bit integer), the size value wraps around, resulting in a negative integer when stored in the int variable (Integer Overflow).   *  This negative value is subsequently used in offset calculations. For example, within functions like re_parse_disjunction, the negative size is used to compute an offset (pos) for patching a jump instruction.   *  This negative offset is then incorrectly added to the buffer pointer (s-&amp;gt;byte\_code.buf + pos), leading to an out-of-bounds write on the first line of the snippet below: put_u32(s-&amp;gt;byte_code.buf + pos, len);&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:24.04:LTS: quickjs, Ubuntu:25.10: quickjs, Ubuntu:26.04:LTS: quickjs&lt;/p&gt;
&lt;p&gt;An integer overflow vulnerability exists in the QuickJS regular expression engine (libregexp) due to an inconsistent representation of the bytecode buffer size.   *  The regular expression bytecode is stored in a DynBuf structure, which correctly uses a $\text{size}\_\text{t}$ (an unsigned type, typically 64-bit) for its size member.   *  However, several functions, such as re_emit_op_u32 and other internal parsing routines, incorrectly cast or store this DynBuf $\text{size}\_\text{t}$ value into a signed int (typically 32-bit).   *  When a large or complex regular expression (such as those generated by a recursive pattern in a Proof-of-Concept) causes the bytecode size to exceed $2^{31}$ bytes (the maximum positive value for a signed 32-bit integer), the size value wraps around, resulting in a negative integer when stored in the int variable (Integer Overflow).   *  This negative value is subsequently used in offset calculations. For example, within functions like re_parse_disjunction, the negative size is used to compute an offset (pos) for patching a jump instruction.   *  This negative offset is then incorrectly added to the buffer pointer (s-&amp;gt;byte\_code.buf + pos), leading to an out-of-bounds write on the first line of the snippet below: put_u32(s-&amp;gt;byte_code.buf + pos, len);&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-62495</guid>
    </item>
  </channel>
</rss>
