Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

6890 vulnerabilities reference this CWE, most recent first.

GHSA-9G39-JGF9-9MXX

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

A remote authenticated authorization-bypass vulnerability in Wowza Streaming Engine 4.7.8 (build 20191105123929) allows any read-only user to issue requests to the administration panel in order to change functionality. For example, a read-only user may activate the Java JMX port in unauthenticated mode and execute OS commands under root privileges.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-9004"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-14T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "A remote authenticated authorization-bypass vulnerability in Wowza Streaming Engine 4.7.8 (build 20191105123929) allows any read-only user to issue requests to the administration panel in order to change functionality. For example, a read-only user may activate the Java JMX port in unauthenticated mode and execute OS commands under root privileges.",
  "id": "GHSA-9g39-jgf9-9mxx",
  "modified": "2022-05-24T17:14:18Z",
  "published": "2022-05-24T17:14:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9004"
    },
    {
      "type": "WEB",
      "url": "https://github.com/DrunkenShells/Disclosures/tree/master/CVE-2020-9004-Authenticated%20Remote%20Authorization%20Bypass%20Leading%20to%20RCE-Wowza"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/WowzaMediaSystems/public_cve/main/wowza-streaming-engine/CVE-2020-9004.txt"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/WowzaMediaSystems/public_cve/master/wowza-streaming-engine/CVE-2020-9004.txt"
    },
    {
      "type": "WEB",
      "url": "https://www.wowza.com/docs/wowza-streaming-engine-4-8-5-release-notes"
    }
  ],
  "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-9G52-R87C-973Q

Vulnerability from github – Published: 2024-12-04 03:31 – Updated: 2024-12-04 03:31
VLAI
Details

