Common Weakness Enumeration

CWE-306

Allowed

Missing Authentication for Critical Function

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

3436 vulnerabilities reference this CWE, most recent first.

GHSA-XQ7H-VWJP-5VRH

Vulnerability from github – Published: 2026-03-25 17:30 – Updated: 2026-03-25 17:30
VLAI
Summary
@grackle-ai/powerline Runs Without Authentication by Default
Details

Impact

When --token is not provided and GRACKLE_POWERLINE_TOKEN is not set, the PowerLine gRPC server runs with zero authentication. A warning is logged ("NO AUTH (development only)") but nothing prevents deployment in this state. Any client that can reach the PowerLine port can spawn agent sessions, access credential tokens, and execute code.

The default binding is 127.0.0.1 (loopback only), which limits exposure to the local machine. However, if PowerLine is accidentally exposed on a network (e.g., in a container or via port forwarding), the impact is critical.

Affected code: - packages/powerline/src/index.ts:46 — token defaults to empty string - packages/powerline/src/index.ts:63-76 — auth interceptor is only added when token is truthy

Patches

0.70.1

Fix: Require an explicit --no-auth flag to run without authentication, rather than defaulting to no auth when the token is empty. Throw an error if starting without a token and without --no-auth.

Workarounds

Always provide --token or set GRACKLE_POWERLINE_TOKEN when starting PowerLine. The Grackle server does this automatically when managing PowerLine lifecycle.

Resources

  • CWE-306: Missing Authentication for Critical Function
  • File: packages/powerline/src/index.ts
Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.70.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@grackle-ai/powerline"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.70.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-25T17:30:46Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nWhen `--token` is not provided and `GRACKLE_POWERLINE_TOKEN` is not set, the PowerLine gRPC server runs with **zero authentication**. A warning is logged (`\"NO AUTH (development only)\"`) but nothing prevents deployment in this state. Any client that can reach the PowerLine port can spawn agent sessions, access credential tokens, and execute code.\n\nThe default binding is `127.0.0.1` (loopback only), which limits exposure to the local machine. However, if PowerLine is accidentally exposed on a network (e.g., in a container or via port forwarding), the impact is critical.\n\n**Affected code:**\n- `packages/powerline/src/index.ts:46` \u2014 token defaults to empty string\n- `packages/powerline/src/index.ts:63-76` \u2014 auth interceptor is only added when token is truthy\n\n### Patches\n\n0.70.1\n\n**Fix:** Require an explicit `--no-auth` flag to run without authentication, rather than defaulting to no auth when the token is empty. Throw an error if starting without a token and without `--no-auth`.\n\n### Workarounds\n\nAlways provide `--token` or set `GRACKLE_POWERLINE_TOKEN` when starting PowerLine. The Grackle server does this automatically when managing PowerLine lifecycle.\n\n### Resources\n\n- CWE-306: Missing Authentication for Critical Function\n- File: `packages/powerline/src/index.ts`",
  "id": "GHSA-xq7h-vwjp-5vrh",
  "modified": "2026-03-25T17:30:46Z",
  "published": "2026-03-25T17:30:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nick-pape/grackle/security/advisories/GHSA-xq7h-vwjp-5vrh"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nick-pape/grackle"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@grackle-ai/powerline Runs Without Authentication by Default"
}

GHSA-XQHV-CHQM-FHCC

Vulnerability from github – Published: 2026-07-08 20:27 – Updated: 2026-07-08 20:27
VLAI
Summary
Joro: Unauthenticated Cross-Origin Plugin Upload Leads to RCE
Details

Unauthenticated Cross-Origin Plugin Upload Leads to RCE (Joro ≤ v1.1.0)

Severity: Critical CVSS v3.1: 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) Affected versions: Joro ≤ v1.1.0, proxy mode (default), Linux/macOS Reporter: cstover Date: 2026-05-27

Summary

Joro's default proxy mode (in versions <= 1.1.0) exposes a local API on 127.0.0.1:9090 that performs no authentication and applies a wildcard CORS policy. Because plugin uploads use the CORS-safelisted multipart/form-data content type, cross-origin JavaScript on any page the operator visits can reach privileged endpoints - including uploading a native plugin and triggering a restart - directly through the operator's browser, with no preflight or credentials. Since plugins execute on load, this yields unauthenticated remote code execution as the operator's user from a single page visit.

Root Cause

Three weaknesses combined into the exploit chain.

