Dify before version 1

In Dify versions up to 1.14.1, the console trace-configuration endpoints for applications did not consistently verify that the targeted app_id belonged to the caller’s tenant. The practical effect is cross-tenant authorization bypass: a user authenticated in tenant A could change tracing for an app in tenant B and point its telemetry at an attacker-controlled Langfuse or OpenTelemetry endpoint, causing later prompts, outputs, and metadata from that victim app to be exported off-platform.

The vendor's CRITICAL 9.1 overstates enterprise reality. This is not host takeover, not unauthenticated RCE, and not broad internet compromise by itself; it is a management-plane data-exfil path that still needs product access, a reachable console, a target app identifier, and usually an editor-capable session. The risk is still real because the stolen content can be sensitive, but the attack chain has enough deployment friction that this lands as MEDIUM, not panic-grade.

Why this verdict

• Downgrade for attacker position: despite the vendor PR:N framing, the exploit narrative and patch notes describe an attacker who is already inside the Dify console path — on self-hosted estates that usually implies SSO/VPN/private ingress or prior compromise.
• Downgrade for population reach: this hits the console management plane, not every internet-exposed Dify-published app. Many enterprises expose the chatbot endpoint but not the admin/API surface needed for /console/api/apps/<app_id>/trace-config.
• Downgrade for chained prerequisites: the attacker still needs a valid session, a target app_id, and outbound reachability to an attacker-controlled trace sink. Each requirement narrows the reachable population and compounds downward pressure.
• Keep it at MEDIUM, not LOW: the confidentiality/integrity impact on affected apps is real. If the target runs multi-tenant Dify Cloud or a shared creator platform with open signup, a low-trust outsider can pivot into cross-tenant data capture with very little noise.
• Low empirical threat pressure: EPSS is extremely low and there is no KEV or campaign evidence in the reviewed sources, which argues against treating this like an emergency fleet event.

Why not higher?

This is not an unauthenticated front-door break against the average enterprise host. It does not deliver code execution, domain-wide blast radius, or one-shot full-instance compromise; it abuses a tenant check in an authenticated console workflow and then waits for victim app traffic. That is dangerous, but it is not the same operational class as an internet RCE or auth bypass on a widely exposed appliance.

Why not lower?

Cross-tenant prompt and output exfiltration is a serious privacy and IP event, especially in AI platforms where traces may contain secrets, customer content, and workflow metadata. The vendor docs confirm tracing sends debugging or production data to external observability platforms, so a successful exploit can leak exactly the material most teams care about.

1. Restrict console reachability — Put the Dify console/API behind VPN, private ingress, or IdP-enforced SSO if it is not already. For a MEDIUM verdict there is no mitigation SLA, but this is the fastest risk reducer for exposed deployments and should be done immediately where the console is internet-facing.
2. Tighten signup and role assignment — Disable open self-registration where possible and review who actually holds editor-capable access in Dify. There is no mitigation SLA for MEDIUM, but reducing the pool of low-trust authenticated users cuts the exploit population sharply while you schedule remediation.
3. Constrain observability egress — Allow outbound trace traffic only to approved Langfuse/OTLP destinations through proxy or firewall policy. There is no mitigation SLA for MEDIUM, but this directly blocks the exfil path even if a tenant-scope bug exists.
4. Alert on trace-config changes — Instrument audit logging or reverse-proxy detection for /console/api/apps/*/trace-config and on any new external tracing hostnames. There is no mitigation SLA for MEDIUM; use this as compensating telemetry until all vulnerable nodes are upgraded.

Run this on the Dify host or source checkout directory, not from a remote auditor workstation. Invoke it as bash verify-cve-2026-41947.sh /opt/dify and it needs read access to the Dify install path; root is not required unless your repo directory or Docker metadata is restricted.

#!/usr/bin/env bash
# verify-cve-2026-41947.sh
# Checks whether a Dify installation appears vulnerable to CVE-2026-41947
# by determining the local checked-out version/tag. Designed for source-based
# and Docker Compose installs where the Dify repo/tag is present on disk.
#
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / insufficient evidence

set -u

TARGET_DIR="${1:-.}"
FIXED_VERSION="1.14.2"

ver_ge() {
  # returns 0 if $1 >= $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}

normalize_tag() {
  local t="$1"
  t="${t#refs/tags/}"
  t="${t#v}"
  t="${t#release-}"
  printf '%s' "$t"
}

extract_version_from_file() {
  local dir="$1"
  local candidate
  for candidate in \
    "$dir/api/pyproject.toml" \
    "$dir/api/setup.py" \
    "$dir/web/package.json" \
    "$dir/package.json"; do
    if [ -f "$candidate" ]; then
      local v
      v=$(grep -Eom1 '[0-9]+\.[0-9]+\.[0-9]+' "$candidate" 2>/dev/null || true)
      if [ -n "$v" ]; then
        printf '%s' "$v"
        return 0
      fi
    fi
  done
  return 1
}

get_git_version() {
  local dir="$1"
  if command -v git >/dev/null 2>&1 && [ -d "$dir/.git" ]; then
    local tag
    tag=$(git -C "$dir" describe --tags --exact-match 2>/dev/null || true)
    if [ -z "$tag" ]; then
      tag=$(git -C "$dir" describe --tags --abbrev=0 2>/dev/null || true)
    fi
    if [ -n "$tag" ]; then
      normalize_tag "$tag"
      return 0
    fi
  fi
  return 1
}

main() {
  if [ ! -d "$TARGET_DIR" ]; then
    echo "UNKNOWN - target directory not found: $TARGET_DIR"
    exit 2
  fi

  local version=""

  version=$(get_git_version "$TARGET_DIR" 2>/dev/null || true)
  if [ -z "$version" ]; then
    version=$(extract_version_from_file "$TARGET_DIR" 2>/dev/null || true)
  fi

  if [ -z "$version" ]; then
    echo "UNKNOWN - could not determine local Dify version from git tags or common metadata files"
    exit 2
  fi

  if ver_ge "$version" "$FIXED_VERSION"; then
    echo "PATCHED - detected Dify version $version (fixed threshold: $FIXED_VERSION)"
    exit 0
  fi

  echo "VULNERABLE - detected Dify version $version (< $FIXED_VERSION)"
  exit 1
}

main

Sources

1. NVD CVE-2026-41947
2. CIRCL Vulnerability-Lookup CVE record mirror
3. Dify PR #35793 tenant scoping fix
4. Dify fixing commit 55d05fe
5. Dify v1.14.2 release notes
6. Dify docs: Integrate with Langfuse
7. Dify docs: Quick Start / free cloud signup
8. CISA Known Exploited Vulnerabilities Catalog