Skip to content

feat: verify S226 @g5n-dev bounty — NO verdict, SSRF claim is speculative (#538)#350

Open
xliry wants to merge 4 commits intopeteromallet:mainfrom
xliry:fix/bounty-4010235362-g5n-dev
Open

feat: verify S226 @g5n-dev bounty — NO verdict, SSRF claim is speculative (#538)#350
xliry wants to merge 4 commits intopeteromallet:mainfrom
xliry:fix/bounty-4010235362-g5n-dev

Conversation

@xliry
Copy link

@xliry xliry commented Mar 7, 2026

Issue: #204
Submission: #204 (comment)
Author: @g5n-dev

Problem (in our own words)

S226 claims _download(filename) in update_skill.py is vulnerable to SSRF because the filename parameter is concatenated into a URL without validation, and raises concerns about missing HTTPS certificate validation and repository compromise risk.

Evidence

  • desloppify/app/commands/update_skill.py:22-31: _RAW_BASE is hardcoded, _download() concatenates filename without validation
  • desloppify/app/commands/update_skill.py:88-89: _download() called only with "SKILL.md" and f"{overlay_name}.md" — both hardcoded constants
  • desloppify/app/skill_docs.py:34-42: SKILL_TARGETS is a module-level constant dict with fixed overlay names ("CLAUDE", "CURSOR", "COPILOT", etc.)
  • desloppify/app/commands/update_skill.py:112-116: interface validated against SKILL_TARGETS keys before reaching _download()
  • No code path exists where user input reaches _download()

Fix

No fix needed — verdict is NO

Verdict

Question Answer Reasoning
Is this poor engineering? NO _download() only receives hardcoded constant filenames; no user input reaches it
Is this at least somewhat significant? NO The vulnerability is entirely hypothetical — the PoC explicitly requires "if a future caller passes user-controlled input"

Final verdict: NO

Scores

Criterion Score
Significance 1/10
Originality 2/10
Core Impact 0/10
Overall 1/10

Summary

The submission claims SSRF via _download(filename) but filename is never user-controlled — it's always derived from hardcoded SKILL_TARGETS constants. The MITM/certificate claim is factually wrong (Python's urllib validates HTTPS certs by default since 3.4). The PoC states "if a future caller passes user-controlled input," which is speculative. Same author as S219/S220/S222/S224/S225 (all NO).

Why Desloppify Missed This

  • What should catch: N/A — there is no real issue to catch
  • Why not caught: The # noqa: S310 suppresses Bandit's blanket urlopen warning; this is a valid false-positive suppression, not a vulnerability
  • What could catch: N/A

Verdict Files

Generated with Lota

xliry and others added 4 commits March 7, 2026 03:58
… (#451)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…eld confirmed (#456)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…tive (#538)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant