OpenVSX Registry Verified

Abbenay Provider

by redhat
6eb6f872-a609-5801-a731-d6e10e6c6611 | v2026.8.8
65/ 100
MEDIUM risk
+21 since v2026.8.7
Analyst verdict
Review before use

The AI review rates the findings as likely false positive, but the risk score (65/100) still counts them.

Analysis record

Analysed
5 days ago
Version
v2026.8.8
Artifact
SHA256 052…0B8
Source
Findings (non-IoC)

Is Abbenay Provider safe?

This is Red Hat's AI chat extension for VS Code, published on OpenVSX as abbenay-provider. It lets you point the editor at whichever model you prefer, OpenAI, Anthropic, Google or a local Ollama server, and streams the answers into a chat panel. It declares no special permissions, and the network side matches that job: the code in extension/out/extension.js makes outbound requests, and the bundled chat UI in extension/out/webview-ui/chat/main.js carries a socket.io client for streaming replies. The endpoint list also holds amazonaws.com and a long tail of odd strings such as a27.google, address.host and accordion-section.open, which are fragments the scanner pulled out of minified JavaScript rather than real destinations.

The two flags worth explaining are extension/bin/keytar.node, tagged as an obfuscated native binary, and OBFUSCATION-FROMCHARCODE_BULK in extension/out/extension.js. keytar is the standard open source module extension authors use to put your provider API key in the operating system keychain instead of a plain settings file; it compiles to a binary, so a scanner cannot read it and marks it suspicious. The second flag comes from the extension being minified for shipping, which is how published extensions look.

Your API key does get stored, and the extension reads it back to call the provider you configured, which is the point of the tool. Nothing here reads .env files, SSH keys or cloud credentials, no malware signatures turned up, and there is no install-time download or shell command. The scanner tripped on compiled binary bytes and minified source, which is about how this extension is built, not what it does.

Evidence ledger

Ranked by severity · findings with a source location link to the code viewer

3 detail rows

Publisher Evidence

Low

redhat

Publisher identity, store signals, distribution reach, and warning signals used for context. Treat this as supporting evidence, not a clean bill of health.

65
Noisy-finding weight
x1.00
Publisher domain
No domain
Missing
Store verification signal
Verified publisher
Verified
Extension portfolio
44
Portfolio

12 evidence rows available.

Finding Categories

3
Network

AI Security Report

AI Security Review

Evidence context: threat category none; evidence quality moderate.

abbenay-provider is Red Hat's bring-your-own-model AI assistant for VS Code, mirrored on OpenVSX with roughly 5,800 users. Its job is to send editor context to a model provider and stream the answer into a chat panel, so outbound HTTP and a bundled chat UI are the product rather than a side effect. The three network findings land in exactly the files that job requires: NET-FETCH-extension/out/extension.js-8 in the extension entry point, and two NET-SOCKET_IO hits in extension/out/webview-ui/chat/main.js, the webview that renders the conversation.

Nothing here shows a postinstall or activation-time payload. There are no malware signatures, no tool-poisoning hits, and no secret-access findings, so no .env file, .git/config, .ssh directory or cloud credential store is being read. The 1,393 IoC entries are extractor noise; the endpoint list they generated holds obvious fragments from minified JavaScript such as a27.google, address.host, accordion-section.open and anthropic.computer, sitting next to generic infrastructure like amazonaws.com. A string shaped like a property access chain or a CSS selector is not a destination the extension contacts.

The two obfuscation findings are build artifacts. OBFUSCATION-NATIVE_BINARY_ADDON-extension/bin/keytar.node is a compiled Node addon, and keytar is the standard open source package authors use to keep API keys in the operating system keychain instead of a settings file. A scanner cannot read compiled bytes, so it labels the binary itself as obfuscation; the finding describes the file format, not hidden behavior. OBFUSCATION-FROMCHARCODE_BULK-extension/out/extension.js-5 comes from the bundled, minified output in out/, which is how extensions ship after a webpack or esbuild pass.

Filesystem and process access matches this class of tool and goes no further. The manifest declares no permissions and no host permissions. Reading workspace files to build model context, and storing and reading back the user's own provider API key through keytar, are the only capabilities that matter, and both are the stated function of a Copilot alternative. The 68 code-smell entries and 7 dependency entries are the usual bundled-library background.

The strongest argument against this verdict is that keytar.node is unreadable native code: if someone had tampered with that binary, a source-level review would miss it. That argument would carry weight if the extension came from an unknown publisher with a thin listing, but this is a Red Hat release with a matching store page and an active user base, the bundled keytar path matches the official npm module, and nothing else in the package shells out, downloads code at install time, or reaches for credentials beyond the keychain. The open question sits in a well known dependency, not in the extension's own logic.

Key Reasons

  • Network findings are the extension's stated function: NET-FETCH-extension/out/extension.js-8 and two NET-SOCKET_IO hits in extension/out/webview-ui/chat/main.js serve the LLM chat client.
  • OBFUSCATION-NATIVE_BINARY_ADDON-extension/bin/keytar.node is the standard npm keychain module shipped as compiled code, which scanners cannot read and flag by default.
  • OBFUSCATION-FROMCHARCODE_BULK-extension/out/extension.js-5 is webpack/esbuild output, not intentional hiding.
  • No malware signatures, no secret-access findings, no tool-poisoning hits, and no postinstall or activation-time execution.
  • The 1,393 IoC entries include property-chain and CSS-selector fragments such as address.host and accordion-section.open, which are extraction noise.

False Positive Considerations

  • IoC extractor fragments misread as domains (a27.google, address.host, accordion-section.open) from minified webview JavaScript
  • keytar.node native binary addon flagged as obfuscation, describing file format rather than behavior
  • FROMCHARCODE_BULK match on minified extension/out/extension.js build output
  • Code-smell and dependency counts inflated by hundreds of bundled libraries in out/

Reviewed 2026-09-29; recommended action: no action; model confidence 85%.

Open VSX version history

Risk trend by version

5 analyzed versions. Each point is the latest successful scan for that version; failed zero-score scans are hidden. Dates are based on first seen by risky plugins.

Selected
65
Change since first
+34
Change from previous
+21
Versions:
First analyzed version
2026.6.4
Jun 19, 2026
Risk range
31 to 65
Across analyzed versions
Latest analyzed version
2026.8.8
Sep 5, 2026
Selected version
medium
Version
v2026.8.8
3 weeks ago
Risk score
65
Findings
1473
Change vs previous
+21

Pick any point on the chart to explore that version's code below.

About This Extension

Use any LLM with any VS Code extension - OpenAI, Anthropic, Google, Ollama & more. The open alternative to Copilot.

Frequently Asked Questions