Migration Toolkit for Runtimes (MTR) by Red Hat

AI Security Review

Evidence context: threat category none; evidence quality strong.

Red Hat's Migration Toolkit for Runtimes inspects a Java project and reports what has to change for a move to a newer JDK or runtime. That purpose sets the baseline: the plugin reads source, bytecode and build files across the workspace, which is what a migration analyzer does. No manifest-analysis findings appear in this data, so nothing here contradicts the plugin's own description of its scope.

The process work a migration engine needs does not show up as a finding either. What does show up is seven network findings, all inside org.jboss.tools.intellij.mtr/lib/webroot/configuration-editor/lib/configurationFrontendClient.js at lines 17, 28, 39, 50, 63, 76 and 89. Each is tagged NET-JQUERY_AJAX. That file is the front end of the plugin's configuration editor, a webview that loads its settings from the local plugin process. Seven ajax calls scattered through one UI script is how a settings panel populates itself.

Credential access is absent. The secret category holds nothing, and no finding names .env, .ssh, .git/config or a cloud credential file. The broad credential rules that fire on any code touching an API key did not fire here at all, which matters because those rules are noisy and their silence on this extension is meaningful.

The 136 IoC entries are the strongest reason to distrust the raw counts. The endpoint list contains "allof.java", "anyof.java", "arrayiterator.java", "basematcher.java", "corematchers.java" and "describedas.java", which are Java class names from Hamcrest and from the plugin's own model layer, plus "commonmessages.properties", a resource bundle filename. The extractor pulled identifier strings out of bundled files and recorded them as hostnames. The rest are short fragments such as "ci.vu", "eb.gr" and "ak.af", two-letter substrings with no server behind them. Not one entry resolves to a real host.

The 82 code-smell findings carry low severity and match ordinary bundled JavaScript. Malware signature, malware, obfuscation and tool-poisoning counts are all zero.

The counterargument is sheer volume. 299 findings on a plugin that reads your entire project sounds like a problem, and a tool with that access could do damage. But the volume comes from bundled web assets and an extractor that reads Java class names as domains. A real exfiltration setup would leave a hostname somewhere, an upload call outside the webview, or a credential read. None of those is present.

Key Reasons

• The only network findings are seven NET-JQUERY_AJAX hits in the plugin's own configuration webview client, configurationFrontendClient.js lines 17-89, which is ordinary UI-to-backend traffic.
• The endpoint list consists of Java class names (arrayiterator.java, basematcher.java, corematchers.java) and a resource bundle filename (commonmessages.properties), showing the IoC extractor was reading identifiers, not hosts.
• Zero findings in the secret category, and no finding references .env, .ssh, .git/config or cloud credential files.
• Zero malware, malware-signature, obfuscation and tool-poisoning findings; all 82 code-smell hits are low severity against bundled JavaScript.
• Published by Red Hat on the JetBrains marketplace with roughly 1,000 users, matching the stated migration tooling purpose.

False Positive Considerations

• IoC extractor recording Java class names and .properties filenames as network endpoints
• NET-JQUERY_AJAX rules firing on a webview settings client bundled under lib/webroot
• High-severity scoring driven by IoC volume and code-smell counts rather than real behavior
• Generic code-smell rules matching bundled/minified web assets

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