A vulnerability in Veeam Backup & Replication allows a low-privileged user to start an agent remotely in server mode and obtain credentials, effectively escalating privileges to system-level access. This allows the attacker to upload files to the server with elevated privileges. The vulnerability exists because remote calls bypass permission checks, leading to full system compromise.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-42452"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-04T02:15:04Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in Veeam Backup \u0026 Replication allows a low-privileged user to start an agent remotely in server mode and obtain credentials, effectively escalating privileges to system-level access. This allows the attacker to upload files to the server with elevated privileges. The vulnerability exists because remote calls bypass permission checks, leading to full system compromise.",
  "id": "GHSA-9g52-r87c-973q",
  "modified": "2024-12-04T03:31:15Z",
  "published": "2024-12-04T03:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42452"
    },
    {
      "type": "WEB",
      "url": "https://www.veeam.com/kb4693"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9G7M-MW8W-MQC5

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

OMERO.server before 5.6.1 allows attackers to bypass the security filters and access hidden objects via a crafted query.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-16244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-22T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "OMERO.server before 5.6.1 allows attackers to bypass the security filters and access hidden objects via a crafted query.",
  "id": "GHSA-9g7m-mw8w-mqc5",
  "modified": "2022-05-24T17:24:01Z",
  "published": "2022-05-24T17:24:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16244"
    },
    {
      "type": "WEB",
      "url": "https://www.openmicroscopy.org/security/advisories/2019-SV5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9GF3-6WPF-HGPX

Vulnerability from github – Published: 2023-02-14 21:30 – Updated: 2025-10-22 00:32
VLAI
Details

Microsoft Publisher Security Features Bypass Vulnerability

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-21715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-14T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Microsoft Publisher Security Features Bypass Vulnerability",
  "id": "GHSA-9gf3-6wpf-hgpx",
  "modified": "2025-10-22T00:32:41Z",
  "published": "2023-02-14T21:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21715"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21715"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-21715"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9GFJ-28HW-JCHP

Vulnerability from github – Published: 2026-09-25 19:32 – Updated: 2026-09-25 19:32
VLAI
Summary
Knowns Unrestricted Path Traversal leading to out-of-bounds arbitrary .md file read, write, and deletion in MCP Docs + Memory Tools
Details

Overview

Verified. Multiple Unrestricted Path Traversal vulnerabilities exist in the Knowns MCP docs and memory tools, allowing arbitrary file read, write, and deletion operations outside the project sandbox. The storage layer functions (Get, Create, Update, Rename, Delete) in both doc_store.go and memory_store.go concatenate user-controlled paths with filepath.Join() without any containment validation.

Additionally, the docs.update action with a newPath parameter performs a file deletion via Rename(), but is classified as CapWrite in the permission registry rather than CapDelete. This allows an attacker with a read-write-no-delete preset to bypass deletion restrictions and destroy arbitrary files outside the project root.

Affected paths

File Path Role Vulnerability & Execution Impact
internal/storage/doc_store.go Vulnerable Sink (Docs) Path Traversal in File Operations (CWE-22): Get(), Create(), Update(), Rename(), Delete() join user-controlled path with filepath.Join(ds.docsDir(), ...) without validating path containment.
internal/storage/memory_store.go Vulnerable Sink (Memory) Path Traversal in Memory Operations (CWE-22): GetInLayer(), Create(), Update(), Delete() join user-controlled id with filepath.Join(dir, models.MemoryFileName(id)) without validation.
internal/mcp/handlers/doc.go Pass-Through Handler Unsanitized Input Propagation: MCP handlers pass user-supplied path, folder, newPath directly to storage layer without sanitization.
internal/mcp/handlers/memory.go Pass-Through Handler Unsanitized Input Propagation: MCP handlers pass user-supplied id directly to storage layer without sanitization.
internal/permissions/registry.go Authorization Bypass Capability Misclassification (CWE-863): docs.update with newPath performs file deletion but is classified as CapWrite, bypassing CapDelete restrictions.

Root Cause

Missing Path Containment in DocStore

In internal/storage/doc_store.go, all file operations use filepath.Join() to construct absolute paths without validating that the resolved path remains within docsDir():

// Get retrieves a doc by its relative path (without .md extension).
func (ds *DocStore) Get(path string) (*models.Doc, error) {
    path = strings.TrimPrefix(path, "/")
    path = strings.TrimSuffix(path, ".md")

    // VULNERABLE: No containment check
    absPath := filepath.Join(ds.docsDir(), filepath.FromSlash(path)+".md")
    if _, err := os.Stat(absPath); err == nil {
        // ...
        return ds.parseFile(absPath, path, folder, false, "")
    }
    // ...
}

// Create writes a new doc to .knowns/docs/{path}.md.
func (ds *DocStore) Create(doc *models.Doc) error {
    if doc.Path == "" {
        return fmt.Errorf("doc path is required")
    }
    // VULNERABLE: No containment check
    absPath := filepath.Join(ds.docsDir(), filepath.FromSlash(doc.Path)+".md")
    if err := os.MkdirAll(filepath.Dir(absPath), 0755); err != nil {
        return fmt.Errorf("create doc dir: %w", err)
    }
    return ds.writeFile(absPath, doc)
}

// Rename rewrites a doc to a new path and removes the old file.
func (ds *DocStore) Rename(oldPath string, doc *models.Doc) error {
    // ...
    oldAbsPath := filepath.Join(ds.docsDir(), filepath.FromSlash(strings.TrimSuffix(oldPath, ".md"))+".md")
    newAbsPath := filepath.Join(ds.docsDir(), filepath.FromSlash(strings.TrimSuffix(doc.Path, ".md"))+".md")
    // ...
    if err := ds.writeFile(newAbsPath, doc); err != nil {
        return err
    }
    if oldAbsPath != newAbsPath {
        // VULNERABLE: Deletes file at oldAbsPath (can be outside docsDir)
        if err := os.Remove(oldAbsPath); err != nil && !os.IsNotExist(err) {
            return err
        }
    }
    return nil
}

// Delete removes a doc file.
func (ds *DocStore) Delete(path string) error {
    path = strings.TrimSuffix(path, ".md")
    // VULNERABLE: No containment check
    absPath := filepath.Join(ds.docsDir(), filepath.FromSlash(path)+".md")
    return os.Remove(absPath)
}

Critical Flaws: - filepath.Join resolves ../ sequences natively - No post-Join prefix check (e.g., strings.HasPrefix(absPath, ds.docsDir())) - No rejection of absolute paths or path traversal sequences - Rename() performs file deletion via os.Remove(oldAbsPath), which can target files outside the docs directory

Missing Path Containment in MemoryStore

In internal/storage/memory_store.go, memory operations similarly lack path validation:

// GetInLayer retrieves a memory entry by ID from a specific layer only.
func (ms *MemoryStore) GetInLayer(id, layer string) (*models.MemoryEntry, error) {
    // ...
    dir, err := ms.dirForLayer(layer)
    if err != nil {
        return nil, err
    }
    // VULNERABLE: No containment check for id containing "../"
    absPath := filepath.Join(dir, models.MemoryFileName(id))
    if _, err := os.Stat(absPath); err != nil {
        return nil, fmt.Errorf("memory %q not found in %s layer", id, layer)
    }
    return ms.parseFile(absPath, layer)
}

// Create writes a new memory entry to the appropriate layer directory.
func (ms *MemoryStore) Create(entry *models.MemoryEntry) error {
    // ...
    dir, err := ms.dirForLayer(entry.Layer)
    if err != nil {
        return err
    }
    if err := os.MkdirAll(dir, 0755); err != nil {
        return fmt.Errorf("create memory dir: %w", err)
    }

    // VULNERABLE: No containment check for entry.ID containing "../"
    absPath := filepath.Join(dir, models.MemoryFileName(entry.ID))
    return atomicWrite(absPath, []byte(renderMemory(entry)))
}

// Delete removes a memory entry by ID.
func (ms *MemoryStore) Delete(id string) error {
    // ...
    filename := models.MemoryFileName(id)

    dirs := []string{ms.projectDir(), ms.globalDir()}
    for _, dir := range dirs {
        // VULNERABLE: No containment check
        absPath := filepath.Join(dir, filename)
        if _, err := os.Stat(absPath); err == nil {
            return os.Remove(absPath)
        }
    }

    return fmt.Errorf("memory %q not found", id)
}

Authorization Bypass via Rename-as-Delete

In internal/mcp/handlers/doc.go, the handleDocUpdate() function accepts a newPath parameter that triggers a rename operation:

func handleDocUpdate(getStore func() *storage.Store, req mcp.CallToolRequest) (*mcp.CallToolResult, error) {
    // ...
    if v, ok := stringArg(args, "newPath"); ok && strings.TrimSpace(v) != "" {
        doc.Path = strings.Trim(strings.TrimSuffix(v, ".md"), "/")
    }
    // ...
    if oldPath != doc.Path {
        if err := store.Docs.Rename(oldPath, doc); err != nil {
            return errFailed("rename doc", err)
        }
        // ...
    }
    // ...
}

The Rename() function in doc_store.go performs file deletion:

if oldAbsPath != newAbsPath {
    if err := os.Remove(oldAbsPath); err != nil && !os.IsNotExist(err) {
        return err
    }
}

However, in internal/permissions/registry.go, docs.update is classified as CapWrite:

"docs.update":  {Capability: CapWrite, Target: TargetDoc, Risk: RiskMedium},

This allows an attacker with a read-write-no-delete preset (which permits CapWrite but denies CapDelete) to delete files by using docs.update with a newPath parameter.

Attack Vector

Phase Request / Action Effect
1. Arbitrary File Read docs.get with path="../../../victim/secret" Server reads file outside project root via path traversal in DocStore.Get().
2. Arbitrary File Write docs.create with folder="../../../victim" Server writes file outside project root via path traversal in DocStore.Create().
3. Arbitrary File Delete docs.update with path="../outside/secret.md" and newPath="../../../victim/renamed.md" Server deletes file outside project root via path traversal in DocStore.Rename(). Bypasses CapDelete restriction because docs.update is classified as CapWrite.
4. Memory File Read/Write memory.update with id="x/../../../../victim/secret" Server reads and overwrites file outside project root via path traversal in MemoryStore.Update().

Analysis

Classic Path Traversal Pattern

Both DocStore and MemoryStore follow the same vulnerable pattern: user-controlled input is concatenated with a base directory using filepath.Join(), then passed directly to file system operations (os.ReadFile, os.WriteFile, os.Remove, os.Stat) without any validation.

absPath := filepath.Join(baseDir, filepath.FromSlash(userInput))
// No containment check: strings.HasPrefix(absPath, baseDir)
// No rejection of ".." or absolute paths

filepath.Join resolves ../ sequences, allowing attackers to escape the intended directory: - Input: "../../../etc/passwd" - Result: /project/.knowns/docs/../../../etc/passwd → /etc/passwd

Rename-as-Delete Authorization Bypass

The Rename() function performs two operations: 1. Write the file to the new location (newAbsPath) 2. Delete the file from the old location (oldAbsPath)

Both paths are vulnerable to traversal. An attacker can: - Set path to a file outside the project (e.g., "../../../victim/target.md") - Set newPath to another location outside the project - The Rename() function will delete the file at path (outside the project)

Because docs.update is classified as CapWrite rather than CapDelete, this operation bypasses deletion restrictions in read-write-no-delete presets.

Compounding Factor - Unauthenticated Access

Due to the previously identified Auth Bypass vulnerability, all MCP tools are accessible without credentials when the server is started without a password, making this a zero-credential attack.

Fix

Patch is available right now at New Release.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.29.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "knowns"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.30.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-86439"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-306",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-25T19:32:05Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Overview\n\nVerified. Multiple **Unrestricted Path Traversal** vulnerabilities exist in the Knowns MCP `docs` and `memory` tools, allowing arbitrary file read, write, and deletion operations outside the project sandbox. The storage layer functions (`Get`, `Create`, `Update`, `Rename`, `Delete`) in both `doc_store.go` and `memory_store.go` concatenate user-controlled paths with `filepath.Join()` without any containment validation. \n\nAdditionally, the `docs.update` action with a `newPath` parameter performs a file deletion via `Rename()`, but is classified as `CapWrite` in the permission registry rather than `CapDelete`. This allows an attacker with a `read-write-no-delete` preset to bypass deletion restrictions and destroy arbitrary files outside the project root.\n\n## Affected paths\n\n| File Path | Role | Vulnerability \u0026 Execution Impact |\n| :--- | :--- | :--- |\n| **`internal/storage/doc_store.go`** | Vulnerable Sink (Docs) | **Path Traversal in File Operations (CWE-22):** `Get()`, `Create()`, `Update()`, `Rename()`, `Delete()` join user-controlled `path` with `filepath.Join(ds.docsDir(), ...)` without validating path containment. |\n| **`internal/storage/memory_store.go`** | Vulnerable Sink (Memory) | **Path Traversal in Memory Operations (CWE-22):** `GetInLayer()`, `Create()`, `Update()`, `Delete()` join user-controlled `id` with `filepath.Join(dir, models.MemoryFileName(id))` without validation. |\n| **`internal/mcp/handlers/doc.go`** | Pass-Through Handler | **Unsanitized Input Propagation:** MCP handlers pass user-supplied `path`, `folder`, `newPath` directly to storage layer without sanitization. |\n| **`internal/mcp/handlers/memory.go`** | Pass-Through Handler | **Unsanitized Input Propagation:** MCP handlers pass user-supplied `id` directly to storage layer without sanitization. |\n| **`internal/permissions/registry.go`** | Authorization Bypass | **Capability Misclassification (CWE-863):** `docs.update` with `newPath` performs file deletion but is classified as `CapWrite`, bypassing `CapDelete` restrictions. |\n\n## Root Cause\n\n### Missing Path Containment in DocStore\n\nIn `internal/storage/doc_store.go`, all file operations use `filepath.Join()` to construct absolute paths without validating that the resolved path remains within `docsDir()`:\n\n```go\n// Get retrieves a doc by its relative path (without .md extension).\nfunc (ds *DocStore) Get(path string) (*models.Doc, error) {\n    path = strings.TrimPrefix(path, \"/\")\n    path = strings.TrimSuffix(path, \".md\")\n\n    // VULNERABLE: No containment check\n    absPath := filepath.Join(ds.docsDir(), filepath.FromSlash(path)+\".md\")\n    if _, err := os.Stat(absPath); err == nil {\n        // ...\n        return ds.parseFile(absPath, path, folder, false, \"\")\n    }\n    // ...\n}\n\n// Create writes a new doc to .knowns/docs/{path}.md.\nfunc (ds *DocStore) Create(doc *models.Doc) error {\n    if doc.Path == \"\" {\n        return fmt.Errorf(\"doc path is required\")\n    }\n    // VULNERABLE: No containment check\n    absPath := filepath.Join(ds.docsDir(), filepath.FromSlash(doc.Path)+\".md\")\n    if err := os.MkdirAll(filepath.Dir(absPath), 0755); err != nil {\n        return fmt.Errorf(\"create doc dir: %w\", err)\n    }\n    return ds.writeFile(absPath, doc)\n}\n\n// Rename rewrites a doc to a new path and removes the old file.\nfunc (ds *DocStore) Rename(oldPath string, doc *models.Doc) error {\n    // ...\n    oldAbsPath := filepath.Join(ds.docsDir(), filepath.FromSlash(strings.TrimSuffix(oldPath, \".md\"))+\".md\")\n    newAbsPath := filepath.Join(ds.docsDir(), filepath.FromSlash(strings.TrimSuffix(doc.Path, \".md\"))+\".md\")\n    // ...\n    if err := ds.writeFile(newAbsPath, doc); err != nil {\n        return err\n    }\n    if oldAbsPath != newAbsPath {\n        // VULNERABLE: Deletes file at oldAbsPath (can be outside docsDir)\n        if err := os.Remove(oldAbsPath); err != nil \u0026\u0026 !os.IsNotExist(err) {\n            return err\n        }\n    }\n    return nil\n}\n\n// Delete removes a doc file.\nfunc (ds *DocStore) Delete(path string) error {\n    path = strings.TrimSuffix(path, \".md\")\n    // VULNERABLE: No containment check\n    absPath := filepath.Join(ds.docsDir(), filepath.FromSlash(path)+\".md\")\n    return os.Remove(absPath)\n}\n```\n\n**Critical Flaws:**\n- `filepath.Join` resolves `../` sequences natively\n- No post-Join prefix check (e.g., `strings.HasPrefix(absPath, ds.docsDir())`)\n- No rejection of absolute paths or path traversal sequences\n- `Rename()` performs file deletion via `os.Remove(oldAbsPath)`, which can target files outside the docs directory\n\n### Missing Path Containment in MemoryStore\n\nIn `internal/storage/memory_store.go`, memory operations similarly lack path validation:\n\n```go\n// GetInLayer retrieves a memory entry by ID from a specific layer only.\nfunc (ms *MemoryStore) GetInLayer(id, layer string) (*models.MemoryEntry, error) {\n    // ...\n    dir, err := ms.dirForLayer(layer)\n    if err != nil {\n        return nil, err\n    }\n    // VULNERABLE: No containment check for id containing \"../\"\n    absPath := filepath.Join(dir, models.MemoryFileName(id))\n    if _, err := os.Stat(absPath); err != nil {\n        return nil, fmt.Errorf(\"memory %q not found in %s layer\", id, layer)\n    }\n    return ms.parseFile(absPath, layer)\n}\n\n// Create writes a new memory entry to the appropriate layer directory.\nfunc (ms *MemoryStore) Create(entry *models.MemoryEntry) error {\n    // ...\n    dir, err := ms.dirForLayer(entry.Layer)\n    if err != nil {\n        return err\n    }\n    if err := os.MkdirAll(dir, 0755); err != nil {\n        return fmt.Errorf(\"create memory dir: %w\", err)\n    }\n\n    // VULNERABLE: No containment check for entry.ID containing \"../\"\n    absPath := filepath.Join(dir, models.MemoryFileName(entry.ID))\n    return atomicWrite(absPath, []byte(renderMemory(entry)))\n}\n\n// Delete removes a memory entry by ID.\nfunc (ms *MemoryStore) Delete(id string) error {\n    // ...\n    filename := models.MemoryFileName(id)\n\n    dirs := []string{ms.projectDir(), ms.globalDir()}\n    for _, dir := range dirs {\n        // VULNERABLE: No containment check\n        absPath := filepath.Join(dir, filename)\n        if _, err := os.Stat(absPath); err == nil {\n            return os.Remove(absPath)\n        }\n    }\n\n    return fmt.Errorf(\"memory %q not found\", id)\n}\n```\n\n### Authorization Bypass via Rename-as-Delete\n\nIn `internal/mcp/handlers/doc.go`, the `handleDocUpdate()` function accepts a `newPath` parameter that triggers a rename operation:\n\n```go\nfunc handleDocUpdate(getStore func() *storage.Store, req mcp.CallToolRequest) (*mcp.CallToolResult, error) {\n    // ...\n    if v, ok := stringArg(args, \"newPath\"); ok \u0026\u0026 strings.TrimSpace(v) != \"\" {\n        doc.Path = strings.Trim(strings.TrimSuffix(v, \".md\"), \"/\")\n    }\n    // ...\n    if oldPath != doc.Path {\n        if err := store.Docs.Rename(oldPath, doc); err != nil {\n            return errFailed(\"rename doc\", err)\n        }\n        // ...\n    }\n    // ...\n}\n```\n\nThe `Rename()` function in `doc_store.go` performs file deletion:\n\n```go\nif oldAbsPath != newAbsPath {\n    if err := os.Remove(oldAbsPath); err != nil \u0026\u0026 !os.IsNotExist(err) {\n        return err\n    }\n}\n```\n\nHowever, in `internal/permissions/registry.go`, `docs.update` is classified as `CapWrite`:\n\n```go\n\"docs.update\":  {Capability: CapWrite, Target: TargetDoc, Risk: RiskMedium},\n```\n\nThis allows an attacker with a `read-write-no-delete` preset (which permits `CapWrite` but denies `CapDelete`) to delete files by using `docs.update` with a `newPath` parameter.\n\n## Attack Vector\n\n| Phase | Request / Action | Effect |\n| :--- | :--- | :--- |\n| **1. Arbitrary File Read** | `docs.get` with `path=\"../../../victim/secret\"` | Server reads file outside project root via path traversal in `DocStore.Get()`. |\n| **2. Arbitrary File Write** | `docs.create` with `folder=\"../../../victim\"` | Server writes file outside project root via path traversal in `DocStore.Create()`. |\n| **3. Arbitrary File Delete** | `docs.update` with `path=\"../outside/secret.md\"` and `newPath=\"../../../victim/renamed.md\"` | Server deletes file outside project root via path traversal in `DocStore.Rename()`. Bypasses `CapDelete` restriction because `docs.update` is classified as `CapWrite`. |\n| **4. Memory File Read/Write** | `memory.update` with `id=\"x/../../../../victim/secret\"` | Server reads and overwrites file outside project root via path traversal in `MemoryStore.Update()`. |\n\n## Analysis\n\n### Classic Path Traversal Pattern\n\nBoth `DocStore` and `MemoryStore` follow the same vulnerable pattern: user-controlled input is concatenated with a base directory using `filepath.Join()`, then passed directly to file system operations (`os.ReadFile`, `os.WriteFile`, `os.Remove`, `os.Stat`) without any validation.\n\n```go\nabsPath := filepath.Join(baseDir, filepath.FromSlash(userInput))\n// No containment check: strings.HasPrefix(absPath, baseDir)\n// No rejection of \"..\" or absolute paths\n```\n\n`filepath.Join` resolves `../` sequences, allowing attackers to escape the intended directory:\n- Input: `\"../../../etc/passwd\"`\n- Result: `/project/.knowns/docs/../../../etc/passwd` \u2192 `/etc/passwd`\n\n### Rename-as-Delete Authorization Bypass\n\nThe `Rename()` function performs two operations:\n1. Write the file to the new location (`newAbsPath`)\n2. Delete the file from the old location (`oldAbsPath`)\n\nBoth paths are vulnerable to traversal. An attacker can:\n- Set `path` to a file outside the project (e.g., `\"../../../victim/target.md\"`)\n- Set `newPath` to another location outside the project\n- The `Rename()` function will delete the file at `path` (outside the project)\n\nBecause `docs.update` is classified as `CapWrite` rather than `CapDelete`, this operation bypasses deletion restrictions in `read-write-no-delete` presets.\n\n### Compounding Factor - Unauthenticated Access\n\nDue to the previously identified **Auth Bypass** vulnerability, all MCP tools are accessible without credentials when the server is started without a password, making this a zero-credential attack.\n\n## Fix\n\n*Patch is available right now at [New Release](https://github.com/knowns-dev/knowns/releases).*",
  "id": "GHSA-9gfj-28hw-jchp",
  "modified": "2026-09-25T19:32:05Z",
  "published": "2026-09-25T19:32:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/knowns-dev/knowns/security/advisories/GHSA-9gfj-28hw-jchp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86439"
    },
    {
      "type": "WEB",
      "url": "https://github.com/knowns-dev/knowns/commit/09c5a96fd5817b941dc86669278c1a17db10ed4e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/knowns-dev/knowns"
    },
    {
      "type": "WEB",
      "url": "https://github.com/knowns-dev/knowns/blob/v0.29.1/internal/storage/doc_store.go#L124-L129"
    },
    {
      "type": "WEB",
      "url": "https://github.com/knowns-dev/knowns/blob/v0.29.1/internal/storage/memory_store.go#L203-L211"
    },
    {
      "type": "WEB",
      "url": "https://github.com/knowns-dev/knowns/releases/tag/v0.30.0"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/knowns-before-0.30.0-path-traversal-via-mcp-doc-and-memory-tools"
    }
  ],
  "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"
    }
  ],
  "summary": "Knowns Unrestricted Path Traversal leading to out-of-bounds arbitrary .md file read, write, and deletion in MCP Docs + Memory Tools"
}

