JavaSith: A Client-Side Framework for Analyzing Potentially Malicious Extensions in Browsers, VS Code, and NPM Packages

Avihay Cohen

REVIEW 5 major objections 5 minor 2 cited by

JavaSith: A Client-Side Framework for Analyzing Potentially Malicious Extensions in Browsers, VS Code, and NPM Packages

T0 review · 5 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A client-side sandbox with a time machine catches malicious browser, VS Code, and npm code that official store scans miss, as shown on the Cyberhaven compromise and cryptominer extensions.

desk verdict A credible prototype with a new synthesis, but the evaluation is circular and the central detection claim is not supported by the evidence. read the letter →

arxiv 2505.21263 v1 pith:MYZYSLIU submitted 2025-05-27 cs.CR

Avihay Cohen This is my paper

classification cs.CR

keywords supplychainsecuritybrowserextensionmalwareVSCodenpmpackageanalysisdynamicsandboxingtime-basedtriggerdetectionclient-sideLLM

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper sets out to show that a single client-side tool can uncover malicious behavior in browser extensions, VS Code extensions, and npm packages even when that behavior is deliberately delayed or disguised, and that such a tool would have caught real attacks that passed official store checks. JavaSith executes the target code in an emulated runtime, fast-forwards timers and simulated dates to force dormant payloads to fire, and combines static pattern detection with a local language model that writes a plain-language risk assessment. The supporting case studies reproduce the Cyberhaven Chrome extension supply-chain compromise and VS Code extensions that install cryptominers, and the paper argues JavaSith would have flagged each as soon as it was analyzed. The stakes are concrete: supply-chain attacks through extensions have risen sharply, and current store-level vetting demonstrably misses them.

What carries the argument

The load-bearing mechanism is the emulated runtime sandbox: an isolated JavaScript compartment in which JavaSith installs stubs for the Chrome extension API, a mock VS Code extension host, and hooked Node built-ins, so that extension code executes normally while every interesting action is logged or blocked. Attached to the sandbox is the Time Machine, which intercepts setTimeout, setInterval, and Date reads and fast-forwards scheduled tasks, making time-delayed or date-gated logic fire on demand. Around this core sit a static analysis pipeline that scans for suspicious patterns and known vulnerable libraries, and an on-device language model that converts the collected evidence into a plain-language risk report. The sandbox is what makes the dynamic claims possible, and the time machine is what makes stealthy delayed payloads observable.

What would settle it

