<?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://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T17:53:39.921964+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" 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://db.gcve.eu/vuln/cve-2026-58049</id>
    <title>CVE-2026-58049 — FFmpeg - Out-of-Bounds Write in RASC Decoder decode_dlta()</title>
    <updated>2026-09-30T17:53:39.923538+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> FFmpeg, Red Hat Enterprise Linux AI 3.0 for RHEL 9, Red Hat Enterprise Linux AI 3.2 for RHEL 9, Red Hat Enterprise Linux AI 3.3 for RHEL 9, Red Hat Enterprise Linux AI 3.5 for RHEL 9, Red Hat OpenShift AI 3.4, Red Hat AI Inference Server, Red Hat Enterprise Linux AI (RHEL AI) 3, Red Hat OpenShift AI (RHOAI)</p>
<p>FFmpeg's RASC video decoder (decode_dlta in libavcodec/rasc.c) performs 32-bit reads and writes at the row cursor before the NEXT_LINE row-boundary check and validates the DLTA region in pixel rather than byte units, so a DLTA run on a PAL8 frame can access several bytes past the row allocation. A crafted media stream using the RASC FourCC, decoded by libavcodec, triggers a bitstream-controlled out-of-bounds heap write and adjacent out-of-bounds read, leading to memory corruption.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-58049"/>
  </entry>
</feed>
