Workflow Rule Manager

AI Security Review

Evidence context: threat category none; evidence quality moderate.

Workflow Rule Manager is a JetBrains Marketplace plugin published by JetBrains, version 0.0.6, with 300 reported users. It declares no permissions and no host permissions, and the plugin metadata lists no network endpoints and no hardcoded domains anywhere in the package. What the package does contain is a webview panel under widgets/.

The scan returned four medium-severity network matches, all inside one bundled webview asset, widgets/assets/widget-PzqQ8OgQ.js. Three are socket.io client references (NET-SOCKET_IO-widgets/assets/widget-PzqQ8OgQ.js-37, -38 and -40) and one is a fetch call (NET-FETCH-widgets/assets/widget-PzqQ8OgQ.js-1). A JetBrains plugin that renders a rule interface in an embedded browser typically opens a socket to a server the IDE process runs on localhost, and socket.io is a common library for that channel. The file is minified build output, not hand-written payload code.

Nothing here reads the filesystem in a way that needs justifying. There are no process-spawn findings, no file-read findings and no secret-category findings. The specific targets credential theft would need, such as .env files, SSH keys, .git/config or cloud token files, do not appear anywhere in the results. The twelve low-severity code-smell matches are the standard yield from scanning minified JavaScript: rules in the postinstall_* and credential_* families fire on any Node bundle that mentions fetch, exec, fs or process.env, and they carry no behaviour of their own. The seven info-level items are metadata.

The strongest counterargument is that this is a 0.0.x plugin with a small install base, from a publisher name that is trivial to imitate, shipping a webview that opens a socket. If that socket reached a remote host, a rule manager with workspace visibility could stream project data outward. The counterargument does not survive the evidence: no endpoint, host or address is recorded, the socket.io strings sit in the same bundled asset as an ordinary fetch call, and the scanner logged no IoC hits and no obfuscation findings. A socket.io import with no destination attached is a library reference.

What would change the picture is a network endpoint entry naming a non-JetBrains host, a secret-category finding, or a manifest permission request. None is present. Static inspection cannot see a URL assembled at runtime from configuration, so a runtime check of the webview's outbound connections is the only way to close that gap completely.

Key Reasons

• The only medium-severity findings are a fetch call and socket.io client references inside the minified webview asset widgets/assets/widget-PzqQ8OgQ.js, which matches a webview panel talking to a local IDE backend.
• No secret-category findings exist: nothing in the package reads .env, .ssh, .git/config or cloud credential files.
• No IoC hits, no obfuscation findings, no hardcoded domains and no declared network endpoints accompany the network matches.
• The plugin is published by JetBrains on the JetBrains Marketplace at version 0.0.6, an official first-party listing rather than a re-upload.
• The twelve low-severity code-smell matches are the expected output of scanning minified JavaScript and carry no behavioural detail.

False Positive Considerations

• Minified webview bundle widgets/assets/widget-PzqQ8OgQ.js trips network rules on bundled library names rather than on behaviour.
• Low-severity code-smell rules match generic Node patterns such as fetch, exec, fs and process.env in any compressed bundle.
• High finding counts in widgets/ assets are multiplicative noise from bundled dependencies, not independent signals.

Reviewed 2026-09-29; recommended action: suppress false positive; model confidence 82%.