RAGFlow is an open-source RAG

CVE-2026-28797 is an authenticated server-side template injection in RAGFlow Agent workflow components, specifically Text Processing (StringTransform) and Message. In RAGFlow 0.24.0 and earlier, those components render user-controlled Jinja2 templates without sandboxing, so a low-privileged user can turn a harmless-looking template field into OS command execution on the RAGFlow server.

The vendor's HIGH call is directionally right on impact but a little hot if you care about enterprise patch queues. This is not pre-auth internet spray-and-pray RCE: the attacker needs a valid account and access to Agent workflow features, which sharply narrows exposed population; but the default self-registration path and the fact that *any* authenticated user can jump straight to server command execution keep it solidly in HIGH rather than MEDIUM.

Why this verdict

• Downgrade from vendor 8.8 for PR:L: requiring authenticated remote access means the attacker is not starting from the open internet unless self-registration is enabled or creds are already compromised.
• Exposure population is narrower: RAGFlow is popular in open-source circles, but it is not an internet-edge staple, and public scan artifacts suggest only limited direct exposure compared with mass-targeted platforms.
• Upgrade pressure remains because blast radius is ugly: once inside, the attacker can pivot from app-level template injection to command execution, secret theft, data access, and likely control of backing services.

Why not higher?

This is not pre-auth RCE and not a KEV-listed or publicly observed mass-exploitation event. The chain assumes either valid credentials or a registration path, and many enterprise deployments should already put this app behind SSO, VPN, or restricted admin access.

Why not lower?

The permission bar is low: GitHub's advisory says *any authenticated user* can reach the vulnerable workflow components, and self-registration is enabled by default. Once triggered, the vulnerability is not a narrow tenant-only issue; it can expose host commands, service credentials, and all tenant data reachable by the server.

1. Disable self-registration — If you cannot patch immediately, remove the easiest attacker on-ramp by setting REGISTER_ENABLED=0 or otherwise closing public signup. For a HIGH verdict, deploy this compensating control within 30 days; do it first on any internet-reachable instance.
2. Put RAGFlow behind identity and network gates — Force access through SSO, VPN, IP allowlists, or a private reverse proxy so this stays an internal-user problem instead of an internet problem. For a HIGH verdict, apply this within 30 days, prioritizing exposed or partner-accessible deployments.
3. Restrict Agent workflow access — Remove Agent creation/edit rights from ordinary users and confine those functions to trusted admins or service users. This directly cuts the exploit path because the vulnerable components sit inside the Agent workflow feature set; enforce within 30 days.
4. Harden the runtime — Run RAGFlow with least privilege, tight container profiles, minimal mounted secrets, and segmentation to MySQL/Redis/MinIO/Elasticsearch. This will not prevent code execution, but it can cap post-exploitation blast radius; implement within 30 days where patching is delayed.
5. Alert on app-to-shell behavior — Tune EDR or container runtime telemetry to flag shells, os.popen, reverse shells, or unusual outbound connections from the RAGFlow process/container. This is a detection-oriented compensating control and should also be in place within 30 days for lingering vulnerable nodes.

Run this on the target RAGFlow host or inside the ragflow-server container. Example: docker exec -i ragflow-server bash -s -- /ragflow < ./check_cve_2026_28797.sh or, from a source checkout, bash ./check_cve_2026_28797.sh /path/to/ragflow; no root is required unless you need docker exec access.

#!/usr/bin/env bash
# check_cve_2026_28797.sh
# Detects likely vulnerable vs patched RAGFlow code for CVE-2026-28797
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET="${1:-/ragflow}"
if [ ! -d "$TARGET" ]; then
  if [ -d ".git" ] && [ -f "agent/component/string_transform.py" ]; then
    TARGET="."
  fi
fi

STR_FILE="$TARGET/agent/component/string_transform.py"
MSG_FILE="$TARGET/agent/component/message.py"

if [ ! -f "$STR_FILE" ] || [ ! -f "$MSG_FILE" ]; then
  echo "UNKNOWN - could not find RAGFlow source files under: $TARGET"
  exit 2
fi

has_vuln_pattern() {
  local f="$1"
  grep -Eq 'from jinja2 import Template as Jinja2Template|Jinja2Template\(' "$f"
}

has_patch_pattern() {
  local f="$1"
  grep -Eq 'from jinja2\.sandbox import SandboxedEnvironment|SandboxedEnvironment\(|_jinja2_sandbox|from_string\(' "$f"
}

str_vuln=0
msg_vuln=0
str_patch=0
msg_patch=0

has_vuln_pattern "$STR_FILE" && str_vuln=1
has_vuln_pattern "$MSG_FILE" && msg_vuln=1
has_patch_pattern "$STR_FILE" && str_patch=1
has_patch_pattern "$MSG_FILE" && msg_patch=1

version_hint="unknown"
if [ -f "$TARGET/README.md" ]; then
  version_hint=$(grep -Eo 'v0\.[0-9]+\.[0-9]+' "$TARGET/README.md" | head -n1 || true)
  [ -z "$version_hint" ] && version_hint="unknown"
fi

if [ "$str_vuln" -eq 1 ] || [ "$msg_vuln" -eq 1 ]; then
  echo "VULNERABLE - unsandboxed Jinja2 usage detected (version hint: $version_hint)"
  exit 1
fi

if [ "$str_patch" -eq 1 ] && [ "$msg_patch" -eq 1 ]; then
  echo "PATCHED - sandboxed Jinja2 patterns detected in both vulnerable components (version hint: $version_hint)"
  exit 0
fi

echo "UNKNOWN - source present but could not confidently classify patched state (version hint: $version_hint)"
exit 2

Sources

1. NVD entry
2. GitHub Security Advisory GHSA-vvwj-fvwh-4whx
3. RAGFlow releases
4. RAGFlow v0.25.0 patched file evidence
5. RAGFlow release notes
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview
8. Shodan facet page showing indexed `RAGFlow` banners