JetBrains AI Assistant

AI Security Review

Evidence context: threat category none; evidence quality moderate.

JetBrains AI Assistant is published by JetBrains itself (version 262.10968.135, roughly 217 million installs). Its job is to read project files, send relevant context to JetBrains' AI service, and write generated code back. Reading and writing workspace files and calling a remote model is the product, so filesystem access and outbound network traffic are expected for this class of plugin.

String extraction artifacts, not code behavior, account for almost everything recorded. The domain hits include XIOC-DOMAIN-jcasupport.java, XIOC-DOMAIN-config.java, and XIOC-DOMAIN-userauthenticationrequired.java under extracted_from_files. Those are Java class names. A regex hunting for word.word pulled identifiers out of compiled JAR resources and logged them as hostnames. None of the three is a host the plugin could contact, and no network finding accompanies them.

The endpoint list repeats the same mistake. 0llm.error.out.of.prompts.pro.contact.support and 0authenticatedextendedcardnotconfigurederror.java are user-facing error strings, not addresses. A large block of the remainder, miyoshi.saitama.jp, nanmoku.gunma.jp, askvoll.no, 123hjemmeside.dk, 123minsida.se, 123kotisivu.fi, reads like a bundled public suffix or domain list of the sort URL-parsing libraries ship. [email protected] is an address sitting in a string table, not a configured contact.

Two entries name real infrastructure: s3-accesspoint.us-east-1.amazonaws.com and hosting.ovh.net. Neither is tied to any file-read finding, and the plugin declares no permissions, so there is no path connecting workspace reads to uploads at an unusual destination. An AWS access point hostname inside a bundled dependency's domain data is mundane.

On credential access, the scan recorded zero secret findings, zero obfuscation, and zero malware signatures. Nothing touches .env, .ssh, .git/config, or cloud credential files. The 466 code-smell hits are the low-severity pattern matches (process spawn, fs, fetch, env references) that fire on any codebase of this size; they carry no behavioral weight.

The strongest argument against this reading is volume. Fifteen thousand medium findings plus an AWS hostname would be alarming if the entries were genuine. They are not. Every medium IoC we can resolve is either a Java identifier, a localized error message, or a domain-list entry, and the vendor is the publisher on its own marketplace. An official JetBrains plugin bundling a suffix list is unremarkable; a hostile one would have no need for one.

Key Reasons

• Official JetBrains plugin from the publisher's own marketplace (version 262.10968.135, ~217M installs)
• Every resolvable medium IoC is a Java class name, a resource-bundle string, or a domain-list entry, not a contactable host
• Zero malware signatures, zero secret findings, zero obfuscation, zero tool-poisoning findings
• No permission declarations; file and network access match the stated function of an AI coding assistant
• 466 code-smell hits are low-severity pattern matches expected on a large JVM codebase

False Positive Considerations

• Domain regex matching Java identifiers such as jcasupport.java, config.java and userauthenticationrequired.java as IoCs
• Resource-bundle and exception strings (0llm.error.out.of.prompts.pro.contact.support) harvested as network endpoints
• Bundled public-suffix/domain lists (miyoshi.saitama.jp, 123hjemmeside.dk, askvoll.no) counted as exfiltration targets
• 466 low-severity code-smell matches on a large plugin codebase inflating the medium/low tallies

Reviewed 2026-09-30; recommended action: suppress false positive; model confidence 90%.