Take a set of known malicious extensions whose payloads fire only through APIs or page interactions the sandbox does not implement (for example, a real page's DOM state or a less-common Chrome API), run them in JavaSith and in a genuine Chrome or VS Code host, and compare detections; if any sample executes its malicious logic only in the real host while JavaSith reports no high-severity finding, the claim that the tool catches stealthy behavior collapses for that class.

Watch

Extended reading notes

Core claim

The central claim is that extension and package code can be vetted safely on the user's own machine by emulating the host environment rather than by signature matching. For browser extensions the sandbox stubs the Chrome API and simulates page navigations to sensitive sites; for VS Code it provides a mock extension host; for npm it runs install and post-install scripts in an isolated Node-like context. Every API call, network request, file operation, and process spawn is logged or redirected, and the Time Machine accelerates timers and overrides the clock so that payloads gated on dates or delays execute during the analysis window. Static analysis then flags obfuscation, hardcoded webhook URLs, dangerous API use, and known vulnerable libraries, while the on-device LLM synthesizes code, metadata, and privacy policy into a risk judgment. The paper claims this combination would have caught the Cyberhaven malicious update as soon as it was analyzed and would have exposed the VS Code cryptominer's PowerShell download and hidden miner installation.

Load-bearing premise

The framework's accuracy rests on the fidelity of its emulated runtimes: the stubbed Chrome and VS Code APIs and simulated events must make real malicious code behave exactly as it would in a genuine host, and the paper concedes the browser simulation is not a full Chrome browser and covers only APIs seen in past attacks.

Editorial extensions

If this is right

An organization that runs JavaSith on extension updates before deployment would have flagged the Cyberhaven-style malicious update at analysis time, not after days of data exfiltration.
Delayed and date-gated payloads stop being a reliable evasion strategy, because the time machine forces scheduled callbacks to execute during the scan.
Client-side execution means proprietary or sensitive extension code can be vetted without uploading it to a cloud scanner, preserving privacy while still getting an LLM-generated risk narrative.
The combination of static findings, dynamic logs, and LLM reasoning can expose contradictions between a privacy policy's promises and observed behavior, such as claimed no-data-collection alongside cookie exfiltration.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Extending beyond the paper, the sandbox's per-call logs could be turned into a behavioral baseline for each vetted extension; a runtime monitor could then block any action outside that baseline, moving from pre-install vetting to continuous protection.
If emulation fidelity holds, the same architecture should transfer to other package ecosystems whose install scripts run with user privileges, since the npm sandbox already exercises exactly that class of behavior; the paper does not test this.
The time machine suggests an untried differential-testing strategy: run the same extension under many simulated dates and event sequences and treat any divergence in behavior as suspicious, on the grounds that benign code should be temporally stable.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague,

I read the JavaSith paper cover to cover. The honest one-liner: it's a well-built prototype that integrates several known techniques into one client-side tool, but the evaluation is circular and the paper's main claim—that it catches stealthy malicious behavior that evades traditional detection—is not supported by the numbers.

What's genuinely new is the combination of a browser-based SES sandbox, timer fast-forwarding, static rules, and a locally running LLM applied uniformly to Chrome extensions, VS Code extensions, and npm packages. That synthesis is not in the prior work, and the architecture is clean. The case studies are clearly written, and the tool appears to produce useful, explainable output. The paper is also upfront about its limitations, which is a plus.

The soft spot is load-bearing. The Cyberhaven case study flags cyberhavenext.pro because that domain was on a known-malicious OSINT list. The Discord webhook rule is what catches the info-stealers. The npm Unicode case is flagged by a static rule for non-printable characters. In Section 7, all 20 test samples are either taken from public threat reports or recreated from those same reports. The detectors are pre-loaded with the same indicators used to label the samples malicious. So 'no false negatives' really means 'the rule set covers the test set,' not 'the framework detects novel or obfuscated malware.' The time machine, a headline feature, is never shown to independently trigger detection: the Cyberhaven sample wasn't time-coded, and the other cases ran immediately. That's not an attack on the architecture; it's an observation that the evidence doesn't reach the claim.

The paper would be stronger with a blind evaluation: take malware samples that postdate the rule set, or at least hold out known IoCs, and compare against existing scanners like Socket.dev or CRXcavator. Releasing the tool and test set would help too. The authors seem capable of doing this.

Who's this for? Researchers and practitioners working on supply-chain extension security. The prototype is a useful demonstration, and the discussion of sandbox limitations is honest.

My recommendation: send it to peer review—it deserves referee time as a systems paper—but the reviewers should push hard on the evaluation design. If the authors can add a non-circular benchmark and a baseline comparison, this could be a solid paper. As it stands, the central claim of detecting stealthy unseen malware is unproven.

Referee Report

5 major / 5 minor

Summary. The paper presents JavaSith, a client-side framework for analyzing browser extensions, VS Code extensions, and NPM packages for malicious behavior. The system combines an emulated runtime sandbox built on SES with a time-acceleration module, static analysis heuristics, Retire.js dependency scanning, and a locally executed WebLLM-based risk analyzer, all exposed through a GUI. The authors demonstrate the framework on four case studies inspired by real incidents—the Cyberhaven Chrome extension compromise, VS Code cryptominer and information-stealer extensions, and a Unicode-obfuscated NPM package—and report a 20-sample evaluation in which all malicious samples were flagged with high severity while benign samples produced no high-severity alerts. The paper claims that JavaSith can catch stealthy malicious behaviors that evade traditional detection.

Significance. If the central claim were established, JavaSith would be a valuable client-side complement to marketplace vetting, with attractive properties: local execution for privacy, a time machine for time-triggered payloads, and a modular design separating static, dynamic, and LLM-based analysis. The paper's strengths are its concrete architecture, the use of SES for isolation, and the detailed case-study narratives. However, the current evidence does not support the claim of detecting stealthy, previously unseen malicious behavior. The evaluation is largely circular, lacks quantitative detection and false-positive metrics, and relies on an emulated runtime whose fidelity is explicitly limited. Because these points are load-bearing for the paper's central claim, the manuscript requires substantial revision before it can be accepted.

major comments (5)

[§6.1, §7.1] The evaluation is circular in a way that undermines the central detection claim. In the Cyberhaven case, the static analyzer flags the C2 domain cyberhavenext.pro 'because it was on our known-malicious list from OSINT' (§6.1). The 20-sample test set in §7.1 is composed of samples 'from public sources or recreated from descriptions'—the same public reports from which the static rules in §4.3 (Discord webhooks, uncommon domains, child_process, obfuscation) were derived. Success on this set therefore measures whether the rules cover the training corpus, not whether JavaSith detects novel malware. To support the abstract's claim of catching 'stealthy malicious behaviors that evade traditional detection,' the authors need a holdout evaluation with rules frozen before seeing the test samples, ideally using samples disclosed after the rules were written, and an explicit statement of which indicators are in the rule set versus discovered by the framework.
[§7.1] The paper reports no quantitative detection or false-positive metrics. Section 7.1 states that all 20 samples were 'flagged with high severity' and that no false negatives occurred, but it does not give a confusion matrix, a definition of the severity threshold, per-sample results, or a comparison against existing tools (e.g., CRXcavator, npm audit, Socket.dev, or a simple string-matching baseline). Without these numbers, the claim in §7.3 that JavaSith is 'effective in identifying malicious behavior' is not supported. The authors should report precision/recall (or TP/FP/FN/TN) on the 20-sample set, define how 'high severity' is determined, and include a baseline comparison.
[§5.1, §9] The central mechanism—the emulated runtime sandbox—is validated only by assertion. Section 5.1 says the authors implemented 'enough of the Chrome API surface to satisfy typical extensions' and focused on APIs 'commonly used by malicious extensions in past cases.' Section 9 concedes the browser simulation 'is not a full Chrome browser.' No experiment shows that malicious code executes its payload identically in JavaSith and in a real Chrome or VS Code host. Consequently, the claimed ability to 'coerce malicious code into revealing itself' (Conclusion) is not established. The authors should compare execution traces from JavaSith against traces from real instrumented hosts (e.g., headless Chrome with DevTools) on a set of extensions and report what fraction of behaviors were reproduced.
[§6.1, §6.4] Two of the four case studies attribute detection to modules that did not actually contribute. In the Cyberhaven case, the paper explicitly notes that 'time of year was not a coded trigger' (§6.1), so the Time Machine did not trigger detection. In the NPM case, the Unicode steganography was caught by static analysis flagging non-printable characters (§6.4), not by the sandbox. Since the paper's novelty claim includes the time machine and the handling of time-triggered or stealthy logic, the authors should provide at least one controlled sample where a time-delayed or Unicode-obfuscated payload is detected only through the corresponding module, with the static rules not already containing the C2 string. Without such a demonstration, the time machine and Unicode handling remain untested features rather than validated contributions.
[§4.4, §7] The LLM component is presented as a key contribution, but its contribution is not evaluated. Section 4.4 states the LLM's output is 'not taken as ground truth,' and §7 gives only anecdotal quotes (e.g., the Cyberhaven and VS Code miner summaries). There is no measurement of the LLM's precision, recall, or agreement with the rule-based detectors, and no ablation showing that the LLM adds value beyond the static and dynamic signals. The authors should include a quantitative or structured qualitative evaluation (e.g., LLM risk ratings against ground truth, or a user study comparing decisions with and without LLM summaries).

minor comments (5)

[§2.1] The manifest permission is written as '¡all urls¿', which should be '<all_urls>'; the encoding appears corrupted.
[Listing 1 (Section 4.2)] The constant MAXWAITMS is not defined in the text, and the comment 'Immediately (or after a shortened delay)' is ambiguous. Please specify the default threshold and whether callbacks are executed synchronously or scheduled.
[§1] Typo: 'researches/organizations' should be 'researchers/organizations'.
[References [1]–[3]] The first three references are bare URLs with no title, author, or date. If these point to the project or companion material, please cite the artifacts properly and clarify whether they are publicly available.
[§7.1] The paper states 'we did not encounter any false negatives in this set' but does not list the 20 samples or the severity per sample. An appendix table with sample names, origin (real or recreated), and findings would make the evaluation reproducible.

Circularity Check

3 steps flagged · score 6.0 of 10

Evaluation is partly circular: several 'would have caught' demonstrations fire on known indicators that were inputs to the detector, so they show rule coverage rather than detection of unseen malware.

self definitional [Section 6.1 (Cyberhaven case study)]
"The static analysis immediately flagged the presence of code accessing browser cookies and the use of an XMLHttpRequest posting data to a suspicious URL (the domain cyberhavenext.pro was on our known-malicious list from OSINT)."

The test sample was constructed from public reports of the Cyberhaven incident, and the domain that triggers the alarm was already in the tool's known-malicious OSINT list. The detection is therefore a lookup of a pre-loaded indicator, not an independent discovery. The paper's follow-on claim that 'JavaSith would have caught this malicious update as soon as it was analyzed' reduces to the fact that the sample contains an IoC already known to the tool; any sample with a listed domain is flagged by construction. This does not demonstrate catching stealthy or previously unseen behavior.
fitted input called prediction [Section 6.3 (VSCode info-stealer case study) and Section 4.3 (static rules)]
"JavaSith's static scan immediately spotted the Discord webhook URL string embedded in the code. This triggered one of our high-severity rules."

The sample is 'a simplified reimplementation of clipboard-helper-vscode (as per ReversingLabs description)', and the rule that fired was engineered around the same indicator: Section 4.3 states 'We also check for Discord webhook URLs (discord.com/api/webhooks) since, as noted, that is strongly correlated with data-stealing extensions.' The malicious label and the detector rule share the same defining string, so the positive result is forced by construction. It is a coverage test of the rule against its own source, not a prediction about an unknown sample.

1 more flagged steps

other [Section 6 (introduction) and Section 7.1]
"In each case, we either reproduced the malicious code from reports (when available) or created a lightweight approximation based on descriptions in the literature, and then ran our tool to see if it would catch the malicious behavior. ... JavaSith successfully flagged all malicious samples with high severity."

The evaluation set is assembled from the same public reports that supplied the static rules and OSINT indicators, so 'no false negatives' on this set measures whether the detectors cover their own construction inputs. The paper acknowledges the set is small and not exhaustive, but the central detection claim is supported by a self-constructed benchmark. This makes the headline result of 20/20 detection an internal consistency check rather than an independent validation against unseen or stealthy malware.

full rationale

JavaSith contains genuinely non-circular components: a runtime sandbox that logs actual network calls, file access, and process spawns, plus a time-acceleration mechanism. Those parts are not invalidated by the circularity found here. However, the paper's central claim of catching stealthy behaviors is demonstrated through case studies in which the detector fires on indicators that were inputs to the test. The Cyberhaven case is the clearest instance: the suspicious domain was already on the tool's known-malicious OSINT list, so the flag is a lookup, not a discovery. The VSCode info-stealer case similarly relies on a high-severity Discord-webhook rule defined by the same indicator used to construct the sample. The 20-sample evaluation is built from public reports and recreated approximations, so its perfect detection rate is unsurprising. These are partial, not total, circularity: the sandbox observations (e.g., a logged POST or PowerShell spawn) are independent evidence, and the framework's architecture has content beyond the rules. Score 6 reflects that one or more of the central evaluation claims reduce by construction to the paper's own inputs, while the overall framework is not entirely circular.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The central claim rests on assumptions about sandbox fidelity and rule coverage rather than on fitted parameters or new entities. The framework has no numerical free parameters except a timer threshold; its effectiveness depends on the validity of the heuristic rules and API stubs, which the paper partially acknowledges.

free parameters (1)

Timer fast-forward threshold (MAXWAITMS)
The paper sets a threshold (e.g., 1 second) beyond which timers are fast-forwarded. This is a hand-picked value that could affect which time-based behaviors are triggered.

assumptions (4)

domain assumption SES compartments provide strong enough isolation to safely run untrusted extension and package code inside a browser tab.
Invoked in Sections 4.1 and 5.1; if the sandbox can be escaped or if APIs leak into the host, the client-side safety claim fails.
domain assumption The implemented Chrome and VS Code API stubs cover the surfaces used by real malicious extensions.
Section 5.1 says the authors focused on APIs used by past malicious extensions; if a new attack uses an unimplemented API, dynamic analysis will miss it.
domain assumption Fast-forwarding timers and overriding Date preserves the triggering semantics of time-based logic bombs.
Described in Section 4.2; recursive scheduling or interaction with real event-loop ordering could cause the payload to be skipped or executed out of order.
ad hoc to paper Heuristic indicators like Discord webhook URLs and uncommon hardcoded domains are reliable signatures of malicious intent.
Used in Sections 4.3 and 6.3; these rules are derived from past incidents and are not validated against a broad benign corpus.

how reviews work

0 comments

Cite this review

Pith. "Pith review of JavaSith: A Client-Side Framework for Analyzing Potentially Malicious Extensions in Browsers, VS Code, and NPM Packages." pith.science (2026). https://pith.science/paper/MYZYSLIU

@misc{pith2026250521263,
  author       = {Pith},
  title        = {Pith review of: JavaSith: A Client-Side Framework for Analyzing Potentially Malicious Extensions in Browsers, VS Code, and NPM Packages},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MYZYSLIU}},
  note         = {Machine review of arXiv:2505.21263}
}

