Ghostfolio is an open source wealth management software

CVE-2026-28785 is a SQL injection in Ghostfolio's manual asset import flow. In versions before 2.244.0, an attacker can bypass symbol validation and hit the getHistorical() path to run arbitrary SQL against the app database, which can expose or alter portfolio and financial records across users.

The vendor's CRITICAL 9.8 score is technically understandable for raw impact, but it overstates typical enterprise risk. The advisory's own workaround says to disable public user signup so only trusted users can reach the manual import feature; that is a big clue that real exploitation often depends on account creation or existing access, and Ghostfolio itself is a niche self-hosted app with a much smaller exposed population than mainstream edge software.

Why this verdict

• Down from 9.8 because exposure is narrower than CVSS implies: the vulnerable path is in *manual asset import*, not a generic pre-auth homepage endpoint every anonymous user naturally hits.
• Down again because attacker position is often stronger than PR:N suggests: the GHSA workaround says disable *public signup*, which implies many practical exploit chains require open registration or an existing account rather than pure drive-by internet reach.
• Down again because population is small: Ghostfolio is a niche self-hosted wealth app, not a broadly deployed enterprise edge platform. That sharply limits both victim pool and wormable potential.
• Held at HIGH because impact inside the app is still ugly: if the feature is reachable, SQLi against the Ghostfolio DB can expose or change sensitive financial data for all users in that instance.
• Held at HIGH because exploitation mechanics are not exotic: once request structure is understood, SQLi is commodity attacker tradecraft, and time-based blind extraction is still workable.

Why not higher?

I did not keep this at CRITICAL because the real-world chain appears to need more than 'internet packet hits login page, box falls over.' The likely need for public signup or some authenticated path, combined with a niche deployment base and no active exploitation evidence, creates meaningful downward pressure.

Why not lower?

I did not drop this to MEDIUM because the vulnerable feature can still lead to full compromise of the application's core data store. For exposed instances with signup enabled or weak account controls, exploitation should be low-complexity and the confidentiality/integrity hit is real.

1. Disable public signup — Do this within 30 days as the first containment move because the vendor explicitly calls it out as the workaround. If only trusted admins can create accounts, you remove the cleanest remote path into the vulnerable import flow.
2. Pull Ghostfolio behind identity-aware access — Place the app behind VPN, SSO gateway, reverse-proxy auth, or IP allowlists within 30 days. This changes the attacker position from anonymous internet to authenticated network user and materially cuts reachable population.
3. Block or monitor import/history endpoints — Add temporary WAF or reverse-proxy rules for the manual asset import and related historical lookup paths within 30 days. Focus on SQLi signatures, repeated delayed-response probes, and abusive request rates to slow blind extraction.
4. Tighten DB privileges — Review the Ghostfolio application's database account within 30 days and ensure it has only the minimum rights needed. Least privilege does not prevent exploitation, but it does cap how much data an attacker can read or destroy.
5. Preserve clean backups — Validate recent restorable database backups within 30 days. This matters because the stated impact includes record modification and deletion, and recovery posture decides whether an incident is annoying or business-disruptive.

Run this on the Ghostfolio host or a jump box with access to the local Docker daemon and/or application files. Invoke it as bash verify_ghostfolio_cve_2026_28785.sh ghostfolio for a container named ghostfolio, or bash verify_ghostfolio_cve_2026_28785.sh /opt/ghostfolio for a filesystem path; it needs read access to Docker metadata or the app directory, and no root is required unless your Docker socket permissions demand it.

#!/usr/bin/env bash
# verify_ghostfolio_cve_2026_28785.sh
# Check Ghostfolio version against CVE-2026-28785 fixed version 2.244.0
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

FIXED_VERSION="2.244.0"
TARGET="${1:-ghostfolio}"
FOUND_VERSION=""

trim() {
  local s="$1"
  s="${s#\"}"
  s="${s%\"}"
  printf '%s' "$s"
}