1. No authentication in proxy mode. internal/api/server.go applied AuthMiddleware only when listenerMode was true. In the default proxy mode every API endpoint — including plugin upload and system restart — accepted requests without any token, cookie, or credential.

2. Permissive CORS with an insufficient protection assumption. corsMiddleware set Access-Control-Allow-Origin: * unconditionally on all responses. SECURITY.md documented this as an intentional tradeoff on the basis that proxy mode binds to 127.0.0.1, which the document states "limits exposure to the local machine."

That assumption was incorrect. multipart/form-data is a CORS-safelisted Content-Type, so cross-origin JavaScript can POST files to the Joro API without triggering a preflight request — the browser allows it. Any web page the operator visited reached the localhost API through their browser without restriction. The localhost bind provided no protection against browser-mediated requests.

3. Plugin init() executed on plugin.Open() before symbol lookup. internal/plugins/loader.go called plugin.Open(), which ran the plugin's init() functions before any symbol lookup occurred. A plugin with no exports still executed its payload the moment Joro restarted.

Attack Chain

  1. The operator visits an attacker-controlled page in Firefox on their machine.
  2. JavaScript on the page fetches pwn.so from the attacker's server (same-origin, no CORS issue).
  3. JavaScript POSTs pwn.so to http://127.0.0.1:9090/api/v1/plugins/upload as multipart/form-data. Joro accepts it — no auth, no preflight.
  4. JavaScript POSTs to http://127.0.0.1:9090/api/v1/system/restart. Joro re-executes.
  5. On restart, plugin.Open("pwn.so") calls init(), which opens a goroutine and dials back to the attacker's listener.
  6. An interactive /bin/bash -i shell is obtained as the operator's user.

The plugin ABI matches without any access to the operator's machine. The same public v1.1.0 release tarball is downloaded and Joro's own --build-plugin feature is used, which reads runtime/debug.BuildInfo from the release binary and forwards every ABI-relevant flag. One .so works against every operator running that release.

Impact

Unauthenticated, remote, browser-mediated code execution as the operator's user. Because the exploit pivots through the operator's browser to the loopback-bound API, the network bind offers no protection, and a single ABI-matched plugin works against every operator running the affected release.

Fix

The chain is broken at multiple layers. Cross-origin browser access to the proxy-mode API is eliminated, the API is restricted to same-origin requests targeting a loopback host, and the UI/API is bound to loopback only.

1. Removed the wildcard CORS header and gated the proxy-mode API behind a same-origin guard

corsMiddleware (which set Access-Control-Allow-Origin: * on every response) was deleted, and proxy mode now wraps the API in originGuard instead. (internal/api/server.go, commit 5c0ca35)

 var handler http.Handler = mux
 if s.listenerMode {
+     // Listener/teamserver: bearer-token auth.
      handler = team.AuthMiddleware(s.teamToken, handler)
+} else {
+     // Proxy mode: restrict the API to same-origin browser requests.
+     handler = originGuard(uiBind, handler)
 }
-handler = corsMiddleware(handler)

-// corsMiddleware adds permissive CORS headers for dev usage.
-func corsMiddleware(next http.Handler) http.Handler {
-     return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
-             w.Header().Set("Access-Control-Allow-Origin", "*")
-             w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
-             w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization, X-Joro-Nickname")
-             if r.Method == http.MethodOptions {
-                     w.WriteHeader(http.StatusNoContent)
-                     return
-             }
-             next.ServeHTTP(w, r)
-     })
-}

2. Same-origin enforcement via Sec-Fetch-Site + Origin/Host

originGuard rejects state-changing requests (and the /ws upgrade) whose Sec-Fetch-Site indicates a cross-origin initiator or whose Origin host does not match the request Host. Non-browser local tooling (no browser headers) is still allowed. (internal/api/originguard.go, commit 5c0ca35)

func isMutating(method string) bool {
      switch method {
      case http.MethodPost, http.MethodPut, http.MethodDelete, http.MethodPatch:
              return true
      default:
              return false
      }
}

func sameOrigin(r *http.Request) bool {
      switch r.Header.Get("Sec-Fetch-Site") {
      case "", "same-origin", "none":
              // Same-origin, a direct navigation, or a non-browser client.
      default: // "cross-site", "same-site"
              return false
      }
      if origin := r.Header.Get("Origin"); origin != "" {
              if origin == "null" {
                      return false // opaque/sandboxed cross-origin context
              }
              u, err := url.Parse(origin)
              if err != nil || !strings.EqualFold(reqHostname(u.Host), reqHostname(r.Host)) {
                      return false
              }
      }
      return true
}

