<?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 21:45:10 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-368159</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-368159</link>
      <description>EUVD-2026-368159</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-368159</guid>
    </item>
    <item>
      <title>fkie_cve-2026-54176</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-54176</link>
      <description>&lt;p&gt;backpack/crud provides Create, Read, Update &amp;amp; Delete (CRUD) functions for Backpack, a collection of Laravel packages that help users build custom administration panels. From 6.0.0 until 6.8.14 and 7.0.38, MyAccountController::postAccountInfoForm at POST /admin/edit-account-info permits AccountInfoRequest to update backpack_authentication_column(), which is email by default, without requiring current_password or otherwise verifying the account&amp;#39;s existing password. An attacker with a temporary authenticated Backpack session can change the account-recovery email and later use the password-reset flow after the original session expires, converting session compromise into persistent account takeover. The same mechanism permits an insider to set a personal recovery address before access is revoked. The separate password-change endpoint is not affected because it verifies old_password. This issue is fixed in versions 6.8.14 and 7.0.38.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;backpack/crud provides Create, Read, Update &amp;amp; Delete (CRUD) functions for Backpack, a collection of Laravel packages that help users build custom administration panels. From 6.0.0 until 6.8.14 and 7.0.38, MyAccountController::postAccountInfoForm at POST /admin/edit-account-info permits AccountInfoRequest to update backpack_authentication_column(), which is email by default, without requiring current_password or otherwise verifying the account&amp;#39;s existing password. An attacker with a temporary authenticated Backpack session can change the account-recovery email and later use the password-reset flow after the original session expires, converting session compromise into persistent account takeover. The same mechanism permits an insider to set a personal recovery address before access is revoked. The separate password-change endpoint is not affected because it verifies old_password. This issue is fixed in versions 6.8.14 and 7.0.38.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-54176</guid>
    </item>
    <item>
      <title>GHSA-9fw9-8c49-qch8 — Laravel Backpack CRUD: MyAccountController allows changing the login email without a current-password check</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-9fw9-8c49-qch8</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: backpack/crud&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`MyAccountController::postAccountInfoForm` allows an authenticated user to update
the authentication column (default: `email`) without verifying their current password.
Because email is the account-recovery anchor, this enables account takeover after
the attacker&amp;#39;s session ends: the new email address can be used to request a password
reset from outside the system.&lt;/p&gt;
&lt;p&gt;The password-change endpoint in the same controller correctly requires `old_password`
verification, so the gap is asymmetric.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;The `postAccountInfoForm` action passes `$request-&amp;gt;validated()` directly to
`$user-&amp;gt;update()`. The `AccountInfoRequest` whitelists the authentication column
(`email` by default) with no ownership challenge. Contrast this with
`ChangePasswordRequest`, which uses `Hash::check` against the stored password before
allowing any change.&lt;/p&gt;
&lt;p&gt;Scenarios where this is exploitable include:
- A brief unauthorized session (e.g. unattended workstation, XSS in the admin panel)
- An insider/offboarding case where a departing admin sets a personal email address
  before access is revoked, then resets the password after leaving&lt;/p&gt;
&lt;p&gt;## Patch&lt;/p&gt;
&lt;p&gt;Fixed in [#5990](https://github.com/Laravel-Backpack/CRUD/pull/5990) — the
authentication column is now protected by a `current_password` check (mirroring
`ChangePasswordRequest`) whenever its value changes.&lt;/p&gt;
&lt;p&gt;A stronger mitigation — sending a verification link to the new address before
persisting the change — can be layered on top using Laravel&amp;#39;s `MustV…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: backpack/crud&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`MyAccountController::postAccountInfoForm` allows an authenticated user to update
the authentication column (default: `email`) without verifying their current password.
Because email is the account-recovery anchor, this enables account takeover after
the attacker&amp;#39;s session ends: the new email address can be used to request a password
reset from outside the system.&lt;/p&gt;
&lt;p&gt;The password-change endpoint in the same controller correctly requires `old_password`
verification, so the gap is asymmetric.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;The `postAccountInfoForm` action passes `$request-&amp;gt;validated()` directly to
`$user-&amp;gt;update()`. The `AccountInfoRequest` whitelists the authentication column
(`email` by default) with no ownership challenge. Contrast this with
`ChangePasswordRequest`, which uses `Hash::check` against the stored password before
allowing any change.&lt;/p&gt;
&lt;p&gt;Scenarios where this is exploitable include:
- A brief unauthorized session (e.g. unattended workstation, XSS in the admin panel)
- An insider/offboarding case where a departing admin sets a personal email address
  before access is revoked, then resets the password after leaving&lt;/p&gt;
&lt;p&gt;## Patch&lt;/p&gt;
&lt;p&gt;Fixed in [#5990](https://github.com/Laravel-Backpack/CRUD/pull/5990) — the
authentication column is now protected by a `current_password` check (mirroring
`ChangePasswordRequest`) whenever its value changes.&lt;/p&gt;
&lt;p&gt;A stronger mitigation — sending a verification link to the new address before
persisting the change — can be layered on top using Laravel&amp;#39;s `MustV…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-9fw9-8c49-qch8</guid>
    </item>
  </channel>
</rss>
