Fireshare facilitates self-hosted media and link sharing

CVE-2025-67728 is a filename-driven command injection in Fireshare upload handling affecting <=1.2.30, fixed in v1.3.0. A crafted video filename is folded into a shell command during post-upload processing, which can turn an upload into arbitrary command execution and arbitrary file write/path traversal behavior. The advisory is explicit about the real gate: the attacker must either be an authenticated uploader, or hit an instance where *Public Uploads* is enabled.

The vendor's 9.8 CRITICAL score is technically defensible for the worst-case deployment, but it overstates fleet-wide reality. In practice this is a niche self-hosted app, uploads are optional/restrictable, and unauthenticated exploitation exists only on deployments that deliberately exposed public uploads; those are meaningful friction points, so this lands as HIGH, not CRITICAL.

Why this verdict

• Baseline down from 9.8: the vendor score models the worst case, but real exploitation starts with an upload-capable path, not generic anonymous internet reachability on every deployment.
• Major friction: Public Uploads is conditional — per the advisory, PR:N only holds when Public Uploads is enabled; otherwise this is authenticated remote abuse, which is post-access and narrower.
• Population is small — Fireshare is a niche self-hosted media app, not a common enterprise platform, so the reachable universe is much smaller than the bugs that deserve fleetwide CRITICAL treatment.
• Impact stays serious — if you do expose public uploads, exploitation is low-complexity and yields arbitrary command execution in the app/container context with access to mounted data volumes.
• Threat intel is quiet — low EPSS, no KEV listing, and no verified primary-source campaign evidence remove the usual amplifier that would push this back toward CRITICAL.

Why not higher?

Because this is not a clean, universal pre-auth internet RCE across the whole install base. The vulnerability depends on an upload-capable path, and the unauthenticated case exists only when admins turned on Public Uploads; that is real deployment friction, not theoretical edge-case handwaving.

Why not lower?

Because once the prerequisite is met, the exploit path is straightforward and the outcome is still arbitrary command execution. On an exposed Fireshare instance with public uploads enabled, this is exactly the kind of bug that becomes an immediate foothold into app data, mounted media volumes, and possible internal pivoting.

1. Disable public uploads — If the business does not explicitly need anonymous uploads, turn them off. This removes the PR:N branch of the attack path and should be completed within 30 days for a HIGH finding; if you knowingly expose Fireshare to the internet, do it sooner.
2. Put Fireshare behind authentication or private access — Require SSO, VPN, reverse-proxy auth, or IP allowlisting so the upload endpoints are not anonymously reachable from the internet. This is the highest-value exposure reduction step and should be deployed within 30 days.
3. Constrain the container — Run the service as non-root, keep mounts to the minimum needed, prefer read-only where possible, and apply seccomp/AppArmor or equivalent runtime policy. This does not fix the bug, but it reduces what post-exploitation can touch and should be tightened within 30 days.
4. Monitor child-process creation from Fireshare — Alert on the Fireshare process or container spawning shells or unexpected binaries, especially sh, bash, curl, wget, or package managers. That gives you runtime detection for exploit attempts and should be turned on within 30 days.
5. Inspect mounted-volume integrity — Watch /data, /processed, /videos, and /images for unexpected writes, executable drops, or ownership changes. This helps catch successful exploitation and follow-on persistence; stand it up within 30 days.

Run this on the Docker host that runs Fireshare, not on a random auditor workstation. Invoke it as sudo bash fireshare_cve_2025_67728_check.sh fireshare for a container name, or sudo bash fireshare_cve_2025_67728_check.sh shaneisrael/fireshare:v1.2.30 for an image tag; it needs only read access to the Docker socket.

#!/usr/bin/env bash
# fireshare_cve_2025_67728_check.sh
# Check whether a Docker-deployed Fireshare instance appears vulnerable to CVE-2025-67728.
#
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN
#  64 = USAGE ERROR

set -euo pipefail

usage() {
  echo "Usage: $0 <container-name|image:tag|version>" >&2
  echo "Example: $0 fireshare" >&2
  echo "Example: $0 shaneisrael/fireshare:v1.2.30" >&2
  exit 64
}

normalize_version() {
  local v="$1"
  v="${v#v}"
  v="${v%%-*}"
  echo "$v"
}

is_semver() {
  [[ "$1" =~ ^[vV]?[0-9]+\.[0-9]+\.[0-9]+([.-][A-Za-z0-9._-]+)?$ ]]
}

version_le() {
  local a b
  a="$(normalize_version "$1")"
  b="$(normalize_version "$2")"
  [[ "$(printf '%s\n%s\n' "$a" "$b" | sort -V | head -n1)" == "$a" ]]
}

version_ge() {
  local a b
  a="$(normalize_version "$1")"
  b="$(normalize_version "$2")"
  [[ "$(printf '%s\n%s\n' "$a" "$b" | sort -V | tail -n1)" == "$a" ]]
}

resolve_input_to_version() {
  local input="$1"

  if is_semver "$input"; then
    echo "$input"
    return 0
  fi

  if [[ "$input" == *:* ]]; then
    local tag="${input##*:}"
    if is_semver "$tag"; then
      echo "$tag"
      return 0
    fi
    echo "$tag"
    return 0
  fi

  if command -v docker >/dev/null 2>&1; then
    if docker inspect "$input" >/dev/null 2>&1; then
      local image tag
      image="$(docker inspect -f '{{.Config.Image}}' "$input" 2>/dev/null || true)"
      if [[ -n "$image" && "$image" == *:* ]]; then
        tag="${image##*:}"
        echo "$tag"
        return 0
      fi
    fi
  fi

  return 1
}

if [[ $# -ne 1 ]]; then
  usage
fi

TARGET="$1"
VERSION="$(resolve_input_to_version "$TARGET" 2>/dev/null || true)"

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN - could not resolve a Fireshare version from input '$TARGET'" 
  exit 2
fi

# Common non-pinned tags cannot prove safety.
case "$VERSION" in
  latest|latest-lite|main|master)
    echo "UNKNOWN - image tag '$VERSION' is not a pinned version; inspect your deployment manifest or container provenance"
    exit 2
    ;;
esac

if ! is_semver "$VERSION"; then
  echo "UNKNOWN - resolved tag/version '$VERSION' is not a parseable semantic version"
  exit 2
fi

if version_le "$VERSION" "1.2.30"; then
  echo "VULNERABLE - detected Fireshare version $VERSION (affected: <=1.2.30; fixed in 1.3.0)"
  exit 1
fi

if version_ge "$VERSION" "1.3.0"; then
  echo "PATCHED - detected Fireshare version $VERSION (fixed version threshold: >=1.3.0)"
  exit 0
fi

echo "UNKNOWN - version $VERSION could not be classified confidently"
exit 2

Sources

1. NVD CVE-2025-67728
2. GitHub Security Advisory GHSA-c4f5-g622-q72m
3. Fix commit 157386c85f6683f89192dae52115069b435b6d34
4. OSV entry for CVE-2025-67728
5. Fireshare repository README
6. Fireshare releases
7. CISA Known Exploited Vulnerabilities Catalog