JTools HTTP Client

AI Security Review

Evidence context: threat category none; evidence quality moderate.

JTools HTTP Client is a JetBrains IDE plugin, version 0.0.5, installed by around 110 people, that sends HTTP requests from inside the editor. Network traffic is the product, so the relevant question is whether anything in the scan shows it doing more than sending requests on your behalf.

The biggest group of hits are network indicators pulled out of bundled files under the title pattern XIOC-DOMAIN-*. Examples include XIOC-DOMAIN-n.lu, XIOC-DOMAIN-g.lb, XIOC-DOMAIN-0x.jp, XIOC-DOMAIN-zu.ke, XIOC-DOMAIN-ĵ.al and XIOC-DOMAIN-nϙe.uz. As a set they don't behave like a server list. Two of the entries, anchor.properties and functions.properties, are Java property lookups rather than hostnames, and the ones carrying non-Latin characters can't be resolved as written. Short two-label strings such as n.bw, z.nr, ea.cr and fo.gq read as tokens the extractor cut out of minified or bundled code on the dot, not as destinations anyone contacts. All 239 share the same shape and the same medium severity.

Credential access is where a plugin like this usually gets caught, and there is nothing there. No secret findings, no reads of .env, .git/config or SSH key material, no calls into IDE credential storage. The permissions and host permissions lists are both empty, so nothing in the manifest asks for filesystem or process capability. Malware signatures, tool-poisoning checks and obfuscation detectors all report zero. An HTTP client running inside the editor process and spawning request threads is the job description, and no finding here pairs file reads with outbound sends.

The 32 low-severity code-smell hits are the rules that fire on any JavaScript touching fetch, exec, crypto or process.env. The manifest-analysis category is empty, so there is no evidence of the plugin editing IDE configuration or touching other plugins.

The strongest argument against calling this clean is the publisher: the developer name is a bare UUID, the plugin has no description, one release and a small user base. New and unattributed plugins in a smaller marketplace do warrant a look. That argument stops at the address list, though. If those domains were real command infrastructure, the picture would change; instead they fail as hostnames, and the two most legible entries are property names. A thin track record with no supporting code finding is cause to watch the project. The scan found no malicious code. Nothing here reads source and ships it out, runs at install time, or touches credentials.

Key Reasons

• All 239 network indicators are medium-severity XIOC domain extractions from bundled files; several contain characters that cannot exist in a hostname (XIOC-DOMAIN-ν.jo, XIOC-DOMAIN-nϙe.uz, XIOC-DOMAIN-ĵ.al) and two are property names (anchor.properties, functions.properties).
• Zero findings in the secret, malware-signature, obfuscation, tool-poisoning, dependency and manifest-analysis categories.
• No permission or host permission strings are declared, and an HTTP client plugin issuing network requests matches its stated purpose.
• The 32 code-smell hits are the low-severity generic rules that match any JavaScript using fetch, exec, crypto or process.env.

False Positive Considerations

• XIOC extractor tokenising bundled code into fake two-label domains such as n.lu, g.lb and 0x.jp
• Java property-access chains (anchor.properties, functions.properties) misread as network domains
• Code-smell rules matching generic fetch/exec/process.env patterns in extension code
• Non-ASCII fragments from bundled files misread as internationalised hostnames

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