FileArtifactService user_id with '/' composes onto another user's session artifacts

[artemkulyk]

🔴 Required Information

Describe the Bug:
FileArtifactService stores artifacts under root/apps/{app_name}/users/{user_id}/[sessions/{session_id}/]artifacts/{filename}. validate_path_segment rejects traversal (..), absolute paths, drive letters, and null bytes, but permits / and \ in user_id.

A caller whose user_id is u1/sessions/s2 therefore has its user-scoped storage composed onto exactly victim user u1's session s2 tree. Read, overwrite, and delete of the victim's payload succeed with no .. segments.

This is a service-level issue. Stock HTTP artifact endpoints are not reachable this way (Starlette does not decode %2F inside a path segment). GcsArtifactService is not this collision (blob layout has no literal sessions/artifacts segments). The shared validator should still reject separators so identifiers remain a single path segment.

Google VRP issue 557708759 was closed as Infeasible (not tracked as a security bug) with a request to file this publicly.

Steps to Reproduce:

1. save_artifact(app_name, user_id="u1", session_id="s2", filename="notes", ...) (session-scoped).
2. Call load_artifact / save_artifact / delete_artifact with user_id="u1/sessions/s2" and the same filename (user-scoped).
3. Observe the victim's session artifact is read, overwritten, or deleted.

Expected Behavior:
user_id, app_name, and session_id must not contain path separators. validate_path_segment raises InputValidationError. Nested filenames remain allowed.

Observed Behavior:
validate_path_segment("u1/sessions/s2", "user_id") succeeds. _base_root joins the slash into the tree, colliding with users/u1/sessions/s2/artifacts.

Environment Details:

• ADK Library Version (pip show google-adk): 2.8.0 (a119dd7751082dbbd9a65f71e359abdc2be659cc and current main)
• Desktop OS: macOS
• Python Version (python -V): 3.12 / 3.13

Model Information:

• Are you using LiteLLM: N/A (library-level FileArtifactService)
• Which model is being used: N/A

---

🟡 Optional Information

Regression:
Present as long as validate_path_segment allows / in identifiers used by FileArtifactService._base_root.

Minimal Reproduction Code:

# victim
await svc.save_artifact(app_name="myapp", user_id="u1", session_id="s2",
                        filename="notes", artifact={"text": "VICTIM-SECRET"})
# attacker
await svc.load_artifact(app_name="myapp", user_id="u1/sessions/s2", filename="notes")

Additional Context:
Exploitable only where embedding apps pass slash-containing user_id values (hierarchical IDs). Suggested fix: reject / and \ in validate_path_segment, matching evaluation/_path_validation.py.

[surajksharma07]

@artemkulyk The crafted user_id does land on the victim's session directory and the read succeeds exactly as described. Tried your fix from #7068 (rejecting embedded separators in validate_path_segment) and it blocks the attack while leaving legitimate nested filenames and normal reads untouched. Given this touches the shared validator could you also confirm GcsArtifactService's existing tests still pass clean on your branch before we move it to review?

[artemkulyk]

@surajksharma07 yes, tests still passed.

.venv/bin/pytest tests/unittests/artifacts/test_artifact_util.py tests/unittests/artifacts/test_artifact_service.py -q
861 passed

[artemkulyk]

@surajksharma07

One clarification: would you consider the ability for a crafted user_id to resolve into another user's session artifact namespace, allowing cross-user read, overwrite, or delete, to violate the intended user/session isolation guarantees of FileArtifactService?

I'm specifically trying to understand the intended isolation boundary of the service.

[surajksharma07]

@artemkulyk Confirmed the GCS coverage on our end too, it's parametrized right through test_artifact_service.py against the mocked bucket so 861 passed does exercise it not just IN_MEMORY. On your question: yes this is a real isolation-boundary violation not just a validation nicety. user_id and session_id exist as separate scoping params specifically so the service partitions storage per user/session (see the layout comment atop FileArtifactService) and a crafted user_id defeating that is exactly the guarantee the API contract implies. Clearing request clarification, this is ready for a maintainer to take to merge review.