version_lt() {
  # returns 0 if $1 < $2
  [ "$1" = "$2" ] && return 1
  local first
  first=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)
  [ "$first" = "$1" ]
}

extract_version_from_package_json() {
  local file="$1"
  [ -f "$file" ] || return 1
  local v
  v=$(grep -E '"version"\s*:\s*"[^"]+"' "$file" 2>/dev/null | head -n1 | sed -E 's/.*"version"\s*:\s*"([^"]+)".*/\1/')
  [ -n "$v" ] || return 1
  printf '%s' "$v"
  return 0
}

extract_version_from_container() {
  local container="$1"
  command -v docker >/dev/null 2>&1 || return 1
  docker inspect "$container" >/dev/null 2>&1 || return 1

  local v=""

  # Try common package.json locations inside the container
  for p in /usr/src/app/package.json /app/package.json /var/www/package.json; do
    v=$(docker exec "$container" sh -c "[ -f '$p' ] && grep -E '\"version\"\s*:\s*\"[^\"]+\"' '$p' | head -n1" 2>/dev/null | sed -E 's/.*\"version\"\s*:\s*\"([^\"]+)\".*/\1/' )
    if [ -n "$v" ]; then
      printf '%s' "$v"
      return 0
    fi
  done

  # Fall back to image tag if present and specific
  v=$(docker inspect --format '{{.Config.Image}}' "$container" 2>/dev/null | sed -E 's/.*:([^:@]+)$/\1/')
  case "$v" in
    latest|stable|main|master|"") return 1 ;;
    *) printf '%s' "$v"; return 0 ;;
  esac
}

extract_version_from_path() {
  local base="$1"
  [ -d "$base" ] || return 1
  local p
  for p in "$base/package.json" "$base/apps/api/package.json" "$base/app/package.json"; do
    FOUND_VERSION=$(extract_version_from_package_json "$p") && { printf '%s' "$FOUND_VERSION"; return 0; }
  done
  return 1
}

# 1) If target is a directory, inspect files directly
if [ -d "$TARGET" ]; then
  FOUND_VERSION=$(extract_version_from_path "$TARGET") || true
fi

# 2) If not found, try as a Docker container name/ID
if [ -z "$FOUND_VERSION" ]; then
  FOUND_VERSION=$(extract_version_from_container "$TARGET") || true
fi

# 3) If still not found, try auto-discovering a likely Ghostfolio container
if [ -z "$FOUND_VERSION" ] && command -v docker >/dev/null 2>&1; then
  CANDIDATE=$(docker ps --format '{{.Names}} {{.Image}}' 2>/dev/null | awk 'tolower($0) ~ /ghostfolio/ {print $1; exit}')
  if [ -n "${CANDIDATE:-}" ]; then
    FOUND_VERSION=$(extract_version_from_container "$CANDIDATE") || true
  fi
fi

FOUND_VERSION=$(trim "$FOUND_VERSION")

if [ -z "$FOUND_VERSION" ]; then
  echo "UNKNOWN - could not determine Ghostfolio version from path/container: $TARGET"
  exit 2
fi

if version_lt "$FOUND_VERSION" "$FIXED_VERSION"; then
  echo "VULNERABLE - Ghostfolio version $FOUND_VERSION is older than fixed version $FIXED_VERSION"
  exit 1
else
  echo "PATCHED - Ghostfolio version $FOUND_VERSION is at or above fixed version $FIXED_VERSION"
  exit 0
fi

Sources

1. GitHub Security Advisory GHSA-m5cc-7jw5-34xp
2. Ghostfolio 2.244.0 release
3. NVD CVE-2026-28785
4. OSV entry for CVE-2026-28785
5. OpenCVE record with CISA ADP enrichment
6. CISA Known Exploited Vulnerabilities Catalog
7. Ghostfolio Open Startup metrics
8. Ghostfolio self-hosting FAQ