3. Tightened the WebSocket origin check

The WebSocket upgrader previously accepted every origin (CheckOrigin: return true). It now rejects cross-origin handshakes while still permitting non-browser clients. (internal/api/ws.go, commit 5c0ca35)

var upgrader = websocket.Upgrader{
-     CheckOrigin: func(r *http.Request) bool { return true },
+     CheckOrigin: func(r *http.Request) bool {
+             origin := r.Header.Get("Origin")
+             if origin == "" {
+                     return true
+             }
+             if origin == "null" {
+                     return false
+             }
+             u, err := url.Parse(origin)
+             if err != nil {
+                     return false
+             }
+             return strings.EqualFold(reqHostname(u.Host), reqHostname(r.Host))
+     },
 }

4. Bound the proxy-mode UI/API to loopback and removed the wildcard host exception

The same-origin check alone can be defeated by DNS rebinding under a wildcard bind, because a rebound host (e.g. attacker.com) carries consistent Origin/Host/Sec-Fetch-Site headers. Two coordinated changes close this: the proxy-mode UI/API now binds to 127.0.0.1 regardless of --bind (which governs only the proxy port), and hostAllowed no longer has a wildcard exception, so the host must be loopback or the exact bind address. (internal/api/server.go and internal/api/originguard.go, commit 871936f)