read the original abstract

Modern software supply chains face an increasing threat from malicious code hidden in trusted components such as browser extensions, IDE extensions, and open-source packages. This paper introduces JavaSith, a novel client-side framework for analyzing potentially malicious extensions in web browsers, Visual Studio Code (VSCode), and Node's NPM packages. JavaSith combines a runtime sandbox that emulates browser/Node.js extension APIs (with a ``time machine'' to accelerate time-based triggers) with static analysis and a local large language model (LLM) to assess risk from code and metadata. We present the design and architecture of JavaSith, including techniques for intercepting extension behavior over simulated time and extracting suspicious patterns. Through case studies on real-world attacks (such as a supply-chain compromise of a Chrome extension and malicious VSCode extensions installing cryptominers), we demonstrate how JavaSith can catch stealthy malicious behaviors that evade traditional detection. We evaluate the framework's effectiveness and discuss its limitations and future enhancements. JavaSith's client-side approach empowers end-users/organizations to vet extensions and packages before trustingly integrating them into their environments.

Figures

Figures reproduced from arXiv: 2505.21263 by the authors.

**Figure 2.** High-level architecture of JavaSith Novel Sandbox. [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗

**Figure 3.** Overview Tab • A Vulnerabilities Summary highlighting detected vulnerabilities within the code. • A Permissions Summary (if applicable) detailing each permission required by the extension with extensive descriptions. • A File Explorer enabling users to view all files along with their complete contents. • A Code Analysis tab displaying each file alongside detailed Abstract Syntax Tree (AST) analyses. 12 [PITH_FULL_I… view at source ↗

Figures from the paper (7 more)

**Figure 4.** Figure 4: Vulnerabilities Tab [PITH_FULL_IMAGE:figures/full_fig_p013_4.png]

**Figure 5.** Figure 5: Permissions Tab • A Static Analysis tab showcasing all detected code patterns. • A Sandbox Analysis providing comprehensive insights derived from sandbox executions. • An LLM Analysis tab evaluating both risk factors and privacy policies. The GUI supports interactive …

**Figure 6.** Figure 6: File Explorer Tab [PITH_FULL_IMAGE:figures/full_fig_p014_6.png]

**Figure 7.** Figure 7: Code Analysis Tab ever, the LLM-generated summaries and explicit labeling of issues (e.g., “Detected data exfiltration” or “Uses high-risk API: child process”) also facilitate informed decision-making among less experienced users. Furthermore, JavaSith is structured t…

**Figure 8.** Figure 8: Static Analysis Tab how we addressed them are discussed below. 5.1 Sandboxing and API Hooking To intercept extension API calls, we created wrappers for Chrome’s extension APIs. For example, the extension might call chrome.storage.local.get; our wrapper intercepts this,…

**Figure 9.** Figure 9: Sandbox Analysis Tab 5.2 Time Control Mechanism The Time Machine required control over JavaScript’s event loop. We used Node’s ability to manipulate the event loop with libraries and a custom scheduler for timers. In practice, we intercept setTimeout/setInterval as sho…

**Figure 10.** Figure 10: LLM Analysis Tab (the ones with findings or suspicious patterns). This keeps the prompt size manageable. Improving the prompt engineering and possibly fine-tuning specifically for extension analysis is future work. 5.4 Performance Considerations Running full dynamic a…

Discussion (0). Sign in to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Client-Side Zero-Shot LLM Inference for Comprehensive In-Browser URL Analysis
cs.CR 2025-06 conditional novelty 6.0 of 10

A browser-based LLM that analyzes a webpage's code, runtime behavior, and text can classify malicious URLs with around 92% accuracy using zero-shot inference.
An Evaluation of Large Language Models for Detection of Malicious Python Packages
cs.CR 2026-02 conditional novelty 5.0 of 10

LLMs detect malicious PyPI packages reasonably at package level but identify specific malicious code indicators poorly, a 'granularity gap' that limits them to triage.

Reference graph

Works this paper leans on

17 extracted references · 17 canonical work pages · cited by 2 Pith papers

[1]

JavaSith Browser Extensions: https://extensions.security

work page
[2]

JavaSith IDE Extensions: https://ide.security

work page
[3]

JavaSith Code: https://code.security

work page
[4]

Hunters: Understanding The Chrome Extension Threat Cam- paign - Beyond Cyberhaven https://www.hunters.security/en/blog/ chrome-extension-threat-campaign

work page
[5]

Cyberhaven Supply Chain Attack Exploiting Browser Ex- tensions

Darktrace. “Cyberhaven Supply Chain Attack Exploiting Browser Ex- tensions.” 2024. [Online]. Available: https://www.darktrace.com/blog/ cyberhaven-supply-chain-attack-exploiting-browser-extensions

work page 2024
[6]

cyberhaven. “Cyberhaven’s preliminary analysis of the recent malicious Chrome extension : https://www.cyberhaven.com/engineering-blog/ cyberhavens-preliminary-analysis-of-the-recent-malicious-chrome-extension? ref=31337infosec.com 27

work page
[7]

Insurance Business. “Supply chain cyber attacks surge over 400%, expected to continue rising – Cowbell report : https://www.insurancebusinessmag.com/us/news/cyber/ supply-chain-cyber-attacks-surge-over-400-expected-to-continue-rising--cowbell-report-525369. aspx#:~:text=Between%202021%20and%202023%2C%20supply,cyber%20risk% 20report%20by%20Cowbell

work page
[8]

Malicious VSCode Extensions Infecting Users with Cryp- tominer

Broadcom. “Malicious VSCode Extensions Infecting Users with Cryp- tominer.” Security Bulletin, 2025. [Online]. Available: https:// www.broadcom.com/support/security-center/protection-bulletin/ malicious-vscode-extensions-infecing-users-with-cryptominer

work page 2025

Show all 17 references

[9]

Extension Runtime Security

Microsoft. “Extension Runtime Security.” Visual Studio Code Documentation. [On- line]. Available: https://code.visualstudio.com/docs/configure/extensions/ extension-runtime-security
[10]

Malicious Helpers: VSCode Extensions Observed Stealing Sensitive Information

ReversingLabs. “Malicious Helpers: VSCode Extensions Observed Stealing Sensitive Information.” 2025. [Online]. Available: https://www.reversinglabs.com/blog/ malicious-helpers-vs-code-extensions-observed-stealing-sensitive-information

2025
[11]

Malicious npm Package Leverages Unicode Steganography, Google Calendar as C2 Dropper

TheHackerNews. “Malicious npm Package Leverages Unicode Steganography, Google Calendar as C2 Dropper” 2025. [Online]. Available: https://thehackernews.com/ 2025/05/malicious-npm-package-leverages-unicode.html

2025
[12]

SES stands for fear- less cooperation

SES is a shim for Hardened JavaScript as proposed to ECMA TC39. SES stands for fear- less cooperation. Hardened JavaScript is highly compatible with ordinary JavaScript. Most existing JavaScript libraries can run on Hardened JavaScript. https://github. com/endojs/endo
[13]

Web-LLM: Run large language models in your browser

MLC-AI. “Web-LLM: Run large language models in your browser.” GitHub Repository,
[14]

RetireJS - Scanner detecting the use of JavaScript libraries with known vul- nerabilities

Retire.js. “RetireJS - Scanner detecting the use of JavaScript libraries with known vul- nerabilities.” [Online]. Available: https://retirejs.github.io/
[15]

Content Security Policy (CSP)

MDN Web Docs. “Content Security Policy (CSP).” [Online]. Available: https:// developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP. Accessed: May 2024

2024
[16]

¡iframe¿: The Inline Frame element

MDN Web Docs. “¡iframe¿: The Inline Frame element.” [Online]. Available: https:// developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe. Ac- cessed: May 2024. 28

2024
[2023]

Available: https://github.com/mlc-ai/web-llm

[Online]. Available: https://github.com/mlc-ai/web-llm

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

JavaSith Browser Extensions: https://extensions.security

work page

[2] [2]

JavaSith IDE Extensions: https://ide.security

work page

[3] [3]

JavaSith Code: https://code.security

work page

[4] [4]

Hunters: Understanding The Chrome Extension Threat Cam- paign - Beyond Cyberhaven https://www.hunters.security/en/blog/ chrome-extension-threat-campaign

work page

[5] [5]

Cyberhaven Supply Chain Attack Exploiting Browser Ex- tensions

Darktrace. “Cyberhaven Supply Chain Attack Exploiting Browser Ex- tensions.” 2024. [Online]. Available: https://www.darktrace.com/blog/ cyberhaven-supply-chain-attack-exploiting-browser-extensions

work page 2024

[6] [6]

cyberhaven. “Cyberhaven’s preliminary analysis of the recent malicious Chrome extension : https://www.cyberhaven.com/engineering-blog/ cyberhavens-preliminary-analysis-of-the-recent-malicious-chrome-extension? ref=31337infosec.com 27

work page

[7] [7]

Insurance Business. “Supply chain cyber attacks surge over 400%, expected to continue rising – Cowbell report : https://www.insurancebusinessmag.com/us/news/cyber/ supply-chain-cyber-attacks-surge-over-400-expected-to-continue-rising--cowbell-report-525369. aspx#:~:text=Between%202021%20and%202023%2C%20supply,cyber%20risk% 20report%20by%20Cowbell

work page

[8] [8]

Malicious VSCode Extensions Infecting Users with Cryp- tominer

Broadcom. “Malicious VSCode Extensions Infecting Users with Cryp- tominer.” Security Bulletin, 2025. [Online]. Available: https:// www.broadcom.com/support/security-center/protection-bulletin/ malicious-vscode-extensions-infecing-users-with-cryptominer

work page 2025