OrbitNote

AI Security Review

Evidence context: threat category none; evidence quality moderate.

OrbitNote is a document annotation tool for schools, and the file layout matches that job: content-scripts/schoology/texthelpschoology.js wires the extension into the Schoology learning platform, filePicker/bundle.js handles choosing files to open, and background/bundle.js runs the service worker. The developer field came back empty, which limits a publisher check, but the name, the version 7.0.5 and the Schoology integration point to a specific commercial education product rather than a name-alike. The extracted manifest lists no permissions, no host permissions and no network endpoints, so nothing here shows which domains the extension is allowed to reach. Read that as an extraction gap.

Only one finding carries a malware signature: YARA--supply_chain_sourcemap_appended_iife at schoologyOpen/bundle.js:28568. The rule name describes what it matches, an immediately-invoked function expression with a sourcemap appended after it. Webpack, esbuild and rollup all emit that shape when a build leaves its map in place. It fired on this file because this file is build output.

The network findings are the same story at higher volume. All 58 are NET-XMLHTTPREQUEST or NET-AXIOS entries inside filePicker/bundle.js and content-scripts/schoology/texthelpschoology.js. Those titles name the HTTP client being used, XHR or axios, not a destination. A document tool that opens files from a cloud drive or a class portal has to make requests, and a bundled front end centralizes them in a few files. With the endpoint list empty, the titles tell us the code talks to a server, which is expected, and nothing about where.

The obfuscation hit deserves a second look. OBFUSCATION-invisible_unicode_payload sits at background/bundle.js:0, the head of the service worker bundle. Zero-width characters are legitimate in locale files for several writing systems, but this one is not in a locale file, so that exemption does not apply cleanly. What weakens it as a signal: it is a single match at offset zero in a minified bundle, the rest of the shipped code is readable and lines up with the product, and invisible characters at the start of generated output usually come from a build tool or a copied snippet. Resolving it would mean decoding the character and checking what precedes and follows it in the unminified source.

The strongest counterargument is that we are explaining away two high-severity findings with "it's a bundle". That deserves a straight answer. The YARA rule names the artifact it detects, and the network findings name the client library, not a host. There are no IoCs, no secrets, no code-smell matches and no dependency findings. A payload hidden in build output still has to point somewhere, and nothing here points anywhere.

Key Reasons

• The only malware signature, YARA--supply_chain_sourcemap_appended_iife at schoologyOpen/bundle.js:28568, matches an appended sourcemap, a standard webpack/rollup build output shape.
• All 58 network findings are NET-XMLHTTPREQUEST or NET-AXIOS call sites in filePicker/bundle.js and content-scripts/schoology/texthelpschoology.js, naming HTTP client APIs rather than suspicious destinations.
• No IoCs, secrets, code-smell matches or dependency findings were reported.
• The file layout (Schoology content script, file picker, service worker bundle) is consistent with the stated document-annotation product.
• The single OBFUSCATION-invisible_unicode_payload at background/bundle.js:0 is the only signal that could justify follow-up.

False Positive Considerations

• Appended sourcemap IIFE detected by a broad supply_chain YARA rule on build output
• XHR/axios call sites in bundled JavaScript counted as network findings
• Invisible unicode character inside a minified bundle rather than a locale file
• High finding count concentrated in dist-style bundle files

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