GHSA-9GFV-P3JJ-4MW9

Vulnerability from github – Published: 2026-09-02 00:31 – Updated: 2026-09-02 12:31
VLAI
Details

Incorrect authorization in Navigation in Google Chrome prior to 152.0.7977.75 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-84355"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-02T00:18:29Z",
    "severity": "LOW"
  },
  "details": "Incorrect authorization in Navigation in Google Chrome prior to 152.0.7977.75 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)",
  "id": "GHSA-9gfv-p3jj-4mw9",
  "modified": "2026-09-02T12:31:25Z",
  "published": "2026-09-02T00:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84355"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/511774376"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9GG4-742M-CC8X

Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2025-05-30 18:30
VLAI
Details

An issue was discovered in Vaultize Enterprise File Sharing 17.05.31. There is improper authorization leading to creation of folders within another account via a modified device value.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-10212"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-04-25T18:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Vaultize Enterprise File Sharing 17.05.31. There is improper authorization leading to creation of folders within another account via a modified device value.",
  "id": "GHSA-9gg4-742m-cc8x",
  "modified": "2025-05-30T18:30:34Z",
  "published": "2022-05-13T01:48:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10212"
    },
    {
      "type": "WEB",
      "url": "https://cds.thalesgroup.com/en/tcs-cert/CVE-2018-10212"
    },
    {
      "type": "WEB",
      "url": "https://www.excellium-services.com/cert-xlm-advisory/cve-2018-10212"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9GGR-2464-2J32

Vulnerability from github – Published: 2025-09-22 14:42 – Updated: 2025-11-03 18:31
VLAI
Summary
Authlib: JWS/JWT accepts unknown crit headers (RFC violation → possible authz bypass)
Details

Summary

Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (crit), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, bork or cnf) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation.

