Security audit

dify-dsl-to-code

Security checks across malware telemetry and agentic risk

Overview

This is a coherent Dify workflow code generator, but generated projects can read named environment secrets and execute generated or DSL-derived code without strong containment.

Use this only with Dify DSL files you trust. Generate and verify projects in an isolated folder or container with minimal environment variables, review every env/secret reference and outbound HTTP/tool/LLM endpoint before running, and pin or update template dependencies before deploying generated services.

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection

Findings (12)

Lp3

Medium

Category: MCP Least Privilege
Confidence: 92% confidence
Finding: The skill instructs the agent to read user-specified files, write generated project files, and potentially handle secrets via environment variables, but it declares no permissions. This mismatch can undermine sandboxing and user expectations, making unauthorized file access or modification easier if the platform relies on declared permissions for enforcement or review.

Context-Inappropriate Capability

Medium

Confidence: 93% confidence
Finding: The template resolver allows any DSL-controlled reference like {{#env.NAME#}} or {{#secret.NAME#}} to read arbitrary process environment variables with no allowlist, scoping, or approval step. In this skill, untrusted or user-supplied Dify DSL is converted into runnable code, so a crafted workflow can exfiltrate host secrets at runtime through normal template interpolation.

Intent-Code Divergence

Low

Confidence: 74% confidence
Finding: The comment frames secret handling as ordinary template resolution, but the implementation directly maps {{#secret.*#}} and {{#env.*#}} to host environment variables. That mismatch can mislead maintainers and users into underestimating the sensitivity of the feature, increasing the chance that unsafe DSL is trusted or deployed without proper review.

Missing User Warnings

Medium

Confidence: 89% confidence
Finding: Sensitive value resolution happens silently during interpolation, with no warning, consent, or disclosure to the operator that a DSL is attempting to access env/secret material. In a DSL-to-code generator that may process third-party workflows, this increases the risk of accidental secret exposure because users may not realize the generated service will read and propagate host credentials.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The verifier imports `app.workflow.definition` from the user-supplied project path and calls `build_handlers()`, which executes arbitrary Python code during verification. In this skill's context, generated or user-provided projects may be untrusted, so verification becomes a code-execution sink that could run attacker-controlled module top-level code or handler registration logic on the analyst's machine/agent environment.

Unpinned Dependencies

Low

Category: Supply Chain
Content: fastapi>=0.110 uvicorn[standard]>=0.29 pydantic>=2.6 python-dotenv>=1.0
Confidence: 96% confidence
Finding: The dependency is specified with only a lower bound, which allows future unreviewed versions to be installed. This weakens build reproducibility and can unexpectedly introduce breaking changes or newly disclosed vulnerable releases into generated projects.

Unpinned Dependencies

Low

Category: Supply Chain
Content: fastapi>=0.110 uvicorn[standard]>=0.29 pydantic>=2.6 python-dotenv>=1.0 httpx>=0.27 jinja2>=3.1
Confidence: 96% confidence
Finding: Using an unpinned pydantic version makes installs non-reproducible and permits automatic resolution to later releases that may contain security or compatibility issues. In a code-generation template, this risk propagates to every generated project.

Unpinned Dependencies

Low

Category: Supply Chain
Content: fastapi>=0.110 uvicorn[standard]>=0.29 pydantic>=2.6 python-dotenv>=1.0 httpx>=0.27 jinja2>=3.1
Confidence: 98% confidence
Finding: The unpinned python-dotenv requirement is riskier here because the package also has an associated advisory in the findings. A lower-bound-only spec can allow installation of a vulnerable or otherwise unreviewed version, increasing exposure across all generated FastAPI projects.

Unpinned Dependencies

Low

Category: Supply Chain
Content: uvicorn[standard]>=0.29 pydantic>=2.6 python-dotenv>=1.0 httpx>=0.27 jinja2>=3.1
Confidence: 95% confidence
Finding: An unpinned httpx dependency permits dependency drift over time, reducing reproducibility and potentially introducing vulnerable or incompatible releases. Since this is a project template, the issue can affect all downstream generated applications.

Unpinned Dependencies

Low

Category: Supply Chain
Content: pydantic>=2.6 python-dotenv>=1.0 httpx>=0.27 jinja2>=3.1
Confidence: 99% confidence
Finding: The unpinned jinja2 dependency is especially dangerous because the findings indicate known critical advisories affecting the 3.1 line. Allowing any later unreviewed 3.x release without explicit vetting can expose generated services to template-related vulnerabilities.

Known Vulnerable Dependency: express==4.19.2 — 1 advisory(ies): CVE-2024-43796 (express vulnerable to XSS via response.redirect())

Low

Category: Supply Chain
Confidence: 96% confidence
Finding: The template depends on express 4.19.2, which is associated with CVE-2024-43796 affecting response.redirect() and enabling XSS in some redirect flows. Because this skill generates deployable Express services from DSLs, the vulnerable framework version may be propagated into produced projects and become exploitable if generated code uses redirects with untrusted input.

Known Vulnerable Dependency: jinja2==3.1 — 10 advisory(ies): CVE-2025-27516 (Jinja2 vulnerable to sandbox breakout through attr filter selecting format metho); CVE-2024-56201 (Jinja has a sandbox breakout through malicious filenames); CVE-2024-22195 (Jinja vulnerable to HTML attribute injection when passing user input as keys to ) +7 more

Critical

Category: Supply Chain
Confidence: 84% confidence
Finding: Although the requirement is written as jinja2>=3.1 rather than ==3.1, the allowed range includes the explicitly flagged vulnerable version and potentially other affected 3.1.x releases. In a code-generation template that may render content in generated services, template-engine vulnerabilities can become broadly impactful if unsafe rendering patterns are used downstream.

VirusTotal

VirusTotal findings are pending for this skill version.

View on VirusTotal

Static analysis

No suspicious patterns detected.