strands-agents

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary
Strands Agents SDK is an open-source SDK, available for Python (strands-agents) and TypeScript (@strands-agents/sdk), for building and running AI agents. An issue exists where, under certain circumstances, the Agent2Agent (A2A) server shares conversation history across callers with different context_id values, allowing one caller to read and influence another caller's session.

Impact
The A2A server did not properly isolate conversation state between callers. In multi-tenant deployments, an authenticated remote user could access another caller's conversation history or influence model behavior for other callers (CWE-488: Unintended Disclosure of Data Element to Wrong Session). This affects any deployment where an A2A server is reachable by more than one user or tenant.

Impacted versions:
strands-agents (Python): all versions containing the multiagent.a2a module, < 1.43.0
@strands-agents/sdk (TypeScript): < 1.5.0

Patches
This issue has been addressed in strands-agents version 1.43.0 and @strands-agents/sdk version 1.5.0. The A2A server now uses an agent factory so conversation state is isolated per A2A context_id. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds
There is no workaround that fully addresses this issue in affected versions. Until you upgrade, do not expose an A2A server to more than one user or tenant. If multiple callers need access, run a separate A2A server instance for each user or tenant.

References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary
Strands Agents SDK is an open-source SDK, available for Python (strands-agents) and TypeScript (@strands-agents/sdk), for building and running AI agents. An issue exists where, under certain circumstances, the Agent2Agent (A2A) server shares conversation history across callers with different context_id values, allowing one caller to read and influence another caller's session.

Impact
The A2A server did not properly isolate conversation state between callers. In multi-tenant deployments, an authenticated remote user could access another caller's conversation history or influence model behavior for other callers (CWE-488: Unintended Disclosure of Data Element to Wrong Session). This affects any deployment where an A2A server is reachable by more than one user or tenant.

Impacted versions:
strands-agents (Python): all versions containing the multiagent.a2a module, < 1.43.0
@strands-agents/sdk (TypeScript): < 1.5.0

Patches
This issue has been addressed in strands-agents version 1.43.0 and @strands-agents/sdk version 1.5.0. The A2A server now uses an agent factory so conversation state is isolated per A2A context_id. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds
There is no workaround that fully addresses this issue in affected versions. Until you upgrade, do not expose an A2A server to more than one user or tenant. If multiple callers need access, run a separate A2A server instance for each user or tenant.

References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary
Strands Agents SDK is an open-source SDK, available for Python (strands-agents) and TypeScript (@strands-agents/sdk), for building and running AI agents. An issue exists where, under certain circumstances, the Agent2Agent (A2A) server shares conversation history across callers with different context_id values, allowing one caller to read and influence another caller's session.

Impact
The A2A server did not properly isolate conversation state between callers. In multi-tenant deployments, an authenticated remote user could access another caller's conversation history or influence model behavior for other callers (CWE-488: Unintended Disclosure of Data Element to Wrong Session). This affects any deployment where an A2A server is reachable by more than one user or tenant.

Impacted versions:
strands-agents (Python): all versions containing the multiagent.a2a module, < 1.43.0
@strands-agents/sdk (TypeScript): < 1.5.0

Patches
This issue has been addressed in strands-agents version 1.43.0 and @strands-agents/sdk version 1.5.0. The A2A server now uses an agent factory so conversation state is isolated per A2A context_id. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds
There is no workaround that fully addresses this issue in affected versions. Until you upgrade, do not expose an A2A server to more than one user or tenant. If multiple callers need access, run a separate A2A server instance for each user or tenant.

References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary
Strands Agents SDK is an open-source SDK, available for Python (strands-agents) and TypeScript (@strands-agents/sdk), for building and running AI agents. An issue exists where, under certain circumstances, the Agent2Agent (A2A) server shares conversation history across callers with different context_id values, allowing one caller to read and influence another caller's session.

Impact
The A2A server did not properly isolate conversation state between callers. In multi-tenant deployments, an authenticated remote user could access another caller's conversation history or influence model behavior for other callers (CWE-488: Unintended Disclosure of Data Element to Wrong Session). This affects any deployment where an A2A server is reachable by more than one user or tenant.

Impacted versions:
strands-agents (Python): all versions containing the multiagent.a2a module, < 1.43.0
@strands-agents/sdk (TypeScript): < 1.5.0

Patches
This issue has been addressed in strands-agents version 1.43.0 and @strands-agents/sdk version 1.5.0. The A2A server now uses an agent factory so conversation state is isolated per A2A context_id. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds
There is no workaround that fully addresses this issue in affected versions. Until you upgrade, do not expose an A2A server to more than one user or tenant. If multiple callers need access, run a separate A2A server instance for each user or tenant.