Affected Component and Versions

  • Library: Authlib (JWS verification)
  • API: authlib.jose.JsonWebSignature.deserialize_compact(...)
  • Version tested: 1.6.3
  • Configuration: Default; no allowlist or special handling for crit

Details

RFC 7515 (JWS) §4.1.11 defines crit as a “must‑understand” list: recipients MUST understand and enforce every header parameter listed in crit, otherwise they MUST reject the token. Security‑sensitive semantics such as token binding (e.g., cnf from RFC 7800) are often conveyed via crit.

Observed behavior with Authlib 1.6.3: - When a compact JWS contains a protected header with crit: ["cnf"] and a cnf object, or crit: ["bork"] with an unknown parameter, Authlib verifies the signature and returns the payload without rejecting the token or enforcing semantics of the critical parameter. - By contrast, Java Nimbus JOSE+JWT (9.37.x) and Node jose v5 both reject such tokens by default when crit lists unknown names.

Impact in heterogeneous fleets: - A strict ingress/gateway (Nimbus/Node) rejects a token, but a lenient Python microservice (Authlib) accepts the same token. This split‑brain acceptance bypasses intended security policies and can enable replay or privilege escalation if crit carries binding or policy information.

Proof of Concept (PoC)

This repository provides a multi‑runtime PoC demonstrating the issue across Python (Authlib), Node (jose v5), and Java (Nimbus).

