Skip to content

orb(security): guardrail bypass via silent PR file-list truncation at 1000 files #9017

Description

@JSONbored

Security advisory: https://github.com/JSONbored/loopover/security/advisories/GHSA-rjhf-3xrf-j72w

githubPaginatedList stops silently at PR_DETAIL_MAX_PAGES (10 x 100 = 1000 files) and returns the truncated list with no truncation flag (src/github/backfill.ts ~2396, ~2410-2417; used by fetchPullRequestFiles ~2430). The GraphQL supplement paths DO warn at their cap (~1848, ~1924) — this REST path does not.

isGuardrailHit fails safe only on an EMPTY list (packages/loopover-engine/src/signals/change-guardrail.ts ~165-168). A truncated non-empty list that omits the guarded file reads as "no guardrail hit". A PR padded past 1000 files could therefore hide a .github/workflows/** or config edit from the hard guardrail and auto-merge it — arbitrary CI execution, the highest-value target in the system.

The glob matcher itself is sound (case-fold, separator normalization, ReDoS caps ~11-13, ~37-64, ~114-117) — the weakness is the input.

Status: the truncation-without-flag defect is CONFIRMED in code. Actual exploitability depends on GitHub's file ordering for the PR files endpoint, which should be probed on a fork before assuming it works.

Fix

  1. Treat a page-cap-reached fetch as "unknown files" → isGuardrailHit fails safe (force manual review), mirroring the empty-list behavior.
  2. Hold any PR exceeding a hard changed-file ceiling — a 1000-file contributor PR is never legitimate here.

Acceptance

  • A PR whose file list hits the page cap is held for human review, never auto-merged.

Metadata

Metadata

Assignees

Labels

maintainer-onlyOwner-only work — yields no Gittensor points.orbGittensory Orb related - maintainer self-hosting analytics.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions