Dify version 1

CVE-2026-41948 is a path traversal in Dify's proxying to the Plugin Daemon internal REST API. Affected builds are Dify 1.14.1 and earlier. The vulnerable flow forwards caller-controlled path material to the plugin daemon without adequately rejecting traversal segments, so an attacker can use crafted task identifiers or filename parameters to step outside the intended tenant-scoped path and hit internal endpoints such as debug surfaces.

The vendor/NVD-style 9.4 CRITICAL rating is too hot for most enterprise patch queues. The real-world chain requires an attacker to first become an authenticated Dify user, then know or discover a victim tenant UUID, then hit the specific proxyable path in a way that survives normalization. That is still bad in shared Dify environments because it breaks tenant isolation, but it is not equivalent to anonymous one-packet internet compromise. The one major amplifier is that Dify Cloud allows free self-registration, which weakens the usual value of the auth prerequisite.

Why this verdict

• Auth requirement is real downward pressure — in self-hosted enterprises this usually implies prior access, SSO enrollment, or invitation. Vendor PR:N is technically defensible for Dify Cloud self-registration, but it overstates exposure for private deployments.
• Target-knowledge raises friction — the attacker needs the victim tenant UUID and a path that breaks out of the intended namespace. GitHub's advisory modeling this as AC:H matches field reality better than a flat low-complexity assumption.
• Impact is still serious once it lands — this is not cosmetic traversal. It can cross tenant boundaries into internal plugin-daemon/debug surfaces, which makes the blast radius meaningful inside shared Dify estates.

Why not higher?

I did not find KEV listing, public campaign reporting, or a broadly circulating turnkey exploit. More importantly, this is not demonstrated host-level RCE and it usually requires either self-registration or pre-existing user access plus target-specific recon, which keeps it below the 'drop everything' bucket.

Why not lower?

Free self-registration on Dify Cloud weakens the protection normally provided by authentication, so calling this merely medium would understate cloud/SaaS risk. And if you run Dify as a shared internal platform, tenant-boundary failures are exactly the sort of bug that turns one low-privilege foothold into cross-workspace data exposure.

1. Disable open signup and tighten identity gates — If your deployment permits self-registration, stop treating this as a harmless auth-required bug. Move Dify behind SSO, invitation-only access, or VPN where possible; for a HIGH verdict, deploy this control within 30 days.
2. Block traversal patterns at the reverse proxy — Reject requests containing .., %2e%2e, mixed-encoding dot segments, and suspicious filename/task identifier patterns on Dify API routes that touch plugin or file proxying. This is not a perfect fix, but it meaningfully cuts exploit reliability; deploy within 30 days.
3. Keep plugin-daemon and debug ports private — Dify docs show internal daemon traffic on 5002 and optional debugging on 5003. Ensure those ports are not internet-exposed and are reachable only from the app tier or explicit admin workflows; validate within 30 days.
4. Hunt for tenant-crossing path probes — Search ingress, app, and plugin-daemon logs for dot-segment traversal markers and for one account referencing multiple tenant UUIDs. This is your best immediate signal of attempted exploitation; turn on monitoring within 30 days.

Run this on a self-hosted Dify app host or container filesystem where the Dify source tree is present. Invoke it as bash verify_cve_2026_41948.sh /path/to/dify (example: bash verify_cve_2026_41948.sh /app/dify). It needs read-only access to the Dify tree; no root is required unless your container filesystem permissions demand it.

#!/usr/bin/env bash
# verify_cve_2026_41948.sh
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -euo pipefail

ROOT="${1:-.}"
FILE="$ROOT/api/core/plugin/impl/base.py"

semver_lte() {
  # returns 0 if $1 <= $2
  local a b IFS=.
  read -r -a a <<< "${1#v}"
  read -r -a b <<< "${2#v}"
  for i in 0 1 2; do
    local ai="${a[$i]:-0}"
    local bi="${b[$i]:-0}"
    if (( ai < bi )); then return 0; fi
    if (( ai > bi )); then return 1; fi
  done
  return 0
}

if [[ ! -f "$FILE" ]]; then
  echo "UNKNOWN - expected file not found: $FILE"
  exit 2
fi

# The merged fix in PR #35796 adds a traversal guard in api/core/plugin/impl/base.py.
if grep -q "Invalid plugin daemon path: traversal sequence detected" "$FILE" \
   || grep -q "traversal sequence detected" "$FILE"; then
  echo "PATCHED - traversal guard string found in $FILE"
  exit 0
fi

if grep -q "unquote(path)" "$FILE" && grep -q "%2e%2e" "$FILE"; then
  echo "PATCHED - path decode and encoded-dot traversal checks found in $FILE"
  exit 0
fi

VERSION=""
if command -v git >/dev/null 2>&1 && [[ -d "$ROOT/.git" ]]; then
  VERSION="$(git -C "$ROOT" describe --tags --exact-match 2>/dev/null || true)"
fi

if [[ -n "$VERSION" ]]; then
  if semver_lte "$VERSION" "1.14.1"; then
    echo "VULNERABLE - version $VERSION and no traversal guard found"
    exit 1
  else
    echo "UNKNOWN - version $VERSION is newer than 1.14.1, but guard pattern was not found; validate whether the fix was backported differently"
    exit 2
  fi
fi

echo "UNKNOWN - no git tag found and no known fix pattern detected; compare api/core/plugin/impl/base.py against PR #35796"
exit 2

Sources

1. NVD CVE-2026-41948
2. GitHub Advisory Database - GHSA-h666-98mq-949j
3. Dify PR #35796 fix details
4. VulnCheck advisory
5. Dify releases page
6. Dify self-hosted environment variables
7. Dify plugin remote debugging docs
8. CISA Known Exploited Vulnerabilities Catalog