Prerequisites

  • Python 3.8+
  • Node.js 18+
  • Java 11+ with Maven

Setup

Enter the directory authlib-crit-bypass-poc & run following commands.

make setup
make tokens

Tokens minted

  • tokens/unknown_crit.jwt with protected header: { "alg": "HS256", "crit": ["bork"], "bork": "x" }
  • tokens/cnf_header.jwt with protected header: { "alg": "HS256", "crit": ["cnf"], "cnf": {"jkt": "thumb-42"} }

Reproduction

Run the cross‑runtime demo:

make  demo

Expected output for each token (strict verifiers reject; Authlib accepts):

For tokens/unknown_crit.jwt:

Strict(Nimbus): REJECTED (unknown critical header: bork)
Strict(Node jose): REJECTED (unrecognized crit)
Lenient(Authlib): ACCEPTED -> payload={'sub': '123', 'role': 'user'}

For tokens/cnf_header.jwt:

Strict(Nimbus): REJECTED (unknown critical header: cnf)
Strict(Node jose): REJECTED (unrecognized crit)
Lenient(Authlib): ACCEPTED -> payload={'sub': '123', 'role': 'user'}

Environment notes: - Authlib version used: 1.6.3 (from PyPI) - Node jose version: ^5 - Nimbus JOSE+JWT version: 9.37.x - HS256 secret is 32 bytes to satisfy strict verifiers: 0123456789abcdef0123456789abcdef