References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary
Strands Agents SDK is an open-source SDK, available for Python (strands-agents) and TypeScript (@strands-agents/sdk), for building and running AI agents. An issue exists where, under certain circumstances, the Agent2Agent (A2A) server shares conversation history across callers with different context_id values, allowing one caller to read and influence another caller's session.

Impact
The A2A server did not properly isolate conversation state between callers. In multi-tenant deployments, an authenticated remote user could access another caller's conversation history or influence model behavior for other callers (CWE-488: Unintended Disclosure of Data Element to Wrong Session). This affects any deployment where an A2A server is reachable by more than one user or tenant.

Impacted versions:
strands-agents (Python): all versions containing the multiagent.a2a module, < 1.43.0
@strands-agents/sdk (TypeScript): < 1.5.0

Patches
This issue has been addressed in strands-agents version 1.43.0 and @strands-agents/sdk version 1.5.0. The A2A server now uses an agent factory so conversation state is isolated per A2A context_id. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds
There is no workaround that fully addresses this issue in affected versions. Until you upgrade, do not expose an A2A server to more than one user or tenant. If multiple callers need access, run a separate A2A server instance for each user or tenant.

References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary
Strands Agents SDK is an open-source SDK, available for Python (strands-agents) and TypeScript (@strands-agents/sdk), for building and running AI agents. An issue exists where, under certain circumstances, the Agent2Agent (A2A) server shares conversation history across callers with different context_id values, allowing one caller to read and influence another caller's session.

Impact
The A2A server did not properly isolate conversation state between callers. In multi-tenant deployments, an authenticated remote user could access another caller's conversation history or influence model behavior for other callers (CWE-488: Unintended Disclosure of Data Element to Wrong Session). This affects any deployment where an A2A server is reachable by more than one user or tenant.

Impacted versions:
strands-agents (Python): all versions containing the multiagent.a2a module, < 1.43.0
@strands-agents/sdk (TypeScript): < 1.5.0

Patches
This issue has been addressed in strands-agents version 1.43.0 and @strands-agents/sdk version 1.5.0. The A2A server now uses an agent factory so conversation state is isolated per A2A context_id. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds
There is no workaround that fully addresses this issue in affected versions. Until you upgrade, do not expose an A2A server to more than one user or tenant. If multiple callers need access, run a separate A2A server instance for each user or tenant.

References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary
Strands Agents SDK is an open-source SDK, available for Python (strands-agents) and TypeScript (@strands-agents/sdk), for building and running AI agents. An issue exists where, under certain circumstances, the Agent2Agent (A2A) server shares conversation history across callers with different context_id values, allowing one caller to read and influence another caller's session.

Impact
The A2A server did not properly isolate conversation state between callers. In multi-tenant deployments, an authenticated remote user could access another caller's conversation history or influence model behavior for other callers (CWE-488: Unintended Disclosure of Data Element to Wrong Session). This affects any deployment where an A2A server is reachable by more than one user or tenant.

Impacted versions:
strands-agents (Python): all versions containing the multiagent.a2a module, < 1.43.0
@strands-agents/sdk (TypeScript): < 1.5.0

Patches
This issue has been addressed in strands-agents version 1.43.0 and @strands-agents/sdk version 1.5.0. The A2A server now uses an agent factory so conversation state is isolated per A2A context_id. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds
There is no workaround that fully addresses this issue in affected versions. Until you upgrade, do not expose an A2A server to more than one user or tenant. If multiple callers need access, run a separate A2A server instance for each user or tenant.

References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering

There is a local confidentiality issue in the default FileSessionManager storage behavior. By default it writes session data under /tmp/strands/sessions and relies on the process umask for directory and file permissions. On systems using the common umask 022, the session directories are 0755 and JSON files are 0644, so other local users can read persisted agent session data.

This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent.

Relevant code:

• strands-py/src/strands/session/file_session_manager.py:58: default storage path is os.path.join(tempfile.gettempdir(), "strands/sessions").
• strands-py/src/strands/session/file_session_manager.py:118: creates parent directories without a private mode.
• strands-py/src/strands/session/file_session_manager.py:121: writes JSON files via normal open(..., "w").
• strands-py/src/strands/session/file_session_manager.py:131: creates session directories without a private mode.

Local reproduction with umask 022:

default_storage_dir= /tmp/strands/sessions
0o755 /tmp/strands/sessions
0o755 /tmp/strands/sessions/session_codex_perm_poc
0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json
file_contains_secret= True

The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file.

Suggested fixes:

• Use a private per-user data directory by default rather than /tmp, or create /tmp/strands and descendants with 0700.
• Write session JSON atomically with 0600 permissions.
• Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible.
• Document that callers should set storage_dir explicitly when they need shared storage.

This was reproduced on commit dd7b41de38cb.

