Pyrefly - Python Language Tooling

AI Security Review

Evidence context: threat category none; evidence quality strong.

Pyrefly is Meta's Python language tooling extension: autocomplete, type checking and code navigation backed by an open source language server. That shape explains nearly everything the scan flagged.

The code-smell matches all land in bundled build output or boilerplate text. YARA--postinstall_system_command, YARA--postinstall_obfuscation and YARA--UsingShellInterpreterWhenExecutingOSCommands fire on extension/dist/extension.js, the webpack bundle of the extension host code. A rule set that looks for child_process patterns and shell invocation will match any bundle that spawns a subprocess, and spawning a subprocess is this extension's entire job. The same system command rule also matches resources/find_pyrefly.py, a helper whose filename states its purpose: locate the Pyrefly server binary so the extension can launch it. It matches extension/package.json too, which is the rule firing on the presence of a scripts block rather than on any executed command.

The clearest sign these are lexical matches rather than behaviour is YARA--postinstall_network_communication matching extension/LICENSE.txt. A license file has no network behaviour to detect, so whatever the rule keys on there is text.

Credential access is absent. There are no secret findings of any kind: nothing reads .env files, .ssh keys, .git/config or cloud credential stores, and nothing touches VS Code secret storage. No network endpoints were extracted, no IP or domain indicators were extracted, and no malware signature matched. The dependency entries, [email protected], underscore@^1.13.8 and serialize-javascript@^7.0.5, are ordinary packages for a VS Code language client.

Filesystem and process access here is the job, not a deviation from it. A language server has to read the workspace to type check it and has to run a Python process to do the analysis. The extension publishes under Meta, ships version 1.3.9002 to roughly 86,000 users on the VS Code marketplace, and its name is not a clone of a more popular package.

The strongest counterargument is that dist/extension.js genuinely does contain shell interpreter usage, so the capability exists and a future version could point that capability somewhere it should not go. Capability is not intent. Almost every language extension on the marketplace spawns processes, and the rules that fired belong to the generic postinstall family that the scanner applies to any Node.js bundle. Nothing in this scan shows code reaching outside the workspace, contacting an unknown host, or collecting credentials.

Key Reasons

• All 12 code-smell matches are low-severity generic postinstall_* YARA rules hitting dist/extension.js, package.json and resources/find_pyrefly.py, which is bundled build output and language server bootstrap code
• YARA--postinstall_network_communication matching extension/LICENSE.txt shows the rule family is matching plain text, not behaviour
• Zero secret findings: no .env, .ssh, .git/config or credential store access, and no VS Code secret storage use
• Zero network endpoints, zero IoC, zero obfuscation and zero malware signatures across 18 findings
• Official Meta publisher, ~86,000 installs, non-typosquatting name, standard dependencies ([email protected])

False Positive Considerations

• Generic postinstall_* YARA rules matching any bundled Node.js code that spawns processes
• YARA rule firing on LICENSE.txt text as postinstall_network_communication
• Code-smell findings in minified dist/extension.js webpack output
• Dependency enumeration of standard packages labeled as low-severity findings

Reviewed 2026-10-01; recommended action: suppress false positive; model confidence 90%.