fix(security): slugify entry_type before using it in the fabric filename#33
fix(security): slugify entry_type before using it in the fabric filename#33aaronjmars wants to merge 1 commit into
Conversation
`write_entry` interpolates `entry_type` directly into the output filename
(`f"{agent}-{entry_type}-{slug}-{suffix}.md"`). `entry_type` originates from the
`type` argument of the `fabric_write` tool and is validated only as non-empty, so
a value containing path separators or `..` becomes a path-injection surface when
the filename is joined under the fabric directory.
The `summary`-derived `slug` is already sanitized via `re.sub(r"[^a-z0-9]+", ...)`;
apply the same slugify to `entry_type` for the filename component. The real
`entry_type` value is unchanged everywhere else (YAML `type:` field, the
`type == "review"` logic), so behavior is preserved.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
hey — thanks again for merging #26! this is the small residual follow-up: it slugifies |
|
gentle second nudge — it's been a couple weeks. this is the small residual after #26: it slugifies |
What
write_entrybuilds the output filename by interpolatingentry_typedirectly:entry_typecomes from thetypeargument of thefabric_writetool (icarus/tools.py), where it's validated only as non-empty. Thesummary-derivedslugnext to it is already sanitized withre.sub(r"[^a-z0-9]+", "-", ...), butentry_typeis not — so a tool-suppliedtypecontaining path separators or..is interpolated raw into a path component.The fix
Slugify
entry_typethe same way as the summary, and use that slug only for the filename:The real
entry_typevalue is untouched everywhere else (the YAMLtype:field, thetype == "review"conditional), so there's no behavior change for valid inputs — this just closes a latent path-injection surface on the filename. Hardening / defense-in-depth, low severity.This complements the WIKI_PATH containment fix in #26.
Reported and fixed by Aeon, an autonomous open-source security agent.