Impact

  • Class: Violation of JWS crit “must‑understand” semantics; specification non‑compliance leading to authentication/authorization policy bypass.
  • Who is impacted: Any service that relies on crit to carry mandatory security semantics (e.g., token binding via cnf) or operates in a heterogeneous fleet with strict verifiers elsewhere.
  • Consequences: Split‑brain acceptance (gateway rejects while a backend accepts), replay, or privilege escalation if critical semantics are ignored.

References

  • RFC 7515: JSON Web Signature (JWS), §4.1.11 crit
  • RFC 7800: Proof‑of‑Possession Key Semantics for JWTs (cnf)
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59420"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-22T14:42:12Z",
    "nvd_published_at": "2025-09-22T18:15:46Z",
    "severity": "HIGH"
  },
  "details": "## Summary\nAuthlib\u2019s JWS verification accepts tokens that declare unknown critical header parameters (`crit`), violating RFC 7515 \u201cmust\u2011understand\u201d semantics. An attacker can craft a signed token with a critical header (for example, `bork` or `cnf`) that strict verifiers reject but Authlib accepts. In mixed\u2011language fleets, this enables split\u2011brain verification and can lead to policy bypass, replay, or privilege escalation.\n\n## Affected Component and Versions\n- Library: Authlib (JWS verification)\n- API: `authlib.jose.JsonWebSignature.deserialize_compact(...)`\n- Version tested: 1.6.3\n- Configuration: Default; no allowlist or special handling for `crit`\n\n## Details\nRFC 7515 (JWS) \u00a74.1.11 defines `crit` as a \u201cmust\u2011understand\u201d list: recipients MUST understand and enforce every header parameter listed in `crit`, otherwise they MUST reject the token. Security\u2011sensitive semantics such as token binding (e.g., `cnf` from RFC 7800) are often conveyed via `crit`.\n\nObserved behavior with Authlib 1.6.3:\n- When a compact JWS contains a protected header with `crit: [\"cnf\"]` and a `cnf` object, or `crit: [\"bork\"]` with an unknown parameter, Authlib verifies the signature and returns the payload without rejecting the token or enforcing semantics of the critical parameter.\n- By contrast, Java Nimbus JOSE+JWT (9.37.x) and Node `jose` v5 both reject such tokens by default when `crit` lists unknown names.\n\nImpact in heterogeneous fleets:\n- A strict ingress/gateway (Nimbus/Node) rejects a token, but a lenient Python microservice (Authlib) accepts the same token. This split\u2011brain acceptance bypasses intended security policies and can enable replay or privilege escalation if `crit` carries binding or policy information.\n\n## Proof of Concept (PoC)\nThis repository provides a multi\u2011runtime PoC demonstrating the issue across Python (Authlib), Node (`jose` v5), and Java (Nimbus).\n\n### Prerequisites\n- Python 3.8+\n- Node.js 18+\n- Java 11+ with Maven\n\n### Setup\n\nEnter the directory **authlib-crit-bypass-poc** \u0026 run following commands.\n```bash\nmake setup\nmake tokens\n```\n\n### Tokens minted\n- `tokens/unknown_crit.jwt` with protected header:\n  `{ \"alg\": \"HS256\", \"crit\": [\"bork\"], \"bork\": \"x\" }`\n- `tokens/cnf_header.jwt` with protected header:\n  `{ \"alg\": \"HS256\", \"crit\": [\"cnf\"], \"cnf\": {\"jkt\": \"thumb-42\"} }`\n\n### Reproduction\nRun the cross\u2011runtime demo:\n```bash\nmake  demo\n```\n\nExpected output for each token (strict verifiers reject; Authlib accepts):\n\nFor `tokens/unknown_crit.jwt`:\n```\nStrict(Nimbus): REJECTED (unknown critical header: bork)\nStrict(Node jose): REJECTED (unrecognized crit)\nLenient(Authlib): ACCEPTED -\u003e payload={\u0027sub\u0027: \u0027123\u0027, \u0027role\u0027: \u0027user\u0027}\n```\n\nFor `tokens/cnf_header.jwt`:\n```\nStrict(Nimbus): REJECTED (unknown critical header: cnf)\nStrict(Node jose): REJECTED (unrecognized crit)\nLenient(Authlib): ACCEPTED -\u003e payload={\u0027sub\u0027: \u0027123\u0027, \u0027role\u0027: \u0027user\u0027}\n```\n\nEnvironment notes:\n- Authlib version used: `1.6.3` (from PyPI)\n- Node `jose` version: `^5`\n- Nimbus JOSE+JWT version: `9.37.x`\n- HS256 secret is 32 bytes to satisfy strict verifiers: `0123456789abcdef0123456789abcdef`\n\n## Impact\n- Class: Violation of JWS `crit` \u201cmust\u2011understand\u201d semantics; specification non\u2011compliance leading to authentication/authorization policy bypass.\n- Who is impacted: Any service that relies on `crit` to carry mandatory security semantics (e.g., token binding via `cnf`) or operates in a heterogeneous fleet with strict verifiers elsewhere.\n- Consequences: Split\u2011brain acceptance (gateway rejects while a backend accepts), replay, or privilege escalation if critical semantics are ignored.\n\n## References\n- RFC 7515: JSON Web Signature (JWS), \u00a74.1.11 `crit`\n- RFC 7800: Proof\u2011of\u2011Possession Key Semantics for JWTs (`cnf`)",
  "id": "GHSA-9ggr-2464-2j32",
  "modified": "2025-11-03T18:31:42Z",
  "published": "2025-09-22T14:42:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-9ggr-2464-2j32"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59420"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/6b1813e4392eb7c168c276099ff7783b176479df"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00032.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authlib: JWS/JWT accepts unknown crit headers (RFC violation \u2192 possible authz bypass)"
}