+// In proxy mode the UI/API binds to loopback only: --bind governs the proxy
+// port, and remote collaboration is listener/teamserver mode (bearer-token auth).
+uiBind := s.cfg.BindAddr
+if !s.listenerMode {
+     uiBind = "127.0.0.1"
+}
+
 var handler http.Handler = mux
 ...
 s.srv = &http.Server{
-     Addr:              fmt.Sprintf("%s:%d", s.cfg.BindAddr, s.cfg.UIPort),
+     Addr:              fmt.Sprintf("%s:%d", uiBind, s.cfg.UIPort),

 func hostAllowed(reqHost, bindAddr string) bool {
      h := reqHostname(reqHost)
      if h == "" {
              return false
      }
      switch h {
      case "localhost", "127.0.0.1", "::1":
              return true
      }
-     switch bindAddr {
-     case "", "0.0.0.0", "::":
-             return true
-     }
      return strings.EqualFold(h, reqHostname(bindAddr))
 }
Severity
9.6 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/BishopFox/joro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260601151442-5c0ca35db828"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53649"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-352",
      "CWE-434",
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-08T20:27:02Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "# Unauthenticated Cross-Origin Plugin Upload Leads to RCE (Joro \u2264 v1.1.0)\n\n**Severity:** Critical\n**CVSS v3.1:** 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H)\n**Affected versions:** Joro \u2264 v1.1.0, proxy mode (default), Linux/macOS\n**Reporter:** cstover\n**Date:** 2026-05-27\n\n---\n\n## Summary\n\nJoro\u0027s default proxy mode (in versions \u003c= 1.1.0) exposes a local API on `127.0.0.1:9090` that performs no authentication and applies a wildcard CORS policy. Because plugin uploads use the CORS-safelisted `multipart/form-data` content type, cross-origin JavaScript on any page the operator visits can reach privileged endpoints - including uploading a native plugin and triggering a restart - directly through the operator\u0027s browser, with no preflight or credentials. Since plugins execute on load, this yields unauthenticated remote code execution as the operator\u0027s user from a single page visit.\n\n---\n\n## Root Cause\n\nThree weaknesses combined into the exploit chain.\n\n**1. No authentication in proxy mode.**\n`internal/api/server.go` applied `AuthMiddleware` only when `listenerMode` was `true`. In the default proxy mode every API endpoint \u2014 including plugin upload and system restart \u2014 accepted requests without any token, cookie, or credential.\n\n**2. Permissive CORS with an insufficient protection assumption.**\n`corsMiddleware` set `Access-Control-Allow-Origin: *` unconditionally on all responses. `SECURITY.md` documented this as an intentional tradeoff on the basis that proxy mode binds to `127.0.0.1`, which the document states \"limits exposure to the local machine.\"\n\nThat assumption was incorrect. `multipart/form-data` is a CORS-safelisted `Content-Type`, so cross-origin JavaScript can POST files to the Joro API without triggering a preflight request \u2014 the browser allows it. Any web page the operator visited reached the localhost API through their browser without restriction. The localhost bind provided no protection against browser-mediated requests.\n\n**3. Plugin `init()` executed on `plugin.Open()` before symbol lookup.**\n`internal/plugins/loader.go` called `plugin.Open()`, which ran the plugin\u0027s `init()` functions before any symbol lookup occurred. A plugin with no exports still executed its payload the moment Joro restarted.\n\n---\n\n## Attack Chain\n\n1. The operator visits an attacker-controlled page in Firefox on their machine.\n2. JavaScript on the page fetches `pwn.so` from the attacker\u0027s server (same-origin, no CORS issue).\n3. JavaScript POSTs `pwn.so` to `http://127.0.0.1:9090/api/v1/plugins/upload` as `multipart/form-data`. Joro accepts it \u2014 no auth, no preflight.\n4. JavaScript POSTs to `http://127.0.0.1:9090/api/v1/system/restart`. Joro re-executes.\n5. On restart, `plugin.Open(\"pwn.so\")` calls `init()`, which opens a goroutine and dials back to the attacker\u0027s listener.\n6. An interactive `/bin/bash -i` shell is obtained as the operator\u0027s user.\n\nThe plugin ABI matches without any access to the operator\u0027s machine. The same public v1.1.0 release tarball is downloaded and Joro\u0027s own `--build-plugin` feature is used, which reads `runtime/debug.BuildInfo` from the release binary and forwards every ABI-relevant flag. One `.so` works against every operator running that release.\n\n---\n\n## Impact\n\nUnauthenticated, remote, browser-mediated code execution as the operator\u0027s user. Because the exploit pivots through the operator\u0027s browser to the loopback-bound API, the network bind offers no protection, and a single ABI-matched plugin works against every operator running the affected release.\n\n## Fix\n\nThe chain is broken at multiple layers. Cross-origin browser access to the proxy-mode API is eliminated, the API is restricted to same-origin requests targeting a loopback host, and the UI/API is bound to loopback only.\n\n### 1. Removed the wildcard CORS header and gated the proxy-mode API behind a same-origin guard\n\n`corsMiddleware` (which set `Access-Control-Allow-Origin: *` on every response) was deleted, and proxy mode now wraps the API in `originGuard` instead. (`internal/api/server.go`, commit `5c0ca35`)\n\n```diff\n var handler http.Handler = mux\n if s.listenerMode {\n+     // Listener/teamserver: bearer-token auth.\n      handler = team.AuthMiddleware(s.teamToken, handler)\n+} else {\n+     // Proxy mode: restrict the API to same-origin browser requests.\n+     handler = originGuard(uiBind, handler)\n }\n-handler = corsMiddleware(handler)\n```\n\n```diff\n-// corsMiddleware adds permissive CORS headers for dev usage.\n-func corsMiddleware(next http.Handler) http.Handler {\n-     return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n-             w.Header().Set(\"Access-Control-Allow-Origin\", \"*\")\n-             w.Header().Set(\"Access-Control-Allow-Methods\", \"GET, POST, PUT, DELETE, OPTIONS\")\n-             w.Header().Set(\"Access-Control-Allow-Headers\", \"Content-Type, Authorization, X-Joro-Nickname\")\n-             if r.Method == http.MethodOptions {\n-                     w.WriteHeader(http.StatusNoContent)\n-                     return\n-             }\n-             next.ServeHTTP(w, r)\n-     })\n-}\n```\n\n### 2. Same-origin enforcement via `Sec-Fetch-Site` + `Origin`/`Host`\n\n`originGuard` rejects state-changing requests (and the `/ws` upgrade) whose `Sec-Fetch-Site` indicates a cross-origin initiator or whose `Origin` host does not match the request `Host`. Non-browser local tooling (no browser headers) is still allowed. (`internal/api/originguard.go`, commit `5c0ca35`)\n\n```go\nfunc isMutating(method string) bool {\n      switch method {\n      case http.MethodPost, http.MethodPut, http.MethodDelete, http.MethodPatch:\n              return true\n      default:\n              return false\n      }\n}\n\nfunc sameOrigin(r *http.Request) bool {\n      switch r.Header.Get(\"Sec-Fetch-Site\") {\n      case \"\", \"same-origin\", \"none\":\n              // Same-origin, a direct navigation, or a non-browser client.\n      default: // \"cross-site\", \"same-site\"\n              return false\n      }\n      if origin := r.Header.Get(\"Origin\"); origin != \"\" {\n              if origin == \"null\" {\n                      return false // opaque/sandboxed cross-origin context\n              }\n              u, err := url.Parse(origin)\n              if err != nil || !strings.EqualFold(reqHostname(u.Host), reqHostname(r.Host)) {\n                      return false\n              }\n      }\n      return true\n}\n```\n\n### 3. Tightened the WebSocket origin check\n\nThe WebSocket upgrader previously accepted every origin (`CheckOrigin: return true`). It now rejects cross-origin handshakes while still permitting non-browser clients. (`internal/api/ws.go`, commit `5c0ca35`)\n\n```diff\nvar upgrader = websocket.Upgrader{\n-     CheckOrigin: func(r *http.Request) bool { return true },\n+     CheckOrigin: func(r *http.Request) bool {\n+             origin := r.Header.Get(\"Origin\")\n+             if origin == \"\" {\n+                     return true\n+             }\n+             if origin == \"null\" {\n+                     return false\n+             }\n+             u, err := url.Parse(origin)\n+             if err != nil {\n+                     return false\n+             }\n+             return strings.EqualFold(reqHostname(u.Host), reqHostname(r.Host))\n+     },\n }\n```\n\n### 4. Bound the proxy-mode UI/API to loopback and removed the wildcard host exception\n\nThe same-origin check alone can be defeated by DNS rebinding under a wildcard bind, because a rebound host (e.g. `attacker.com`) carries consistent `Origin`/`Host`/`Sec-Fetch-Site` headers. Two coordinated changes close this: the proxy-mode UI/API now binds to `127.0.0.1` regardless of `--bind` (which governs only the proxy port), and `hostAllowed` no longer has a wildcard exception, so the host must be loopback or the exact bind address. (`internal/api/server.go` and `internal/api/originguard.go`, commit `871936f`)\n\n```diff\n+// In proxy mode the UI/API binds to loopback only: --bind governs the proxy\n+// port, and remote collaboration is listener/teamserver mode (bearer-token auth).\n+uiBind := s.cfg.BindAddr\n+if !s.listenerMode {\n+     uiBind = \"127.0.0.1\"\n+}\n+\n var handler http.Handler = mux\n ...\n s.srv = \u0026http.Server{\n-     Addr:              fmt.Sprintf(\"%s:%d\", s.cfg.BindAddr, s.cfg.UIPort),\n+     Addr:              fmt.Sprintf(\"%s:%d\", uiBind, s.cfg.UIPort),\n```\n\n```diff\n func hostAllowed(reqHost, bindAddr string) bool {\n      h := reqHostname(reqHost)\n      if h == \"\" {\n              return false\n      }\n      switch h {\n      case \"localhost\", \"127.0.0.1\", \"::1\":\n              return true\n      }\n-     switch bindAddr {\n-     case \"\", \"0.0.0.0\", \"::\":\n-             return true\n-     }\n      return strings.EqualFold(h, reqHostname(bindAddr))\n }\n```",
  "id": "GHSA-xqhv-chqm-fhcc",
  "modified": "2026-07-08T20:27:02Z",
  "published": "2026-07-08T20:27:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BishopFox/joro/security/advisories/GHSA-xqhv-chqm-fhcc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BishopFox/joro"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Joro: Unauthenticated Cross-Origin Plugin Upload Leads to RCE"
}

