<?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>Fri, 02 Oct 2026 17:06:16 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-46488 — motionEye: Authentication possible via password hash</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2026-46488</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; motioneye-project motioneye&lt;/p&gt;
&lt;p&gt;motionEye (mEye) is an online interface for a piece of software called &amp;#34;motion,&amp;#34; which is a video surveillance program with motion detection. Prior to 0.44.0, motionEye accepts the client-controlled meye_username and meye_password_hash cookies as authentication material without server-side session validation. An unauthenticated attacker who knows a target username and corresponding hash can set the cookies manually or cause them to be loaded by submitting blank credentials through the switch-user authentication flow, after which the server authenticates the attacker as that user. The administrator username and password-hash value are stored in /etc/motioneye/motion.conf, which is globally readable by default, allowing a local shell user to obtain reusable administrator credential material. Successful impersonation can enable account lockout, password changes and persistence, data enumeration, data destruction, and data exfiltration. This issue is fixed in version 0.44.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; motioneye-project motioneye&lt;/p&gt;
&lt;p&gt;motionEye (mEye) is an online interface for a piece of software called &amp;#34;motion,&amp;#34; which is a video surveillance program with motion detection. Prior to 0.44.0, motionEye accepts the client-controlled meye_username and meye_password_hash cookies as authentication material without server-side session validation. An unauthenticated attacker who knows a target username and corresponding hash can set the cookies manually or cause them to be loaded by submitting blank credentials through the switch-user authentication flow, after which the server authenticates the attacker as that user. The administrator username and password-hash value are stored in /etc/motioneye/motion.conf, which is globally readable by default, allowing a local shell user to obtain reusable administrator credential material. Successful impersonation can enable account lockout, password changes and persistence, data enumeration, data destruction, and data exfiltration. This issue is fixed in version 0.44.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2026-46488</guid>
    </item>
    <item>
      <title>GHSA-r3cw-c95m-wfh9 — motionEye: Authentication possible via password hash</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-r3cw-c95m-wfh9</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: motioneye&lt;/p&gt;
&lt;p&gt;### Summary
An authentication bypass vulnerability exists due to improper trust in client-controlled cookies. The application accepts user-supplied cookie values containing a username and password-hash-derived value as sufficient authentication material. These cookies can be set or modified prior to login, allowing an unauthenticated attacker to impersonate arbitrary users without knowledge of the plaintext password. This issue stems from the absence of server-side validation of authentication state and reliance on attacker-controlled cookie data&lt;/p&gt;
&lt;p&gt;### Details
The vulnerability arises because the application accepts the client-supplied cookies named `meye_password_hash` and `meye_username` as sufficient authentication material. The server does not validate these values against a server-side session or enforce proper authentication checks before establishing an authenticated state. As a result, an unauthenticated attacker can set or modify these cookies to impersonate another user if the target username and corresponding hash are known.&lt;/p&gt;
&lt;p&gt;These cookies normally appear after using the &amp;#34;switch user&amp;#34; functionality; however, they can be added manually prior to authentication using standard browser tools (e.g., developer tools or cookie editors) or dynamically loaded by submitting blank credentials. When supplied, the server accepts them and authenticates the attacker as the specified user bypassing the intended authentication flow&lt;/p&gt;
&lt;p&gt;Additionally, the password-hash value and username…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: motioneye&lt;/p&gt;
&lt;p&gt;### Summary
An authentication bypass vulnerability exists due to improper trust in client-controlled cookies. The application accepts user-supplied cookie values containing a username and password-hash-derived value as sufficient authentication material. These cookies can be set or modified prior to login, allowing an unauthenticated attacker to impersonate arbitrary users without knowledge of the plaintext password. This issue stems from the absence of server-side validation of authentication state and reliance on attacker-controlled cookie data&lt;/p&gt;
&lt;p&gt;### Details
The vulnerability arises because the application accepts the client-supplied cookies named `meye_password_hash` and `meye_username` as sufficient authentication material. The server does not validate these values against a server-side session or enforce proper authentication checks before establishing an authenticated state. As a result, an unauthenticated attacker can set or modify these cookies to impersonate another user if the target username and corresponding hash are known.&lt;/p&gt;
&lt;p&gt;These cookies normally appear after using the &amp;#34;switch user&amp;#34; functionality; however, they can be added manually prior to authentication using standard browser tools (e.g., developer tools or cookie editors) or dynamically loaded by submitting blank credentials. When supplied, the server accepts them and authenticates the attacker as the specified user bypassing the intended authentication flow&lt;/p&gt;
&lt;p&gt;Additionally, the password-hash value and username…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-r3cw-c95m-wfh9</guid>
    </item>
  </channel>
</rss>
