<?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 03:16:27 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-318564</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-318564</link>
      <description>EUVD-2026-318564</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-318564</guid>
    </item>
    <item>
      <title>fkie_cve-2026-41893</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-41893</link>
      <description>&lt;p&gt;Signal K Server is a server application that runs on a central hub in a boat. Prior to version 2.25.0, the HTTP login endpoints (POST /login and POST /signalk/v1/auth/login) are protected by express-rate-limit (default: 100 attempts per 10-minute window, configurable via HTTP_RATE_LIMITS). The WebSocket login path — sending {login: {username, password}} messages over an established WebSocket connection — calls app.securityStrategy.login() directly without any rate limiting. An attacker can bypass HTTP rate limiting entirely by opening a WebSocket connection and attempting unlimited password guesses at the speed bcrypt allows (~20 attempts/sec with 10 salt rounds). This issue has been patched in version 2.25.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Signal K Server is a server application that runs on a central hub in a boat. Prior to version 2.25.0, the HTTP login endpoints (POST /login and POST /signalk/v1/auth/login) are protected by express-rate-limit (default: 100 attempts per 10-minute window, configurable via HTTP_RATE_LIMITS). The WebSocket login path — sending {login: {username, password}} messages over an established WebSocket connection — calls app.securityStrategy.login() directly without any rate limiting. An attacker can bypass HTTP rate limiting entirely by opening a WebSocket connection and attempting unlimited password guesses at the speed bcrypt allows (~20 attempts/sec with 10 salt rounds). This issue has been patched in version 2.25.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-41893</guid>
    </item>
    <item>
      <title>GHSA-vmfm-ch9h-5c7g — Signal K Server's WebSocket Login Endpoint Lacks Rate Limiting (Credential Brute-Force)</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-vmfm-ch9h-5c7g</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: signalk-server&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The HTTP login endpoints (`POST /login` and `POST /signalk/v1/auth/login`) are protected by `express-rate-limit` (default: 100 attempts per 10-minute window, configurable via `HTTP_RATE_LIMITS`). The WebSocket login path — sending `{login: {username, password}}` messages over an established WebSocket connection — calls `app.securityStrategy.login()` directly without any rate limiting.&lt;/p&gt;
&lt;p&gt;An attacker can bypass HTTP rate limiting entirely by opening a WebSocket connection and attempting unlimited password guesses at the speed bcrypt allows (~20 attempts/sec with 10 salt rounds).&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;**Vulnerable code:** `src/interfaces/ws.ts`, function `processLoginRequest` (lines 753-780)&lt;/p&gt;
&lt;p&gt;The function directly calls `app.securityStrategy.login(msg.login.username, msg.login.password)` with no throttling or attempt tracking.&lt;/p&gt;
&lt;p&gt;**Rate-limited HTTP path for comparison:** `src/tokensecurity.ts` lines 609-617 apply `loginLimiter` middleware to the HTTP login routes at line 637.&lt;/p&gt;
&lt;p&gt;## Steps to Reproduce&lt;/p&gt;
&lt;p&gt;1. Start Signal K server with security enabled
2. Open a WebSocket connection to `ws://server:3000/signalk/v1/stream?subscribe=none`
3. Wait for the hello message
4. Send login attempts in rapid succession:
   ```json
   {&amp;#34;requestId&amp;#34;: &amp;#34;1&amp;#34;, &amp;#34;login&amp;#34;: {&amp;#34;username&amp;#34;: &amp;#34;admin&amp;#34;, &amp;#34;password&amp;#34;: &amp;#34;guess1&amp;#34;}}
   {&amp;#34;requestId&amp;#34;: &amp;#34;2&amp;#34;, &amp;#34;login&amp;#34;: {&amp;#34;username&amp;#34;: &amp;#34;admin&amp;#34;, &amp;#34;password&amp;#34;: &amp;#34;guess2&amp;#34;}}
   ```
5. Observe that all attempts are processed without any 429 response or throttling
6. For comparison, send 100…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: signalk-server&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The HTTP login endpoints (`POST /login` and `POST /signalk/v1/auth/login`) are protected by `express-rate-limit` (default: 100 attempts per 10-minute window, configurable via `HTTP_RATE_LIMITS`). The WebSocket login path — sending `{login: {username, password}}` messages over an established WebSocket connection — calls `app.securityStrategy.login()` directly without any rate limiting.&lt;/p&gt;
&lt;p&gt;An attacker can bypass HTTP rate limiting entirely by opening a WebSocket connection and attempting unlimited password guesses at the speed bcrypt allows (~20 attempts/sec with 10 salt rounds).&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;**Vulnerable code:** `src/interfaces/ws.ts`, function `processLoginRequest` (lines 753-780)&lt;/p&gt;
&lt;p&gt;The function directly calls `app.securityStrategy.login(msg.login.username, msg.login.password)` with no throttling or attempt tracking.&lt;/p&gt;
&lt;p&gt;**Rate-limited HTTP path for comparison:** `src/tokensecurity.ts` lines 609-617 apply `loginLimiter` middleware to the HTTP login routes at line 637.&lt;/p&gt;
&lt;p&gt;## Steps to Reproduce&lt;/p&gt;
&lt;p&gt;1. Start Signal K server with security enabled
2. Open a WebSocket connection to `ws://server:3000/signalk/v1/stream?subscribe=none`
3. Wait for the hello message
4. Send login attempts in rapid succession:
   ```json
   {&amp;#34;requestId&amp;#34;: &amp;#34;1&amp;#34;, &amp;#34;login&amp;#34;: {&amp;#34;username&amp;#34;: &amp;#34;admin&amp;#34;, &amp;#34;password&amp;#34;: &amp;#34;guess1&amp;#34;}}
   {&amp;#34;requestId&amp;#34;: &amp;#34;2&amp;#34;, &amp;#34;login&amp;#34;: {&amp;#34;username&amp;#34;: &amp;#34;admin&amp;#34;, &amp;#34;password&amp;#34;: &amp;#34;guess2&amp;#34;}}
   ```
5. Observe that all attempts are processed without any 429 response or throttling
6. For comparison, send 100…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-vmfm-ch9h-5c7g</guid>
    </item>
  </channel>
</rss>
