Repository navigation
Security: GcsArtifactService missing input validation on path components allows cross-user artifact access (CWE-22) #6115
Description
Summary
GcsArtifactService._get_blob_prefix() constructs GCS blob paths by directly interpolating user_id, app_name, and session_id into f-strings without any validation. A user_id containing path traversal sequences (e.g., ../other-user) allows an attacker to read, write, or delete another user's artifacts in the same GCS bucket.
Vulnerability
File: src/google/adk/artifacts/gcs_artifact_service.py, lines 156-171
python def _get_blob_prefix(self, app_name, user_id, filename, session_id=None): # No validation on app_name, user_id, or session_id if self._file_has_user_namespace(filename): return f'{app_name}/{user_id}/user/{filename}' return f'{app_name}/{user_id}/{session_id}/{filename}'
Attack
A user_id of ../victim-user constructs:
app_name/../victim-user/user/filename -> victim-user/user/filename
This allows User A to:
- Read User B's artifacts (
_load_artifact) - Overwrite User B's artifacts (
_save_artifact) - Delete User B's artifacts (
_delete_artifact)
Comparison with FileArtifactService
FileArtifactService in the same package already validates these inputs via _validate_path_segment() (line 141-163), which rejects path separators, .., and null bytes. GcsArtifactService lacks this validation entirely.
Impact
- Cross-user data access in multi-tenant deployments using GCS-backed artifact storage
- Data destruction via cross-user artifact deletion
- CWE-22: Improper Limitation of a Pathname to a Restricted Directory
Fix
Add _validate_gcs_path_segment() with the same checks as FileArtifactService._validate_path_segment(), and call it in _get_blob_prefix() before constructing blob paths.
References
- CWE-22: https://cwe.mitre.org/data/definitions/22.html
- Related: Security: Path Traversal in _load_skill_from_gcs_dir enables arbitrary file write (VRP #499557362) #5603 (GCS skill path traversal, fixed in PR Security: Fix path traversal in GCS skill extraction (Zip Slip) #5927)
Activity
surajksharma07 commentedon Jun 15, 2026
@Ashutosh0x confirmed the path traversal in _get_blob_prefix(), and the approach in PR #6116 (adding _validate_gcs_path_segment() to mirror what FileArtifactService already does) is exactly the right direction.
Could you make sure the 10 unit tests cover all four operations (save, load, delete, list) before we kick off the review on #6116?
Once you've verified the fix holds up end-to-end on your setup, we'll move forward with the review.
Ashutosh0x commentedon Jun 15, 2026
Thanks @surajksharma07! I've updated the tests in PR #6116 to cover all four operations. The test file now has:
Unit tests (10) -
_validate_gcs_path_segment()directly:../traversal blocked..and.blockedOperation-level tests (8) - through the async public API with mocked GCS client:
save_artifact- rejects traversal user_id, traversal app_name, null byte user_idload_artifact- rejects traversal user_id, traversal session_iddelete_artifact- rejects traversal user_id, backslash user_idlist_artifact_keys- rejects traversal user_id,..user_idTotal: 18 tests covering all four operations and all validation rules.
Each operation-level test uses
unittest.mockto mock the GCS client, confirming thatInputValidationErroris raised before any GCS call is made. Ready for review!surajksharma07 commentedon Jun 16, 2026
@Ashutosh0x Confirmed, thanks — the 18 tests cover all four operations (save/load/delete/list) plus the segment-validation unit cases, and #6116 is green across CI (header-check, change-validation, CLA).
Team is looking more into it.
Thanks!
fix: Validate path segments in GcsArtifactService and InMemoryArtifac…
fix: Validate path segments in GcsArtifactService and InMemoryArtifac…