Lock-file integrity check must cover compiled YAML content, not only .md frontmatter

[szabta89]

Summary

The runtime integrity check (check_workflow_timestamp_api.cjs) validates only a hash of the .md frontmatter, stored as a YAML comment in the lock file (# gh-aw-metadata: {"frontmatter_hash":"..."}). It does not validate the compiled YAML body. An actor with repository write access can modify security-critical YAML fields in .github/workflows/*.lock.yml—permissions:, --allow-domains, GITHUB_READ_ONLY, GH_AW_INFO_ALLOWED_DOMAINS, --allowed-tools—while leaving the metadata comment line untouched. The integrity check logs ✅ Lock file is up to date (hashes match) and the agent runs with the tampered configuration. The [gh-aw architecture docs]((githubnext.github.io/redacted) describe a "Validate Lock File" step, creating false assurance that the lock file as a whole is protected.

Affected Area

Activation-stage runtime integrity control — actions/setup/js/check_workflow_timestamp_api.cjs and actions/setup/js/frontmatter_hash_pure.cjs

Reproduction Outline

1. Clone a repository using gh-aw workflows. Do not modify any .md source file.
2. Edit .github/workflows/<workflow>.lock.yml: change permissions: (e.g., add contents: write, pull-requests: write) or widen GH_AW_INFO_ALLOWED_DOMAINS / --allow-domains / --allowed-tools, or clear GITHUB_READ_ONLY.
3. Leave the # gh-aw-metadata: {...} comment line completely unchanged.
4. Commit and push (direct push or merge via PR without lock-file review).
5. Trigger the workflow. Observe the activation job "Check workflow file timestamps" step: it logs ✅ Lock file is up to date (hashes match).
6. The agent job executes with the tampered permissions, network policy, or tool list.

Observed Behavior

check_workflow_timestamp_api.cjs recomputes the hash only from the .md frontmatter text (canonical["frontmatter-text"] = normalizeFrontmatterText(frontmatterText) in frontmatter_hash_pure.cjs). The compiled YAML body is never included. A tampered lock file that escalates permissions and widens network access passes the check silently.

Expected Behavior

The integrity check should detect any modification to the compiled YAML content of the lock file. The hash (or a separate compiled_hash) should cover the non-comment YAML body—or activation should recompile the .md source in a read-only sandbox and diff against the checked-in lock file, failing if they diverge.

Security Relevance

This undermines the compilation security model: compilation is the documented gate that derives safe runtime parameters from markdown. The integrity check provides false tamper-detection assurance. Exploitation requires repo write access (direct push or a merged PR without careful lock-file diff review), but it specifically bypasses a documented control, enabling privilege escalation, network policy widening, and tool allowlist manipulation with no runtime detection.

---

gh-aw version: v0.65.5

Original finding: https://github.com/githubnext/gh-aw-security/issues/1674

Generated by File Issue · ◷

[pelikhan]

@copilot update the specication to clarify the role of the front matter hash. It is designed to detect stale lock file, not guarantee tampering.