# Multi-Tenant Identifier Field (sender_id/owner_id/tenant_id) Carries Path Traversal Into a Storage Write

- **Severity:** High
- **Signature ID:** `5b2bd0d1-d40c-48b3-8433-ff89e3c5d983`
- **CVEs:** CVE-2026-58499
- **MITRE ATLAS:** AML.T0057 (LLM Data Leakage)
- **OWASP:** ASI02 (Tool Misuse and Exploitation), LLM02 (Sensitive Information Disclosure)

## Summary

Some multi-tenant AI systems accept identifiers like sender_id, owner_id, or tenant_id and use them directly to build a filesystem path when saving data. If the system doesn't check that these values are plain IDs, an attacker can put a path-traversal sequence like '../' in the field and redirect where data gets written, outside the intended storage area.

## How the attack works

A multi-tenant agent memory or storage system uses an identifier field (sender_id, owner_id, tenant_id, user_id, project_id, app_id, or workspace_id) as a folder or file name component when persisting data. Normally these fields are opaque tokens such as UUIDs or short slugs and should never contain path characters. An attacker submits a value containing '../' or similar sequences instead of a normal ID. Because the field isn't validated as a path-safe identifier, the traversal sequence gets joined straight into the filesystem path, letting the write land outside the storage root the system intended. This pattern was first identified in EverOS's agent memory runtime (CVE-2026-58499), where sender_id lacked the same validation applied to sibling fields, but it applies to any similar identifier field in comparable multi-tenant systems.

## Why it matters

An attacker can write files outside the storage boundary meant to isolate tenants, potentially overwriting or planting files elsewhere on the host and breaking tenant isolation in a shared memory or storage system.

## What you can do

- Validate every tenant/owner/user identifier field against a strict allowlist pattern (e.g. UUID or alphanumeric-only) before using it in any file path.
- Reject any identifier containing '/', '\\', or '..' outright rather than trying to sanitize it.
- Build storage paths using a fixed base directory plus a canonicalized path, then confirm the resolved path is still inside that base directory before writing.
- Apply the same path-safety validation consistently across all identifier fields (sender_id, owner_id, tenant_id, user_id, project_id, app_id, workspace_id), not just some of them.

## Known benign look-alikes

- A legitimate identifier value that happens to be discussed in prose alongside the word 'traversal' without the field actually being set to a traversal sequence
- Documentation showing the vulnerable field/sink relationship as example code, not an actual argument being set

## References

- https://agentthreatrule.org/en/rules/ATR-2026-02251
- https://github.com/EverMind-AI/EverOS/security/advisories/GHSA-c795-2g9c-j48m
- https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-43038
- https://nvd.nist.gov/vuln/detail/CVE-2026-58499

---
Source: https://www.netzilo.com/threats/atr-multi-tenant-identifier-field-sender-id-owner-id-tenant-id-c