GHSA-C795-2G9C-J48M: Remote Path Traversal and Arbitrary File Write in EverOS Memory Ingestion

EverOS is designed as a Markdown-first storage and retrieval framework for artificial intelligence agents. It allows applications to ingest and organize long-term agent interactions, compiling structured logs into local Markdown configurations. The framework exposes a public-facing API endpoint at /api/v1/memory/add to handle incoming conversation logs and serialize them under dynamic hierarchical paths based on metadata parameters.

During user-memory extraction, the API processes structured payloads representing historical interaction events. The vulnerability lies in the lack of input sanitization applied to the sender_id parameter, which represents the identifier of the message author. While other organizational variables such as app_id and project_id are strictly verified, the framework trustingly integrates the raw sender_id string directly into local directory paths.

The resulting path vulnerability belongs to the class of Improper Limitation of a Pathname to a Restricted Directory, tracked as CWE-22. Because the application server processes these payloads programmatically without user intervention, remote unauthenticated entities can exploit this endpoint to write files on any storage path accessible to the user running the EverOS daemon.

The root cause of this vulnerability is the absence of validation checks on the sender_id parameter before it is processed by the local file storage subsystem. In the vulnerable versions of EverOS, the incoming JSON payload is parsed into a Pydantic Data Transfer Object (DTO) in src/everos/entrypoints/api/routes/memorize.py. The sender_id field is defined simply as a string type with a minimum length requirement, lacking structural constraints or pattern matching.

When a client submits memory entries, the persistence layer resolves the final file system write path through a nested directory join. The folder structure is generated as follows: [configured_memory_root]/[app_id]/[project_id]/[sender_id]/episodes/[episode_id].md. Since Python’s standard pathlib.Path utility evaluates double-dot sequences (../) literal-by-literal during path normalization, providing directory traversal segments within sender_id alters the resolved directory tree.

Because the underlying operating system executes write operations relative to the calculated absolute path, the file system writes escape the bounds of memory_root. The path calculation collapses the target directories step-by-step for each ../ sequence encountered, permitting the file writer to point to root folders such as /var/www/ or any other directory writable by the server process group.

In vulnerable versions, the DTO parsing mechanism permitted any arbitrary sequence of string characters to define the message sender:

# Vulnerable DTO structure
class MessageItemDTO(BaseModel):
    sender_id: str = Field(..., min_length=1)
    sender_name: str | None = None
    role: Literal["user", "assistant", "tool"]
    timestamp: int

The vulnerability was resolved in commit a10cdcd197747f371b7879a32c2cc3f77471e9c2 by implementing validation constraints at the model layer and adding a directory containment check in the persistence layer.

The patched schema enforces strict string sanitization using a Pydantic AfterValidator and a regex character filter:

# Patched DTO with validation
_PATH_SAFE_CHARSET = r"^[a-zA-Z0-9_.@+-]+$"
_PATH_TRAVERSAL_TOKENS = frozenset({".", ".."})
 
def validate_path_safe_id(v: str) -> str:
    if v in _PATH_TRAVERSAL_TOKENS:
        raise ValueError(f"identifier cannot be reserved token: {v}")
    return v
 
PathSafeId = Annotated[str, AfterValidator(validate_path_safe_id)]
 
class MessageItemDTO(BaseModel):
    sender_id: PathSafeId = Field(
        ...,
        min_length=1,
        max_length=128,
        pattern=_PATH_SAFE_CHARSET,
    )

Additionally, a safety check was added directly to MarkdownWriter to verify directory boundaries relative to the server root directory:

def _ensure_within_root(self, target: Path) -> Path:
    root = self._memory_root.root
    resolved = target.resolve()
    if not resolved.is_relative_to(root):
        raise PathTraversalError(
            f"write target escapes the memory root: {resolved} not under {root}"
        )
    return resolved

This defensive design ensures that even if upstream DTO validation fails or is bypassed by dynamic configurations, the persistence layer actively raises a PathTraversalError and blocks directory escape. The fix is considered structurally complete, as the combination of whitelist validation and runtime containment checks prevents directory traversal bypass vectors.

An unauthenticated remote attacker can exploit this vulnerability by submitting a crafted HTTP POST request to the /api/v1/memory/add endpoint of an exposed EverOS deployment. The attack vector relies on injecting directory traversal sequences directly into the sender_id property of a message payload.

Below is an example of an exploitation payload that demonstrates how an attacker can leverage this flaw to write file contents outside the target storage path:

POST /api/v1/memory/add HTTP/1.1
Host: vulnerable-everos.local:8000
Content-Type: application/json
Content-Length: 351
 
{
  "session_id": "session_01",
  "app_id": "default",
  "project_id": "default",
  "messages": [
    {
      "sender_id": "../../../../../var/tmp/malicious_trigger",
      "role": "user",
      "timestamp": 1700000000000,
      "content": "Payload written to an unauthorized system directory"
    }
  ]
}

During exploitation, the server normalizes the target write location by evaluating the nested segments. The traversal string resolves to /var/tmp/malicious_trigger/episodes/[episode_id].md, causing the framework to write the output to /var/tmp/ instead of the restricted application storage pool. The final written file contains metadata and content formatted as a Markdown conversation episode.

The impact of this vulnerability is classified as High for integrity and Low for availability, yielding an overall CVSS base score of 8.2. Because the application processes user-supplied markdown files directly on the local host, attackers can overwrite configuration files, inject unauthorized assets, or pollute operational databases.

While the attacker cannot execute arbitrary commands directly through standard path traversal, the ability to control file paths and partially influence file contents poses a severe risk. If the daemon runs with elevated permissions, system-level configurations or web document roots can be altered, potentially leading to unauthorized data modification, cross-site scripting hosting, or configuration-based local system compromises.

Furthermore, write access to database-adjacent directories allows attackers to overwrite critical application storage objects, generating application processing errors that disrupt services. Confidentiality remains unaffected because the endpoint does not return local files to the client.

Deploying the official patch is the primary remediation strategy to address this vulnerability. System administrators must upgrade all local installations of EverOS to version 1.0.1 or later. If immediate updating is not possible, security teams can implement several architectural workarounds to restrict access and limit potential traversal damage.

To restrict the impact of potential directory escape, run the EverOS daemon under a dedicated, low-privilege user account. This service user should only have write permissions within the defined memory root folder, neutralizing path traversal attempts outside the restricted directory tree.

Additionally, deploying a Web Application Firewall (WAF) or an API Gateway rule to filter requests containing directory traversal payloads can help identify and mitigate exploitation attempts before they reach the backend service.