windows-control

SUSPICIOUS: the skill’s capabilities match a Windows control harness, but its footprint is extremely powerful and the install provenance is not verifiable from the provided evidence. No confirmed malware or credential harvesting is shown, yet the combination of mutable local install plus broad UI/file/shell control makes this a high-risk skill to trust without strong publisher verification and explicit per-action approval.

The fragment is an automation CLI/REPL launcher with broad delegated Windows control capabilities. The primary security concerns are the developer-specific sys.path override, dynamic generated-script execution, stderr suppression, and delegation of arbitrary system/file operations to code not provided. There is no direct evidence of malware, credential theft, network exfiltration, or persistence in this fragment. The apparent syntax corruption should be resolved before execution and the imported action implementations should be audited separately.

The fragment is a privileged system-control module rather than covert malware. It provides unrestricted command execution, arbitrary filesystem modification/deletion, environment-variable access, and host reconnaissance to whatever component can invoke these actions. In an untrusted or remotely accessible action framework, this represents a critical authorization and sandboxing risk and can enable command execution, credential theft, data destruction, or persistence through caller-supplied commands. The fragment itself contains no evident automatic exfiltration, persistence, obfuscation, or malicious payload. WriteFileAction also has a non-malicious append-mode implementation bug.

The code is a legitimate browser automation module and contains no clear malware or supply-chain payload. It has meaningful security risks if its actions are exposed to untrusted users: unrestricted URL fetching can enable SSRF, arbitrary JavaScript execution can control the browser page, and persistent shared browser state can expose cookies or authenticated content across tasks. Apply URL allowlisting and private-network blocking, isolate browser contexts per user/task, restrict or remove JavaScript execution, and treat returned page data and screenshots as sensitive.

No direct malware indicators or data-exfiltration behavior are present. The principal security risk is deliberate dynamic execution of Python files and module-defined functions/classes from caller-supplied paths. This is expected for a trusted plugin system but is unsafe if skill directories or module paths can be controlled by untrusted users or package contents. YAML and SKILL.md handling is comparatively safe because yaml.safe_load is used and configuration values are not dynamically evaluated.

The code is a transparent Windows desktop-control CLI. It contains high-impact capabilities for arbitrary command execution, filesystem access, screenshots, and input simulation, so it should not be exposed to untrusted users without authorization and validation. The hardcoded sys.path override is a supply-chain/import-hijacking concern if the referenced directory is attacker-controlled. No direct malware indicators, network exfiltration, credential theft, persistence, or obfuscated payload are present in the supplied fragment. Assessment of path traversal and command safety requires the implementations of the imported action classes.

The code implements a legitimate Windows application launcher and contains no clear malware or exfiltration behavior. However, it has a significant command-injection vulnerability because app_name and search_keyword are interpolated into multiple PowerShell commands without escaping or strict validation. Inputs should be constrained to safe application identifiers, PowerShell arguments should be passed as parameters rather than string-built commands, and discovered paths should be validated before execution.

The code is a Windows automation/action module with an intentional capability to execute arbitrary cmd and PowerShell commands and inspect processes. This is highly dangerous when action parameters can be influenced by untrusted users or external data. The process-name interpolation also creates a likely PowerShell injection issue. No direct evidence of malware, data theft, persistence, or network exfiltration is present in this fragment, but deployment should restrict commands, avoid shell=True, validate shell and parameters, and safely escape or avoid dynamic PowerShell construction.

The supplied material is a README describing a powerful Windows automation tool, not executable code. It exposes potentially dangerous capabilities such as arbitrary shell commands, filesystem writes, and full UI control, so deployment should require strong authorization and isolation. No malicious behavior, credential theft, network exfiltration, persistence, or obfuscation is evidenced in the provided fragment. Assessment of the referenced jingmai-agent backend requires its source code.