Bug 2554025 (CVE-2026-111079)

Goose's @goose terminal integration (goose term) installs a shell preexec hook
that logs every command the user types. When the user later invokes @goose, all
logged commands since the last assistant response are sent verbatim — without
any sanitization — as context to the configured LLM provider endpoint.

Credentials entered in the terminal (bearer tokens, API keys, passwords passed
as command arguments or set via export) leave the user's machine and enter a
system outside their control, where they may be logged, retained under the
provider's data-retention policy, or accessed by provider employees or
infrastructure compromises. Affected Versions

- Introduced in: commit 5f50198318e6edc502b96187ab647119d9daab3b (PR #5887) https://github.com/aaif-goose/goose/commit/5f50198318e6edc502b96187ab647119d9daab3b  
- First released in: v1.16.0
- Affected through: v1.54.0
- Affected releases: 58 versions (v1.16.0 – v1.54.0)
- Attribution
- This issue was discovered by these engineers: Rodolfo Olivieri (Red Hat), Manuel Moran (Red Hat), and Theofanis Petkos (Red Hat, GitHub account https://github.com/thepetk).

Vulnerable Code
Full details in this tab, if needed.
Examples of impact
Scenario 1: Long-lived API keys and personal access tokens in commands
A user passes a long-lived credential as a command-line argument:

curl -H "Authorization: token GITHUB_PAT_VALUE" https://api.github.com/repos/private/repo

or:

aws configure set aws_secret_access_key AWS_SECRET_KEY_VALUE

These are not short-lived bearer tokens — GitHub Personal Access Tokens (classic) do not expire by default, and AWS access keys persist until explicitly rotated. A single disclosure can grant indefinite access.

Later in the same session, the user asks Goose an entirely unrelated question:

@goose what does the -r flag do in cp?

The question has no relation to the earlier commands and does not require shell context.

Goose unconditionally reads the shell history — including the command with the long-lived credential — and sends it as-is to the configured LLM endpoint. Every @goose invocation includes all shell history since the last response, regardless of whether the question is related to prior commands.
The credential now exists in a system outside the user's control (LLM provider logs, data-retention storage, etc.).
Anyone who later gains access to those logs can reuse the credential to authenticate as the user. Because these credentials are long-lived, the window of exploitation persists until the user discovers the leak and manually rotates the credential.
Scenario 2: Environment variable assignments with secrets
A user sets credentials as environment variables in their terminal for use by CLI tools:

export AWS_SECRET_ACCESS_KEY=AWS_SECRET_KEY_VALUE
export GITHUB_TOKEN=GITHUB_PAT_VALUE
export DATABASE_URL=postgres://admin:SECRET_PASSWORD:5432/app

The preexec hook captures each export command verbatim.

The user later asks Goose something completely unrelated to the environment setup:

@goose what does the -r flag do in cp?

Goose unconditionally sends the full shell history — including every export statement — to the LLM provider. The question's topic is irrelevant; all history since the last response is always included.
The attacker now has not just one credential but potentially a full set of secrets: cloud provider keys, database connection strings with embedded passwords, API tokens for third-party services. A single @goose invocation can leak an entire working environment's secrets in one request.