<?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://db.gcve.eu</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, 01 Oct 2026 20:44:21 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-58272</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-58272</link>
      <description>&lt;p&gt;Sync-in Server is an open-source platform for file storage, sharing, collaboration, and syncing. Versions prior to 2.4.1 contain an observable timing discrepancy in the login endpoint because authentication attempts for nonexistent accounts return without performing the bcrypt comparison used for existing accounts. An unauthenticated attacker can measure response times to enumerate valid usernames or email addresses, facilitating credential-stuffing, password-spraying, and phishing attacks. Version 2.4.1 contains a patch.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Sync-in Server is an open-source platform for file storage, sharing, collaboration, and syncing. Versions prior to 2.4.1 contain an observable timing discrepancy in the login endpoint because authentication attempts for nonexistent accounts return without performing the bcrypt comparison used for existing accounts. An unauthenticated attacker can measure response times to enumerate valid usernames or email addresses, facilitating credential-stuffing, password-spraying, and phishing attacks. Version 2.4.1 contains a patch.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-58272</guid>
    </item>
    <item>
      <title>GHSA-29hq-23m2-2j47 — Sync-in Server has Username/Login Enumeration via Timing Side-Channel on POST /api/auth/login (incomplete fix of the pr…</title>
      <link>https://db.gcve.eu/vuln/ghsa-29hq-23m2-2j47</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @sync-in/server&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;validateUser() in backend/src/authentication/providers/mysql/auth-provider-mysql.service.ts returns immediately when the supplied login/email does not match any account, without ever calling comparePassword():&lt;/p&gt;
&lt;p&gt;async validateUser(loginOrEmail: string, password: string, ip?: string, scope?: AUTH_SCOPE): Promise&amp;lt;UserModel&amp;gt; {
      let user: UserModel
      try {
        user = await this.usersManager.findUser(loginOrEmail, false)
      } catch (e) { ... }
      if (!user) {
        this.logger.warn(...)
        return null   // &amp;lt;-- comparePassword() is never reached here
      }
      return await this.usersManager.logUser(user, password, ip, scope)
    }&lt;/p&gt;
&lt;p&gt;comparePassword() (backend/src/common/functions.ts) already contains a dummy-hash branch that was clearly added to defend against exactly this class of attack:&lt;/p&gt;
&lt;p&gt;export async function comparePassword(password: string, hash?: string | null): Promise&amp;lt;boolean&amp;gt; {
      if (!hash) {
        // No hash, waste time for time-based attacks
        await bcrypt.compare(password, DUMMY_PASSWORD_HASH)
        return false
      }
      return await bcrypt.compare(password, hash)
    }&lt;/p&gt;
&lt;p&gt;The problem is that this protection only runs when comparePassword() is actually invoked with a falsy hash. Because validateUser() short-circuits with return null as soon as findUser() comes back empty, the &amp;#34;account doesn&amp;#39;t exist&amp;#34; path skips all cryptographic work entirely, while the &amp;#34;account exists, wrong password&amp;#34; path always performs…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @sync-in/server&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;validateUser() in backend/src/authentication/providers/mysql/auth-provider-mysql.service.ts returns immediately when the supplied login/email does not match any account, without ever calling comparePassword():&lt;/p&gt;
&lt;p&gt;async validateUser(loginOrEmail: string, password: string, ip?: string, scope?: AUTH_SCOPE): Promise&amp;lt;UserModel&amp;gt; {
      let user: UserModel
      try {
        user = await this.usersManager.findUser(loginOrEmail, false)
      } catch (e) { ... }
      if (!user) {
        this.logger.warn(...)
        return null   // &amp;lt;-- comparePassword() is never reached here
      }
      return await this.usersManager.logUser(user, password, ip, scope)
    }&lt;/p&gt;
&lt;p&gt;comparePassword() (backend/src/common/functions.ts) already contains a dummy-hash branch that was clearly added to defend against exactly this class of attack:&lt;/p&gt;
&lt;p&gt;export async function comparePassword(password: string, hash?: string | null): Promise&amp;lt;boolean&amp;gt; {
      if (!hash) {
        // No hash, waste time for time-based attacks
        await bcrypt.compare(password, DUMMY_PASSWORD_HASH)
        return false
      }
      return await bcrypt.compare(password, hash)
    }&lt;/p&gt;
&lt;p&gt;The problem is that this protection only runs when comparePassword() is actually invoked with a falsy hash. Because validateUser() short-circuits with return null as soon as findUser() comes back empty, the &amp;#34;account doesn&amp;#39;t exist&amp;#34; path skips all cryptographic work entirely, while the &amp;#34;account exists, wrong password&amp;#34; path always performs…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-29hq-23m2-2j47</guid>
    </item>
  </channel>
</rss>
