Skip to content

fix(review): guard contributor screenshot fetches#4976

Open
JSONbored wants to merge 3 commits into
mainfrom
codex/propose-fix-for-unsafe-screenshot-url-fetch
Open

fix(review): guard contributor screenshot fetches#4976
JSONbored wants to merge 3 commits into
mainfrom
codex/propose-fix-for-unsafe-screenshot-url-fetch

Conversation

@JSONbored

Copy link
Copy Markdown
Owner

Motivation

  • Contributor-provided screenshot URLs were being fetched via the trusted bot helper (fetchShotContentBlock), which followed redirects and buffered entire responses without timeout/size/type checks, enabling SSRF and resource-consumption risks.
  • Harden fetching of attacker-controlled PR-markdown images so the advisory vision check cannot be used to reach internal hosts or exhaust worker memory/time.

Description

  • Add fetchExternalScreenshotContentBlock(url) in src/review/visual/capture.ts that revalidates every redirect hop with isSafeHttpUrl, uses manual redirects, enforces a fetch timeout, enforces a bounded redirect budget, caps buffered response bytes, and validates Content-Type against an allowlist before producing an AiContentBlock (PNG/JPEG/WebP/GIF). PNG bytes are downscaled for vision like bot-produced shots.
  • Replace contributor-image fetches in the screenshot-table advisory flow to use fetchExternalScreenshotContentBlock instead of the trusted fetchShotContentBlock in src/queue/processors.ts to ensure untrusted URLs get the stricter guards.
  • Add unit tests in test/unit/visual-capture.test.ts that cover successful public image responses, unsafe redirect targets, oversized responses, non-image responses, safe redirect handling with MIME preservation, inputs that cause early rejection, bounded redirect budget, and fetch failures.
  • Regenerate Cloudflare worker types (worker-configuration.d.ts) to satisfy the repo checks.

Testing

  • Ran targeted unit tests for the new guarded fetch: npx vitest run test/unit/visual-capture.test.ts -t "fetchExternalScreenshotContentBlock" — passed.
  • Ran wiring/unit tests that exercise the screenshot-table vision path: npx vitest run test/unit/screenshot-table-vision-wiring.test.ts test/unit/visual-capture.test.ts -t "screenshot-table|fetchExternalScreenshotContentBlock|fetchShotContentBlock" — passed.
  • Typechecking: npm run typecheck -- --pretty false — passed.
  • Attempted full local gate: npm run test:ci was started but could not complete reliably in this environment (long-suite timeouts and external network/audit failures); npm audit --audit-level=moderate returned 403 Forbidden from the registry so the audit step could not complete here.

Codex Task

@superagent-security

Copy link
Copy Markdown
Contributor

Superagent didn't find any vulnerabilities or security issues in this PR.

@JSONbored

Copy link
Copy Markdown
Owner Author

