README Diagrams - Mermaid and Structurizr Preview

AI Security Review

Evidence context: threat category none; evidence quality moderate.

This plugin renders Mermaid and Structurizr diagrams found in project README files, inside the JetBrains IDE. Publisher jakub-jirak, 259 users, version 2026.1.1. The job is to read markdown that already sits in the open project and draw it in a preview pane, which is the same file access any linter or formatter takes. Nothing in this scan goes further than that. The declared permissions list is empty, the host permissions list is empty, and no manifest-analysis result was produced at all. There is no postinstall step, no shell or child-process execution finding, no obfuscation finding, no dependency finding and no tool-poisoning finding.

Most of what the scan returns is one artifact of the extraction step. Seventeen entries are domain indicators from the XIOC extractor, every one of them filed under the synthetic path extracted_from_files. XIOC-DOMAIN-pom.properties is a Maven build file that ships inside a packaged plugin JAR, not a hostname. XIOC-DOMAIN-q7ɖ.lv, XIOC-DOMAIN-ߩ.st, XIOC-DOMAIN-u.sv, XIOC-DOMAIN-wrx.gf, XIOC-DOMAIN-zj.kh and their neighbors are two-letter TLD fragments with stray Unicode characters attached, the shape you get when a parser splits compiled output on dots. The endpoint list repeats those same strings, so it carries no new information. Not one network finding accompanies them, and a plugin that actually called a remote host would produce one.

Credential access is missing rather than benign. No secret finding appears, so there is no read of .env, no .git/config, no SSH key path, no cloud credential file and no use of the IDE's credential storage. The four remaining entries are low-severity code-smell matches, the category where broad rules fire on bundled build output and on ordinary references to environment variables or crypto APIs. None of them carries high or critical severity, and none names a file that a README previewer would have any reason to open.

The strongest argument against calling this clean is that no manifest analysis ran, so the plugin's declared permissions are unverified, and a previewer that resolves remote image links in a README could in principle reach out to a URL. Two things push back on that. Zero malware signatures matched anywhere in the archive, and a plugin fetching remote images would have produced a network finding, which it did not. The plugin name is distinctive and the publisher matches the author, so this is not a lookalike of a popular package. What remains is a small diagram tool plus a scanner that reads dotted strings as web addresses.

Key Reasons

• All seventeen domain indicators come from the XIOC extractor under extracted_from_files, including pom.properties (a Maven build file) and two-letter TLD fragments with stray Unicode characters
• Zero malware signatures, zero network findings, zero obfuscation findings and zero secret findings across the archive
• No postinstall or child-process execution finding, and the permissions and host permissions lists are both empty
• Four low-severity code-smell matches, the noisiest rule category, with no high or critical severity anywhere
• Distinctive plugin name with the publisher matching the author, so no typosquat pattern

False Positive Considerations

• XIOC domain extractor splitting compiled code and JAR contents on dots
• Maven build metadata (pom.properties) misread as a hostname
• Two-letter TLD fragments carrying stray Unicode characters
• Generic low-severity code-smell rules firing on bundled build output

Reviewed 2026-10-01; recommended action: suppress false positive; model confidence 88%.