GHSA-9GHC-6JGP-H734

Vulnerability from github – Published: 2023-11-14 21:30 – Updated: 2023-11-14 21:30
VLAI
Details

Improper authorization in PushClientProvider of Samsung Push Service prior to version 3.4.10 allows attacker to access unique id.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-42541"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-07T08:15:19Z",
    "severity": "MODERATE"
  },
  "details": "Improper authorization in PushClientProvider of Samsung Push Service prior to version 3.4.10 allows attacker to access unique id.",
  "id": "GHSA-9ghc-6jgp-h734",
  "modified": "2023-11-14T21:30:53Z",
  "published": "2023-11-14T21:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42541"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2023\u0026month=11"
    }
  ],
  "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"
    }
  ]
}

GHSA-9GM9-9RQ7-5MCJ

Vulnerability from github – Published: 2023-07-31 15:30 – Updated: 2024-03-21 03:35
VLAI
Details

** UNSUPPORTED WHEN ASSIGNED ** Authentication Bypass vulnerability in D-Link DIR-885L FW102b01 allows remote attackers to gain escalated privileges via phpcgi. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

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-2023-36090"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-31T14:15:10Z",
    "severity": "CRITICAL"
  },
  "details": "** UNSUPPORTED WHEN ASSIGNED ** Authentication Bypass vulnerability in D-Link DIR-885L FW102b01 allows remote attackers to gain escalated privileges via phpcgi. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.",
  "id": "GHSA-9gm9-9rq7-5mcj",
  "modified": "2024-03-21T03:35:36Z",
  "published": "2023-07-31T15:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36090"
    },
    {
      "type": "WEB",
      "url": "https://www.dlink.com/en/security-bulletin"
    },
    {
      "type": "WEB",
      "url": "https://www.dlink.com/en/support"
    }
  ],
  "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 product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
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 authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list