GHSA-p347-7m45-694r

GHSA-p347-7m45-694r — Huginn LocalFileAgent Arbitrary File Read

• Infinit3i & p80n-sec

This is a vulnerability I reported (alongside p80n-sec) in Huginn, the self-hosted automation platform for building agents that watch and act on the web. Even with Huginn’s “insecure agents” safety switch turned off, one code path in the LocalFileAgent would still open any file you pointed it at — which lets an authenticated user read arbitrary files off the server, including the secrets that let you forge an admin session.

It’s published as GHSA-p347-7m45-694r with a CVSS v3.1 score of 9.6 (critical), tagged as path traversal (CWE-22) and incorrect authorization (CWE-863). It affects Huginn builds up to and including 2026.08.27 and is fixed in 2026.09.08. No CVE was assigned.

Where it goes wrong

Huginn has a global setting, ENABLE_INSECURE_AGENTS, that’s meant to keep the dangerous stuff locked down. When it’s disabled, LocalFileAgent correctly refuses to do file operations — almost everywhere. The catch is that the refusal wasn’t applied consistently.

The agent’s get_io method skipped that check entirely. So while the front-door file operations were properly blocked, get_io would happily open whatever path it was handed regardless of the setting. That’s the authorization bypass: the guard exists, it’s just not on every door.

How it’s abused

The trick is that LocalFileAgent doesn’t have to act alone. Other agents — ReadFileAgent, CsvAgent, PostAgent — consume “file pointers” that a LocalFileAgent hands them. So an authenticated user can:

1. Create a LocalFileAgent pointing at a sensitive path.
2. Feed that file pointer to a consuming agent, either through an event or a dry run.
3. The consuming agent calls the unguarded get_io, which opens the file even though insecure agents are supposedly disabled.
4. The file’s contents come back to the attacker, read with the privileges of the Huginn process.

The nasty target here is Huginn’s own .env file. It holds APP_SECRET_TOKEN, and once you have that, you can forge session cookies — which means signing in as any user, including an administrator. So an arbitrary file read quietly escalates into full admin account takeover. That “scope changed” bit in the CVSS vector is exactly this: the bug reaches past the file system and into the app’s authentication.

Impact

Any authenticated user could read arbitrary files on the host, exposing configuration and secrets far beyond what their role should allow. The standout is APP_SECRET_TOKEN leaking from .env, which turns a read primitive into session forgery and administrator takeover. Instances already running with ENABLE_INSECURE_AGENTS=true don’t gain anything new here — those operators had already opted into file access — but everyone relying on that switch being off for safety was exposed.

The fix in 2026.09.08 makes get_io honor the same check as every other entry point: it logs the refusal and returns nil so the consuming agent just skips the event. If untrusted users had access before you upgraded, rotate APP_SECRET_TOKEN and any related secrets, because they may already be gone.

This one’s a clean lesson in why a security check has to live on every path into a sensitive operation, not just the obvious ones. All it takes is a single helper method that forgot to ask permission, and the whole guard rail stops meaning anything.