<?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>Thu, 15 Oct 2026 21:39:55 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-277122</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-277122</link>
      <description>EUVD-2026-277122</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-277122</guid>
    </item>
    <item>
      <title>fkie_cve-2026-33650</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-33650</link>
      <description>&lt;p&gt;WWBN AVideo is an open source video platform. In versions up to and including 26.0, a user with the &amp;#34;Videos Moderator&amp;#34; permission can escalate privileges to perform full video management operations — including ownership transfer and deletion of any video — despite the permission being documented as only allowing video publicity changes (Active, Inactive, Unlisted). The root cause is that `Permissions::canModerateVideos()` is used as an authorization gate for full video editing in `videoAddNew.json.php`, while `videoDelete.json.php` only checks ownership, creating an asymmetric authorization boundary exploitable via a two-step ownership-transfer-then-delete chain. Commit 838e16818c793779406ecbf34ebaeba9830e33f8 contains a patch.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;WWBN AVideo is an open source video platform. In versions up to and including 26.0, a user with the &amp;#34;Videos Moderator&amp;#34; permission can escalate privileges to perform full video management operations — including ownership transfer and deletion of any video — despite the permission being documented as only allowing video publicity changes (Active, Inactive, Unlisted). The root cause is that `Permissions::canModerateVideos()` is used as an authorization gate for full video editing in `videoAddNew.json.php`, while `videoDelete.json.php` only checks ownership, creating an asymmetric authorization boundary exploitable via a two-step ownership-transfer-then-delete chain. Commit 838e16818c793779406ecbf34ebaeba9830e33f8 contains a patch.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-33650</guid>
    </item>
    <item>
      <title>GHSA-8x77-f38v-4m5j — AVideo: Video Moderator Privilege Escalation via Ownership Transfer Enables Arbitrary Video Deletion</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8x77-f38v-4m5j</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: wwbn/avideo&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;A user with the &amp;#34;Videos Moderator&amp;#34; permission can escalate privileges to perform full video management operations — including ownership transfer and deletion of any video — despite the permission being documented as only allowing video publicity changes (Active, Inactive, Unlisted). The root cause is that `Permissions::canModerateVideos()` is used as an authorization gate for full video editing in `videoAddNew.json.php`, while `videoDelete.json.php` only checks ownership, creating an asymmetric authorization boundary exploitable via a two-step ownership-transfer-then-delete chain.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;The `PERMISSION_INACTIVATEVIDEOS` (ID 11) permission is described as a limited moderator role in `plugin/Permissions/Permissions.php:213`:&lt;/p&gt;
&lt;p&gt;```php
$permissions[] = new PluginPermissionOption(
    Permissions::PERMISSION_INACTIVATEVIDEOS, 
    __(&amp;#39;Videos Moderator&amp;#39;), 
    __(&amp;#39;This is a level below the (Videos Admin), this type of user can change the video publicity (Active, Inactive, Unlisted)&amp;#39;), 
    &amp;#39;Permissions&amp;#39;
);
```&lt;/p&gt;
&lt;p&gt;However, `Permissions::canModerateVideos()` (`Permissions.php:175`) is reused as an authorization gate in multiple locations in `videoAddNew.json.php` that go far beyond status changes:&lt;/p&gt;
&lt;p&gt;**1. Upload gate bypass** (`videoAddNew.json.php:10`):
`User::canUpload()` (`user.php:2650`) returns `true` if `Permissions::canModerateVideos()` is true, granting moderators upload access.&lt;/p&gt;
&lt;p&gt;**2. Edit gate bypass** (`videoAddNew.json.php:19`):
```php
if (!Video::canEdit($_…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: wwbn/avideo&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;A user with the &amp;#34;Videos Moderator&amp;#34; permission can escalate privileges to perform full video management operations — including ownership transfer and deletion of any video — despite the permission being documented as only allowing video publicity changes (Active, Inactive, Unlisted). The root cause is that `Permissions::canModerateVideos()` is used as an authorization gate for full video editing in `videoAddNew.json.php`, while `videoDelete.json.php` only checks ownership, creating an asymmetric authorization boundary exploitable via a two-step ownership-transfer-then-delete chain.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;The `PERMISSION_INACTIVATEVIDEOS` (ID 11) permission is described as a limited moderator role in `plugin/Permissions/Permissions.php:213`:&lt;/p&gt;
&lt;p&gt;```php
$permissions[] = new PluginPermissionOption(
    Permissions::PERMISSION_INACTIVATEVIDEOS, 
    __(&amp;#39;Videos Moderator&amp;#39;), 
    __(&amp;#39;This is a level below the (Videos Admin), this type of user can change the video publicity (Active, Inactive, Unlisted)&amp;#39;), 
    &amp;#39;Permissions&amp;#39;
);
```&lt;/p&gt;
&lt;p&gt;However, `Permissions::canModerateVideos()` (`Permissions.php:175`) is reused as an authorization gate in multiple locations in `videoAddNew.json.php` that go far beyond status changes:&lt;/p&gt;
&lt;p&gt;**1. Upload gate bypass** (`videoAddNew.json.php:10`):
`User::canUpload()` (`user.php:2650`) returns `true` if `Permissions::canModerateVideos()` is true, granting moderators upload access.&lt;/p&gt;
&lt;p&gt;**2. Edit gate bypass** (`videoAddNew.json.php:19`):
```php
if (!Video::canEdit($_…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-8x77-f38v-4m5j</guid>
    </item>
  </channel>
</rss>
