pdfkit-py

SUSPICIOUS. The PDF-processing scope is broadly coherent, but the mandatory immediate bootstrap through unseen local scripts, plus auto-download of a standalone Python runtime and font assets from unspecified locations, creates a disproportionate install-trust problem. Standard package-manager installs are expected for this purpose, but the opaque bootstrap path and automatic execution keep overall risk high despite no clear evidence of credential theft or overt malware.

This module is primarily a dynamic plugin/extension loader/dispatcher. While it does not itself show explicit malicious payload behavior (e.g., networking/exfiltration), it executes arbitrary Python code from all discovered extension scripts via exec_module with no integrity/signature/allowlist validation. Combined with sys.path manipulation that can alter import resolution, the overall supply-chain/host-compromise risk is high if the extension directory or relevant filesystem paths can be tampered with. Treat extensions as fully privileged code and secure/verify the extension directory and import paths.

No clear direct malware behavior is evident in this fragment (no exfiltration, shell, or obvious credential theft shown). The primary security issue is supply-chain/bootstrap risk: the script downloads a standalone Python runtime from a remote release and extracts it into an executable directory without any visible integrity verification, and it uses PowerShell with ExecutionPolicy Bypass while suppressing output. This combination warrants review/hardening (pinning releases, verifying checksums/signatures, reducing policy bypass, improving logging).

This fragment provides a high-risk execution service: it runs caller-supplied Python via exec() and grants user code dynamic imports (via a custom __import__ that allows a broad set of modules, including filesystem/IO-capable ones), plus significant builtins exposure. The substring-based blacklist is bypassable, the working directory is user-controlled, and the non-POSIX timeout mechanism uses unsafe async exception injection. While there is no direct evidence of stealthy malware inside this wrapper, the overall security risk is extremely high unless the executed code is fully trusted and the runtime is strongly isolated (separate process/container/user with strict filesystem/network controls).