Skip to content

Knowns Unrestricted Path Traversal leading to out-of-bounds arbitrary .md file read, write, and deletion in MCP Docs + Memory Tools

High severity GitHub Reviewed Published Aug 16, 2026 in knowns-dev/knowns • Updated Sep 25, 2026

Package

npm knowns (npm)

Affected versions

<= 0.29.1

Patched versions

0.30.0

Description

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.

References

@howznguyen howznguyen published to knowns-dev/knowns Aug 16, 2026
Published to the GitHub Advisory Database Sep 25, 2026
Reviewed Sep 25, 2026
Last updated Sep 25, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(64th percentile)

Weaknesses

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. Learn more on MITRE.

Missing Authentication for Critical Function

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

Incorrect Authorization

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. Learn more on MITRE.

CVE ID

CVE-2026-86439

GHSA ID

GHSA-9gfj-28hw-jchp

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.