embedded-captions

SUSPICIOUS: the video-captioning purpose is mostly coherent with local ffmpeg/matting/transcription steps, but the skill overreaches by silently self-updating and refreshing dependent skills from remote sources despite claiming a local end-to-end workflow. The main issue is concealed transitive supply-chain trust, not confirmed malware or direct credential theft.

Based on the provided excerpt (which is largely scanner findings without the full script bodies), there is no definitive proof of malware such as credential theft, reverse shells, or data exfiltration. However, the codebase pattern indicated here is security-sensitive: frequent child_process execution, dynamic require(variable) module loading, symlink creation, and path traversal-like path construction. If any attacker influence exists over environment variables, argv, project JSON/template paths, or dynamically resolved module paths, this could be leveraged for code execution. Overall, treat this as a higher-risk build pipeline and verify that all dynamic paths are strictly allowlisted and that no untrusted inputs affect spawned command arguments or require()-targets.

No direct indicators of intentional malware (e.g., exfiltration, persistence, reverse shells, credential theft) are present in this fragment. The dominant security risk is operational/supply-chain: the generator executes external binaries (ffprobe and python3) during build and embeds inline client-side JavaScript into generated HTML artifacts. If an attacker can control argv[2] and/or theme/transcript inputs (or the generator’s invoked Python script/artifacts), this could enable sabotage, unexpected code execution in the build environment, or unsafe behavior in the rendered artifact. Additionally, the produced HTML depends on a CDN-hosted GSAP script at viewing time (partially mitigated by SRI).

No clear indicators of intentionally malicious runtime behavior in this module (no network calls, credential theft, or persistence). The security risk is primarily that untrusted plan.json and/or DNA-derived tokens/CSS fragments are embedded into generated HTML/CSS via raw string templating with incomplete escaping (word text only). Additionally, the tool executes ffprobe during compilation using paths derived from files discovered in the provided project directory. If an attacker can influence the project contents, they can potentially generate an index.html with HTML/CSS injection payloads and may be able to disrupt the build via ffprobe on crafted inputs.

This module is a local rendering/measurement harness with no explicit data-theft/exfiltration behavior visible. However, it has meaningful security risk due to (a) dynamic discovery and require() of Puppeteer from filesystem locations influenced by process.env.HYPERFRAMES_ROOT and broad directories (possible dependency-path poisoning/loader abuse), and (b) weakened browser security flags while executing a user-supplied local index.html, plus injecting a locally discovered JS payload (gsap.min.js) into the page via evaluateOnNewDocument. Use only with trusted projectDir and trustworthy dependency paths/checkout contents.

This code is primarily a local image/layout analysis CLI. It does not show direct malware behaviors (no networking, credential theft, or obvious persistence). However, it introduces a notable security risk: it dynamically resolves and requires 'sharp' from non-standard/writable filesystem locations (including HYPERFRAMES_ROOT and a user Downloads path), and it spawns a child Node process with an attacker-controlled project directory argument. If an attacker can influence those search roots/contents or the project directory processed by the child script, they could potentially achieve unintended code execution via the dependency or via measure-layout.cjs behavior. Otherwise, for trusted environments and inputs, the operational risk is low.