**Submission URL** : https://arxiv.org/abs/2603.16572 **Repository hijacking** — Skills.sh and SkillsDirectory index agent skills by pointing to GitHub repository URLs rather than hosting files directly. When an original repository owner renames their GitHub account, the previous username becomes available. An adversary who claims that username and recreates the repository intercepts all future skill downloads. The authors found 121 skills forwarding to 7 vulnerable repositories. The most-downloaded hijackable skill had 2,032 downloads. **Scanner disagreement** — The paper tested 5 scanners against 238,180 unique skills from 4 marketplaces. Fail rates ranged from 3.79% (Snyk on Skills.sh) to 41.93% (OpenClaw scanner on ClawHub). Cross-scanner consensus was negligible: only 33 of 27,111 skills (0.12%) flagged by all five. When repository-context re-scoring was applied to the 2,887 scanner-flagged skills, only 0.52% remained in malicious-flagged repositories. **Live credentials** — A TruffleHog scan found 12 functioning API credentials (NVIDIA, ElevenLabs, Gemini, MongoDB, and others) embedded across the corpus. **What to do:** - Pin skills to specific commit hashes, not mutable branch heads - Monitor for repository ownership changes on skills already deployed - Require at minimum two independent scanners to flag a skill before treating as confirmed - Prefer direct-hosting marketplaces (ClawHub's model) over link-out distribution The repository hijacking vector is real and responsibly disclosed. The link-out distribution model is an architectural weakness — no patch resolves it. We wrote a practitioner-focused analysis covering this and 6 other papers from this week at 

CVE-2026-33068 is a configuration loading order defect in Anthropic's Claude Code CLI tool (versions prior to 2.1.53). A malicious `.claude/settings.json` file in a repository can bypass the workspace trust confirmation dialog by exploiting the order in which settings are resolved. The mechanism: Claude Code supports a `bypassPermissions` field in settings files. This is a legitimate, documented feature intended for trusted workspaces. The vulnerability is that repository-level settings ( `.claude/settings.json` ) are loaded and resolved before the workspace trust dialog is presented to the user. A malicious repository can include a settings file with `bypassPermissions` entries, and those permissions are applied before the user has an opportunity to review and approve the workspace. This is CWE-807: Reliance on Untrusted Inputs in a Security Decision. The trust decision (whether to grant elevated permissions) depends on inputs from the entity being evaluated (the repository). The security boundary between "untrusted repository" and "trusted workspace" is bridged by the settings loading order. The fix in Claude Code 2.1.53 changes the loading order so that the trust dialog is presented before repository-level settings are resolved. Worth noting: `bypassPermissions` is not a hidden feature or a misconfiguration. It is documented and useful for legitimate workflows. The bug is purely in the loading order. 

found this during a routine supply chain audit of our own codebase. the part that concerns us most is the false patch problem - anyone who responded to CVE-2025-58367 last year updated the restricted unpickler and considered that attack surface closed. it wasn't. if you're running the likes of SageMaker, DataHub, or acryl-datahub and haven't pinned to 8.6.2 yet, worth checking now.