GHSA-XQPC-XQHC-3CRX

Vulnerability from github – Published: 2026-06-19 15:33 – Updated: 2026-06-19 15:33
VLAI
Details

In JetBrains Hub before 2026.1.13757, 2025.3.148033, 2025.2.148048, 2025.1.148120, 2024.3.148430, 2024.2.148429 authentication bypass via direct database access leading to administrative access was possible

Severity
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-50242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-19T13:16:36Z",
    "severity": "CRITICAL"
  },
  "details": "In JetBrains Hub before 2026.1.13757,\n2025.3.148033,\n2025.2.148048,\n2025.1.148120,\n2024.3.148430,\n2024.2.148429 authentication bypass via direct database access leading to administrative access was possible",
  "id": "GHSA-xqpc-xqhc-3crx",
  "modified": "2026-06-19T15:33:15Z",
  "published": "2026-06-19T15:33:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50242"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XRC8-4CQR-4X7C

Vulnerability from github – Published: 2022-05-17 02:40 – Updated: 2022-05-17 02:40
VLAI
Details

Sony PCS-XG100, PCS-XG100S, PCS-XG100C, PCS-XG77, PCS-XG77S, PCS-XG77C devices with firmware versions prior to Ver.1.51 and PCS-XC1 devices with firmware version prior to Ver.1.22 allow an attacker on the same network segment to bypass authentication to perform administrative operations via unspecified vectors.

Severity
8.8 (High)
CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2016-7830"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-09T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "Sony PCS-XG100, PCS-XG100S, PCS-XG100C, PCS-XG77, PCS-XG77S, PCS-XG77C devices with firmware versions prior to Ver.1.51 and PCS-XC1 devices with firmware version prior to Ver.1.22 allow an attacker on the same network segment to bypass authentication to perform administrative operations via unspecified vectors.",
  "id": "GHSA-xrc8-4cqr-4x7c",
  "modified": "2022-05-17T02:40:33Z",
  "published": "2022-05-17T02:40:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-7830"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN42070907/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.sony.co.uk/pro/support/attachment/1237494431832/1237494431864/videoconferencesecurityenhancement-v3.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XRFJ-6M49-WFMM

Vulnerability from github – Published: 2026-06-24 15:31 – Updated: 2026-06-24 15:31
VLAI
Details

Crawl4AI before 0.8.7 contains an authentication bypass vulnerability in the monitor router endpoints that allows unauthenticated attackers to access destructive operations. Remote attackers can invoke the /monitor/actions/cleanup endpoint and manipulate monitoring state without authentication, causing service disruption.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-56262"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-24T13:16:35Z",
    "severity": "MODERATE"
  },
  "details": "Crawl4AI before 0.8.7 contains an authentication bypass vulnerability in the monitor router endpoints that allows unauthenticated attackers to access destructive operations. Remote attackers can invoke the /monitor/actions/cleanup endpoint and manipulate monitoring state without authentication, causing service disruption.",
  "id": "GHSA-xrfj-6m49-wfmm",
  "modified": "2026-06-24T15:31:46Z",
  "published": "2026-06-24T15:31:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/unclecode/crawl4ai/security/advisories/GHSA-365w-hqf6-vxfg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56262"
    },
    {
      "type": "WEB",
      "url": "https://github.com/unclecode/crawl4ai"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/crawl4ai-unauthenticated-access-to-monitor-endpoints-via-docker-api-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-XRJ9-73XW-FR4F

Vulnerability from github – Published: 2026-03-06 00:31 – Updated: 2026-03-06 00:31
VLAI
Details

Payment Orchestrator Service Elevation of Privilege Vulnerability

Severity
8.6 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-26125"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-05T23:16:20Z",
    "severity": "HIGH"
  },
  "details": "Payment Orchestrator Service Elevation of Privilege Vulnerability",
  "id": "GHSA-xrj9-73xw-fr4f",
  "modified": "2026-03-06T00:31:35Z",
  "published": "2026-03-06T00:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26125"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-26125"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XRR5-FHQ2-5W4H

Vulnerability from github – Published: 2026-06-12 18:31 – Updated: 2026-06-12 18:31
VLAI
Details

The Aqara Board service (op-test.aqara.com) accepts arbitrary MQTT command payloads, and forwards them to the platfom's HiveMQ broker without authentication. This is an instance of "CWE-306: Missing Authentication for Critical Function" and has an estimated CVSS ofCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L (8.6 High). When combined with CVE-2026-50082, CVE-50083, and CVE-50084, this can lead to a fully unauthenticated, remote takeover of affected devices.