Rebased onto current `main` to resolve the merge conflict (`worker-configuration.d.ts`'s generated header only; regenerated via `npm run cf-typegen` to confirm), which is what was blocking this PR from ever completing review and had it stuck in the auto-repair loop (`agent.sweep.regate.repair_exhausted`, tracked as #5001).

While rebasing, found screenshot-table-vision-wiring.test.ts had regressed to 7 failing tests: the new fetchExternalScreenshotContentBlock's Content-Type validation correctly rejects the file's fake image responses, which never set that header. Added the header to each fake response and one more regression test for a malformed (parser-rejected) redirect Location header, the one branch this left uncovered. npm run typecheck and the full test/unit/visual-capture.test.ts + test/unit/screenshot-table-vision-wiring.test.ts + test/unit/queue.test.ts suites (285 tests total) are green.

@codecov

codecov Bot commented Jul 11, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.14%. Comparing base (66ed61d) to head (02bc014).
⚠️ Report is 5 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4976   +/-   ##
=======================================
  Coverage   94.14%   94.14%           
=======================================
  Files         467      467           
  Lines       39598    39645   +47     
  Branches    14444    14457   +13     
=======================================
+ Hits        37278    37325   +47     
  Misses       1664     1664           
  Partials      656      656           
Flag Coverage Δ
shard-1 46.47% <59.57%> (-0.02%) ⬇️
shard-2 33.44% <8.51%> (-0.41%) ⬇️
shard-3 31.57% <8.51%> (-0.59%) ⬇️
shard-4 32.67% <8.51%> (+0.95%) ⬆️
shard-5 33.29% <100.00%> (-0.01%) ⬇️
shard-6 45.08% <8.51%> (+0.15%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
src/queue/processors.ts 95.42% <ø> (ø)
src/review/visual/capture.ts 96.00% <100.00%> (+1.22%) ⬆️
🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@gittensory-orb gittensory-orb Bot added the gittensor:bug Gittensor-scored bug fix — scores a 0.05x multiplier. label Jul 11, 2026
@gittensory-orb

gittensory-orb Bot commented Jul 11, 2026

Copy link
Copy Markdown

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

Review updated: 2026-07-12 01:09:44 UTC

4 files · 1 AI reviewer · 2 blockers · readiness 93/100 · CI green · unstable

⏸️ Suggested Action - Manual Review

  • No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
  • Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Review summary
AI review could not be completed for this PR head. Gittensory is holding this PR for manual review instead of relying on deterministic signals alone.

Concerns raised — review before merging

  • No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
  • Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.
Signal Result Evidence
Code review ❌ 2 blockers 1 reviewer
Linked issue ⚠️ Missing No linked issue or no-issue rationale found.
Related work ✅ No active overlap found No same-issue or scoped active PR overlap found.
Change scope ✅ 20/20 Low review scope from cached public metadata (no linked issue context).
Validation posture ✅ 25/25 PR body includes validation/test evidence.
Contributor workload ✅ 10/10 Author activity: 45 registered-repo PR(s), 37 merged, 415 issue(s).
Contributor context ✅ Confirmed Gittensor contributor JSONbored; Gittensor profile; 45 PR(s), 415 issue(s).
Gate result ❌ Blocking Repo-configured hard blocker found.
Improvement ✅ Minor risk: clean · value: minor — Code changes are accompanied by test evidence.
Review context
  • Author: JSONbored
  • Role context: owner (maintainer lane)
  • Public audience mode: oss maintainer
  • Lane context: Repository is configured for direct PR review.
  • Public profile languages: Python, TypeScript, Ruby, Go, JavaScript, MDX, Shell, Solidity
  • Official Gittensor activity: 45 PR(s), 415 issue(s).
  • PR-specific overlap: none found.
Contributor next steps
  • Treat this as maintainer-lane context rather than normal contributor-lane activity.
  • Explain no-issue PR.
  • Link the issue being solved, or explicitly explain why this is a no-issue PR.
Signal definitions
  • Related work = same linked issue, overlapping active PRs, or title/path similarity.
  • Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
  • Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
  • Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
  • Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.
[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

  • @gittensory ask &lt;question&gt; answers contribution-quality Q&A with source citations and freshness.
  • @gittensory chat &lt;question&gt; answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
  • A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed


💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

  • Re-run Gittensory review

@gittensory-orb gittensory-orb Bot added the manual-review Gittensor contributor context label Jul 11, 2026
…nt-type

fetchExternalScreenshotContentBlock (added by the preceding commit)
validates the response Content-Type before accepting an image -- a
real hardening step, since a contributor-controlled URL could
otherwise return anything. screenshot-table-vision-wiring.test.ts's
fake image responses never set that header, so every fetch was
silently rejected and every finding-producing test regressed to an
empty findings array. Add the header to each fake response, and add a
regression test for a Location header the URL parser itself rejects
(distinct from an absent one), covering the one branch this left
uncovered.
@JSONbored JSONbored force-pushed the codex/propose-fix-for-unsafe-screenshot-url-fetch branch from 11978a2 to a9fb634 Compare July 11, 2026 13:04
…rnalScreenshotContentBlock

The existing "rejects non-image" test always supplied a content-type header
(just the wrong MIME type), so headers.get("content-type") returning null --
and the ?? "" fallback actually firing -- was never exercised. A string-body
Response auto-gets a "text/plain" content-type from the Fetch API itself, so
the new test uses a binary body (Uint8Array) instead, which has no such
auto-assignment.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

aardvark codex gittensor:bug Gittensor-scored bug fix — scores a 0.05x multiplier. manual-review Gittensor contributor context

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant