Kubernetes by Red Hat

AI Security Review

Evidence context: threat category none; evidence quality moderate.

Kubernetes by Red Hat version 1.7.0.11 is a JetBrains Marketplace plugin published by Red Hat with roughly 104,000 installs. Its stated job is to talk to Kubernetes clusters from inside the IDE: browsing workloads, editing manifests, applying them. A tool like that needs to read workspace files and drive cluster tooling. Nothing in the scan contradicts that picture.

Every one of the 499 domain findings carries the file path extracted_from_files, meaning the extractor could not tie a single one to a line of code. Look at what it captured: XIOC-DOMAIN-1kb5.pub, XIOC-DOMAIN-e2i.mw, XIOC-DOMAIN-x7.ie, XIOC-DOMAIN-φ.pk, XIOC-DOMAIN-ߵ.mt. These are two-label fragments, several containing characters (φ, ϭ, ߵ, ߒ) that cannot appear in a registered hostname. The same strings appear in the network endpoint list as 0s.bv, 2k.bz, 9ϒ0.tw. They are substrings lifted out of minified JavaScript, where ordinary property chains and byte sequences look domain-shaped to a regex. A plugin that genuinely phoned home to a rotating roster of throwaway two-letter TLDs would need request-building logic somewhere. The scan shows zero network findings, zero malware signatures and zero obfuscation findings.

On filesystem and process access: this bundle carries no declared permission strings and no manifest-analysis findings, so nothing shows scope beyond the plugin's purpose. A Kubernetes client legitimately reads YAML manifests in the open workspace and reads ~/.kube/config, and it shells out to cluster tooling. Reading and writing workspace files is what the plugin is for.

On credentials: there are no credential-access findings at all. Nothing targets .env, .ssh, .git/config, cloud credential files or IDE secret storage. The 170 low-severity items are code-smell rule matches, the class of YARA rule that fires on any non-trivial JavaScript because it greps for fetch, exec, fs and process.env as bare strings. Nothing pairs a credential read with a network write.

The strongest argument against this verdict is volume: 758 findings, 499 of them medium, inside a plugin with cluster-level reach. The number of hits reflects how the scanner works, not what the plugin does. Every medium finding is a scanner-extracted domain string with no source location and no accompanying code, and the name, publisher, install base and version string match a first-party Red Hat product rather than a lookalike listing.

Key Reasons

• All 499 medium-severity domain hits are labelled extracted_from_files, with no source location and no accompanying request-building code
• The flagged domains include impossible hostnames such as XIOC-DOMAIN-φ.pk and XIOC-DOMAIN-ߵ.mt, which match on minified JavaScript fragments rather than real endpoints
• Zero malware-signature, network, obfuscation, secret and tool-poisoning findings across 758 total items
• No credential-access findings targeting .env, .ssh, .git/config or IDE secret storage
• Publisher Red Hat, 103,951 installs and version 1.7.0.11 match a first-party JetBrains Marketplace listing, not a typosquat

False Positive Considerations

• XIOC domain extraction matching short non-ASCII substrings inside bundled/minified JavaScript
• Code-smell YARA rules (170 low-severity matches) firing on generic Node.js patterns like fetch, exec, fs and process.env
• Finding-count inflation from bundled dependencies, where hundreds of library files each yield extractor hits
• Security scanners' default weighting of IoC volume over IoC plausibility

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