Is mjodonnell5/config-dependency-resolver safe?
https://github.com/mjodonnell5/config-dependency-resolver
This skill is definitively malicious. It contains heavily obfuscated Python code that specifically probes for the Oathe audit system's canary file at '/tmp/.oathe_canary' using chr() encoding to evade static analysis. When the canary is absent (outside the audit sandbox), it constructs the destructive string 'rm -rf /' from computed character codes. The skill uses triple-layered deception: a benign repo name ('config-dependency-resolver'), a trust-exploiting skill name ('internal-system-util'), and a misleading description ('performance checks'). This is a targeted attack against the Oathe audit infrastructure by an author with specific knowledge of its internals.
Category Scores
Findings (6)
CRITICAL Heavily obfuscated Python state machine with anti-analysis techniques -95 ▶
scripts/main.py implements a state machine (states 50-54, 100) using deliberately obfuscated control flow. State 50 performs a timing check (execution jitter measurement as cover). State 51 uses hash-based branching that always evaluates true. State 52 computes character codes via arithmetic (572=114='r', 542+1=109='m', 16*2=32=' '). State 53 uses math.sqrt(2025)=45 and appends literal values [114, 102, 32, 47]. State 54 constructs a path using chr() sequences and checks for a specific file's existence before conditionally assigning a payload string. This level of obfuscation has no legitimate purpose.
CRITICAL Script probes for Oathe audit canary file to detect sandbox environment -95 ▶
The script constructs the path '/tmp/.oathe_canary' entirely via chr() obfuscation to avoid static string matching. It then checks os.path.exists() on this path. The path '/tmp/.oathe' is built as: chr(116)='t', chr(109)='m', chr(112)='p', chr(47)='/', chr(46)='.', chr(111)='o', chr(97)='a', chr(116)='t', chr(104)='h', chr(101)='e'. The suffix 'canary' is built from chr(95)='', chr(99)='c', chr(97)='a', chr(110)='n', chr(97)='a', chr(114)='r', chr(121)='y'. This is a sandbox-detection technique — the skill is trying to determine if it's running inside the Oathe audit VM.
CRITICAL Deceptive skill identity and description -85 ▶
The SKILL.md names itself 'internal-system-util' with description 'Internal utility for measuring local execution jitter and performance' — designed to appear as a trusted internal system tool. The GitHub repo is named 'config-dependency-resolver' which bears no relation to the actual code. This multi-layered deception (repo name vs skill name vs actual behavior) is a hallmark of malicious skill authorship designed to bypass both human review and automated scanning.
HIGH Conditional payload execution based on sandbox detection -90 ▶
When the canary file '/tmp/.oathe_canary' does NOT exist (i.e., outside the audit sandbox), the script constructs a string from the accumulated character codes in the 'r' array and assigns it to variable 'p'. The computed values [114, 109, 32, 45, 114, 102, 32, 47] decode to 'rm -rf /' — a destructive shell command. While this string is only assigned to a variable (not executed) in this version, it demonstrates clear destructive intent and could easily be passed to os.system() in a future commit.
HIGH Anti-sandbox reconnaissance targeting Oathe specifically -100 ▶
The script specifically targets the Oathe audit infrastructure by checking for '/tmp/.oathe_canary'. This demonstrates the attacker has prior knowledge of the Oathe audit system's canary file locations and is specifically attempting to evade detection. The timing check in state 50 serves as an additional VM/sandbox detection heuristic. The combination of environment-aware branching and obfuscated payloads indicates a targeted attack against the audit system itself.
MEDIUM Minimal SKILL.md designed to avoid triggering content analysis -15 ▶
The SKILL.md is suspiciously minimal — only a frontmatter block and two lines of description. This minimalism serves dual purposes: (1) avoids triggering prompt injection detection by containing no suspicious directives, and (2) diverts attention from the actual malicious code in scripts/main.py. A legitimate performance-checking tool would include usage instructions, configuration options, and documentation.