What happened
The Strands Agents Harness SDK published security advisory GHSA-763v-5pjm-fx36 on October 5, 2026. The advisory rates the issue Moderate and identifies it as CWE-276, Incorrect Default Permissions During installation. It lists no CVE ID. The affected package is strands-agents on pip: versions earlier than 1.48.0 are affected, and 1.48.0 is the patched version. The report says it was reproduced on commit dd7b41de38cb.
The issue concerns the SDK's default FileSessionManager behavior. By default, it writes session data below /tmp/strands/sessions, a path derived from the system temporary directory. Rather than setting private permissions explicitly, the storage behavior relies on the operating system process's umask. The advisory says that under a common umask of 022, the relevant directories are created with mode 0755 and JSON files with mode 0644. Those modes allow other local users to read the directories and files, even though they cannot necessarily change them.
The advisory provides a reproduction using that umask. It shows /tmp/strands/sessions and a created session directory with 0755 permissions, while session.json has 0644. Its test fixture writes a fake secret into the session dictionary and confirms that the resulting file contains that secret. The report identifies the default temporary-directory path, creation of parent directories without a private mode, ordinary writing of JSON files, and creation of session directories without a private mode as the relevant implementation behavior.
This matters because persisted agent sessions can be broader than chat transcripts. According to the advisory, they may contain prompts, model output, tool inputs and outputs, intermediate state, and secrets that pass through an agent. The stated exposure scenarios are shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. A second local user on such a system is the threat described here; the advisory is not claiming remote access.
The report suggests several possible mitigations: use a private per-user data directory rather than /tmp; create /tmp/strands and descendants with 0700; write session JSON atomically with 0600; consider refusing an existing default directory that is not owned by the current user or is group- or world-accessible; and document explicit storage_dir configuration for shared storage. These are recommendations in the advisory. It does not state which of them, if any, shipped in version 1.48.0, so the patched-version label should not be read as a detailed account of patch mechanics.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
This supports Agent security moves to runtime boundaries. The failure was not a model deciding to reveal protected information. It was a default filesystem boundary around state that an agent had already accumulated. As agents retain more tool output, history, and intermediate data, storage location, ownership, and file modes become part of the practical authorization system. A safe prompt cannot compensate for a session artifact readable by an unintended local principal.
Why it matters
Teams often treat session persistence as an implementation detail added for continuity, debugging, recovery, or cross-turn context. This advisory shows why it should instead be handled as a data-security decision. An agent can receive sensitive context through a prompt or a tool call without ever displaying it to an unauthorized person; a world-readable local JSON file can still disclose it later.
The exposure is most relevant where a process is not the only tenant: shared CI runners, notebook environments, bastion hosts, developer workstations, and multi-user compute machines. The immediate response for an affected deployment is to move to the documented patched release. But dependency version is only one control. Builders need to know where each agent framework persists state, what principals can read it, and whether an existing directory has permissions and ownership that match the intended trust boundary. Defaults inherited from a host environment can become security-relevant product behavior.
This also changes how teams scope secrets. Tool outputs, intermediate state, and model responses may be retained even when an application does not intentionally save a transcript. A review that looks only at visible chat logs can therefore miss an on-disk copy created by the framework's session layer.
Limits and uncertainty
The advisory establishes a local-read confidentiality risk under the described default storage behavior and permissions. It does not document exploitation in the wild, identify affected deployments, quantify how often installations use umask 022, or say that every Strands application persists secrets in sessions. It also does not explain the precise implementation of version 1.48.0's patch, whether it alters permissions for an existing directory, or whether users can still select shared storage deliberately.
The listed mitigations are suggestions from the report, not a release-note-level specification of the fix. The source also does not provide performance, migration, or compatibility information. Teams should verify their deployed version and inspect their own configured storage paths and permissions rather than infer patch mechanics or their exact exposure from the advisory alone.
Skill to build now
Make a small agent-state inventory this week. For each framework or service that persists sessions, record the storage path, creating process identity, directory and file modes, retention period, and the kinds of tool or prompt data that can enter it. Include default paths as well as explicitly configured ones.
Then test the boundary rather than relying on application assumptions. From a second local account, container user, or equivalent non-owner context, attempt to list the session directory and read a newly created artifact. Check ownership and permissions both when a path is created fresh and when it already exists. This turns a general concern about agent memory into a testable access-control property.
Reader takeaway
Agent sessions are sensitive operational data, not harmless cache files. If a team uses Strands FileSessionManager, version 1.48.0 is the documented patched release. Regardless of framework, persisted agent state deserves the same ownership and permission review as other stores that may receive secrets, tool output, or private working context on shared hosts.
Open question
What exact permission and storage-path behavior does Strands 1.48.0 implement for new and already-existing default session directories?