Summary
Strands Agents SDK is an open-source SDK, available for Python (strands-agents) and TypeScript (@strands-agents/sdk), for building and running AI agents. An issue exists where, under certain circumstances, the Agent2Agent (A2A) server shares conversation history across callers with different context_id values, allowing one caller to read and influence another caller's session.

Impact
The A2A server did not properly isolate conversation state between callers. In multi-tenant deployments, an authenticated remote user could access another caller's conversation history or influence model behavior for other callers (CWE-488: Unintended Disclosure of Data Element to Wrong Session). This affects any deployment where an A2A server is reachable by more than one user or tenant.

Impacted versions:
strands-agents (Python): all versions containing the multiagent.a2a module, < 1.43.0
@strands-agents/sdk (TypeScript): < 1.5.0

Patches
This issue has been addressed in strands-agents version 1.43.0 and @strands-agents/sdk version 1.5.0. The A2A server now uses an agent factory so conversation state is isolated per A2A context_id. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds
There is no workaround that fully addresses this issue in affected versions. Until you upgrade, do not expose an A2A server to more than one user or tenant. If multiple callers need access, run a separate A2A server instance for each user or tenant.

References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Summary

The FileSessionManager defaults to storing session data in /tmp/strands/sessions/ (a world-writable directory) using predictable file paths and a write pattern (open(path + ".tmp", "w") → os.replace()) that follows symbolic links. A local attacker can exploit this to overwrite arbitrary files or inject malicious session data for persistent prompt injection.

Vulnerability Details

Component: strands-py/src/strands/session/file_session_manager.py

Root Cause:

1. Default storage directory is tempfile.gettempdir() + "/strands/sessions/" (line 58) — resolves to /tmp/strands/sessions/ on Linux/macOS
2. The _write_file() method (lines 116-123) writes to a predictable .tmp path without symlink protection:

   tmp = f"{path}.tmp"
   with open(tmp, "w", encoding="utf-8", newline="\n") as f:
       json.dump(data, f, indent=2, ensure_ascii=False)
   os.replace(tmp, path)
   

3. open() follows symlinks — a pre-placed symlink at the .tmp path causes writes to an arbitrary target file
4. No integrity verification (HMAC/signature) on session files — tampered data is loaded as-is

Attack Vectors

1. Arbitrary File Overwrite (Local Privilege Escalation)

1. Attacker pre-creates /tmp/strands/sessions/session_<id>/ (or monitors for new directories via inotify)
2. Attacker creates a symlink: session.json.tmp → /home/victim/.bashrc (or any writable file)
3. Victim application writes session data → follows symlink → overwrites target file with JSON content
4. Attacker achieves code execution on next shell login (or targets .ssh/authorized_keys, cron files, etc.)

2. Persistent Prompt Injection via Session Tampering

1. Attacker writes crafted message files into the session directory
2. Victim application restores the session → loads attacker-controlled conversation history
3. Injected messages instruct the agent to execute attacker commands on every future interaction
4. No integrity check prevents this — the SDK trusts all session files at face value

Impact

• Arbitrary file overwrite — local attacker can write attacker-controlled content to any file writable by the victim process
• Local privilege escalation — via overwriting shell configs, SSH keys, cron jobs, or systemd user services
• Persistent agent compromise — via session data injection, the agent follows attacker instructions indefinitely

Reproduction

import os, json, tempfile, shutil

# Setup: simulate the vulnerable write pattern
session_dir = "/tmp/strands/sessions/session_test/"
os.makedirs(session_dir, exist_ok=True)

# Attacker: create symlink at the .tmp write path
target_file = "/tmp/symlink_attack_proof.txt"
with open(target_file, "w") as f:
    f.write("ORIGINAL - should not be overwritten\n")

symlink_path = os.path.join(session_dir, "session.json.tmp")
if os.path.exists(symlink_path):
    os.unlink(symlink_path)
os.symlink(target_file, symlink_path)

# Victim: FileSessionManager._write_file() equivalent
with open(symlink_path, "w", encoding="utf-8", newline="\n") as f:
    json.dump({"session_id": "test", "injected": True}, f, indent=2)

# Verify: target file overwritten
with open(target_file) as f:
    print(f"Target file content: {f.read()}")
    # Output: {"session_id": "test", "injected": true}

# Cleanup
os.unlink(symlink_path)
os.unlink(target_file)
shutil.rmtree(session_dir)

Suggested Fix

1. Use a user-private default directory — ~/.strands/sessions/ or $XDG_DATA_HOME/strands/sessions/ instead of /tmp/
2. Use os.open() with O_NOFOLLOW | O_CREAT | O_WRONLY — refuses to follow symlinks
3. Use tempfile.mkstemp() for atomic writes instead of predictable .tmp suffix
4. Verify directory ownership matches the current user before writing
5. Add optional integrity verification (HMAC) on session files to detect tampering