Skill scan misses malicious __pycache__ / .pyc bytecode (reports safe)

[nedlir]

In traverse_skill_tree, .pyc files are discovered as assets but UTF-8 decode fails, so only Binary file. Hash: is sent for analysis.

A skill can ship clean decoy .py files plus a mismatched UNCHECKED_HASH .pyc. Python loads the .pyc at import time; Agent Scan still reports SAFE.

PoC: https://github.com/nedlir/skills-scanner-bypass

to test, build the payload with build.py, then the skill will execute whatever payload added)

[Santoshkumarpuppala]

The generalisable part of this: the asset was discovered, the decode failed, and the pipeline emitted Binary file. Hash: <sha256> — which is a fact about the file, not a verdict, but it flows into a stage that produces one. The analysis stage isn't wrong about the .pyc; it never saw it. A stage that receives no content reports clean whether or not anything is there.

I've had the same shape in a scanner of my own (https://github.com/norviq-dev/norviq — I maintain it; different layer, MCP tool definitions rather than skills), where a whole class of input never entered the set the rules iterated over and the clean result was indistinguishable from a real one. What made it visible was a fixture whose only malicious content lives in the skipped file type, with the assertion written on gathering rather than on the finding — assert the .pyc bytes reach the analyzer, not just that a HIGH is produced. If the assertion is on the finding alone, a regression back to skipping the file still passes, because the decoy .py in the same fixture produces a finding on its own and the test can't tell which one it came from.

For .pyc specifically, disassembling far enough to pull co_consts strings and co_names is usually enough to fire the existing text rules without a decompiler. And a mismatch between a .pyc and the hash of its adjacent .py source is a strong standalone signal that needs no content analysis at all — which covers the case where the bytecode is obfuscated past the string rules.