Severity
8.6 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-50085"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-12T16:16:32Z",
    "severity": "HIGH"
  },
  "details": "The Aqara Board service (op-test.aqara.com) accepts arbitrary MQTT command payloads, and forwards them to the platfom\u0027s HiveMQ broker without authentication. This is an instance of \"CWE-306: Missing Authentication for Critical Function\" and has an estimated CVSS ofCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L (8.6 High). When combined with CVE-2026-50082, CVE-50083, and CVE-50084, this can lead to a fully unauthenticated, remote takeover of affected devices.",
  "id": "GHSA-xrr5-fhq2-5w4h",
  "modified": "2026-06-12T18:31:58Z",
  "published": "2026-06-12T18:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50085"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xn0tsa/theres-no-place-like-home"
    },
    {
      "type": "WEB",
      "url": "https://www.runzero.com/advisories/aqara-board-iot-insecure-debug-api-cve-2026-50085"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XV45-RRWP-WGF4

Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36
VLAI
Details

The official rabbitmq docker images before 3.7.13-beta.1-management-alpine (Alpine specific) contain a blank password for a root user. System using the rabbitmq docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-35196"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-17T02:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The official rabbitmq docker images before 3.7.13-beta.1-management-alpine (Alpine specific) contain a blank password for a root user. System using the rabbitmq docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.",
  "id": "GHSA-xv45-rrwp-wgf4",
  "modified": "2022-05-24T17:36:46Z",
  "published": "2022-05-24T17:36:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35196"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koharin/koharin2/blob/main/CVE-2020-35196"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XV5H-V7JH-P2QH

Vulnerability from github – Published: 2021-04-27 20:09 – Updated: 2021-05-10 15:11
VLAI
Summary
Authentication bypass for specific endpoint
Details

The ConfigOpsController lets the user perform management operations like querying the database or even wiping it out. While the /data/remove endpoint is properly protected with the @Secured annotation, the /derby endpoint is not protected and can be openly accessed by unauthenticated users.

For example, the following request will list the tables of the database:

❯ curl -X GET 'http://console.nacos.io/nacos/v1/cs/ops/derby?sql=select+st.tablename+from+sys.systables+st'
{"code":200,"message":null,"data":[{"TABLENAME":"APP_CONFIGDATA_RELATION_PUBS"},{"TABLENAME":"APP_CONFIGDATA_RELATION_SUBS"},{"TABLENAME":"APP_LIST"},{"TABLENAME":"CONFIG_INFO"},{"TABLENAME":"CONFIG_INFO_AGGR"},{"TABLENAME":"CONFIG_INFO_BETA"},{"TABLENAME":"CONFIG_INFO_TAG"},{"TABLENAME":"CONFIG_TAGS_RELATION"},{"TABLENAME":"GROUP_CAPACITY"},{"TABLENAME":"HIS_CONFIG_INFO"},{"TABLENAME":"PERMISSIONS"},{"TABLENAME":"ROLES"},{"TABLENAME":"SYSALIASES"},{"TABLENAME":"SYSCHECKS"},{"TABLENAME":"SYSCOLPERMS"},{"TABLENAME":"SYSCOLUMNS"},{"TABLENAME":"SYSCONGLOMERATES"},{"TABLENAME":"SYSCONSTRAINTS"},{"TABLENAME":"SYSDEPENDS"},{"TABLENAME":"SYSDUMMY1"},{"TABLENAME":"SYSFILES"},{"TABLENAME":"SYSFOREIGNKEYS"},{"TABLENAME":"SYSKEYS"},{"TABLENAME":"SYSPERMS"},{"TABLENAME":"SYSROLES"},{"TABLENAME":"SYSROUTINEPERMS"},{"TABLENAME":"SYSSCHEMAS"},{"TABLENAME":"SYSSEQUENCES"},{"TABLENAME":"SYSSTATEMENTS"},{"TABLENAME":"SYSSTATISTICS"},{"TABLENAME":"SYSTABLEPERMS"},{"TABLENAME":"SYSTABLES"},{"TABLENAME":"SYSTRIGGERS"},{"TABLENAME":"SYSUSERS"},{"TABLENAME":"SYSVIEWS"},{"TABLENAME":"TENANT_CAPACITY"},{"TABLENAME":"TENANT_INFO"},{"TABLENAME":"USERS"}]}%

These endpoints are only valid when using embedded storage (derby DB) so this issue should not affect those installations using external storage (e.g. mysql)

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.alibaba.nacos:nacos-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-29442"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-27T20:08:49Z",
    "nvd_published_at": "2021-04-27T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "The [`ConfigOpsController`](https://github.com/alibaba/nacos/blob/57459227863485d064ff25b3d5e24e714dcf218f/config/src/main/java/com/alibaba/nacos/config/server/controller/ConfigOpsController.java) lets the user perform management operations like querying the database or even wiping it out. While the [`/data/remove`](https://github.com/alibaba/nacos/blob/57459227863485d064ff25b3d5e24e714dcf218f/config/src/main/java/com/alibaba/nacos/config/server/controller/ConfigOpsController.java#L133-L135) endpoint is properly protected with the `@Secured` annotation, the [`/derby`](https://github.com/alibaba/nacos/blob/57459227863485d064ff25b3d5e24e714dcf218f/config/src/main/java/com/alibaba/nacos/config/server/controller/ConfigOpsController.java#L99-L100) endpoint is not protected and can be openly accessed by unauthenticated users. \n\nFor example, the following request will list the tables of the database:\n```\n\u276f curl -X GET \u0027http://console.nacos.io/nacos/v1/cs/ops/derby?sql=select+st.tablename+from+sys.systables+st\u0027\n{\"code\":200,\"message\":null,\"data\":[{\"TABLENAME\":\"APP_CONFIGDATA_RELATION_PUBS\"},{\"TABLENAME\":\"APP_CONFIGDATA_RELATION_SUBS\"},{\"TABLENAME\":\"APP_LIST\"},{\"TABLENAME\":\"CONFIG_INFO\"},{\"TABLENAME\":\"CONFIG_INFO_AGGR\"},{\"TABLENAME\":\"CONFIG_INFO_BETA\"},{\"TABLENAME\":\"CONFIG_INFO_TAG\"},{\"TABLENAME\":\"CONFIG_TAGS_RELATION\"},{\"TABLENAME\":\"GROUP_CAPACITY\"},{\"TABLENAME\":\"HIS_CONFIG_INFO\"},{\"TABLENAME\":\"PERMISSIONS\"},{\"TABLENAME\":\"ROLES\"},{\"TABLENAME\":\"SYSALIASES\"},{\"TABLENAME\":\"SYSCHECKS\"},{\"TABLENAME\":\"SYSCOLPERMS\"},{\"TABLENAME\":\"SYSCOLUMNS\"},{\"TABLENAME\":\"SYSCONGLOMERATES\"},{\"TABLENAME\":\"SYSCONSTRAINTS\"},{\"TABLENAME\":\"SYSDEPENDS\"},{\"TABLENAME\":\"SYSDUMMY1\"},{\"TABLENAME\":\"SYSFILES\"},{\"TABLENAME\":\"SYSFOREIGNKEYS\"},{\"TABLENAME\":\"SYSKEYS\"},{\"TABLENAME\":\"SYSPERMS\"},{\"TABLENAME\":\"SYSROLES\"},{\"TABLENAME\":\"SYSROUTINEPERMS\"},{\"TABLENAME\":\"SYSSCHEMAS\"},{\"TABLENAME\":\"SYSSEQUENCES\"},{\"TABLENAME\":\"SYSSTATEMENTS\"},{\"TABLENAME\":\"SYSSTATISTICS\"},{\"TABLENAME\":\"SYSTABLEPERMS\"},{\"TABLENAME\":\"SYSTABLES\"},{\"TABLENAME\":\"SYSTRIGGERS\"},{\"TABLENAME\":\"SYSUSERS\"},{\"TABLENAME\":\"SYSVIEWS\"},{\"TABLENAME\":\"TENANT_CAPACITY\"},{\"TABLENAME\":\"TENANT_INFO\"},{\"TABLENAME\":\"USERS\"}]}% \n```\n\nThese endpoints are only valid when using embedded storage (derby DB) so this issue should not affect those installations using external storage (e.g. mysql)",
  "id": "GHSA-xv5h-v7jh-p2qh",
  "modified": "2021-05-10T15:11:26Z",
  "published": "2021-04-27T20:09:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29442"
    },
    {
      "type": "WEB",
      "url": "https://github.com/alibaba/nacos/issues/4463"
    },
    {
      "type": "WEB",
      "url": "https://github.com/alibaba/nacos/pull/4517"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-36hp-jr8h-556f"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Authentication bypass for specific endpoint"
}

GHSA-XV6G-6G23-79W2

Vulnerability from github – Published: 2023-03-29 21:30 – Updated: 2023-04-06 15:30
VLAI
Details

This vulnerability allows remote attackers to bypass authentication on affected installations of Ivanti Avalanche 6.3.3.101. Authentication is not required to exploit this vulnerability. The specific flaw exists within the SetSettings class. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-15919.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-36983"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-749"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-29T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "This vulnerability allows remote attackers to bypass authentication on affected installations of Ivanti Avalanche 6.3.3.101. Authentication is not required to exploit this vulnerability. The specific flaw exists within the SetSettings class. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-15919.",
  "id": "GHSA-xv6g-6g23-79w2",
  "modified": "2023-04-06T15:30:18Z",
  "published": "2023-03-29T21:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36983"
    },
    {
      "type": "WEB",
      "url": "https://download.wavelink.com/Files/avalanche_v6.3.4_release_notes.txt"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-22-788"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design
  • Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
  • Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
  • In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation
Architecture and Design
  • Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
  • In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
Implementation System Configuration Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].

CAPEC-12: Choosing Message Identifier

This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.

CAPEC-166: Force the System to Reset Values

An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.

CAPEC-216: Communication Channel Manipulation

An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-62: Cross Site Request Forgery

An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.

← Back to the CWE list