Open ISES Tickets before 3

CVE-2026-48241 is a *hardcoded credential exposure* in Open ISES Tickets before 3.44.2. The vulnerable artifact is loader.php, described by NVD as a *public-facing database utility* with MySQL username, password, and database name committed into the source tree; if an attacker can read that file from the public repo or from a deployed webroot, they can recover working application DB credentials.

The vendor's HIGH 8.1 score is technically understandable but operationally inflated for most enterprises. The decisive friction is that *credential disclosure is not the same thing as remote compromise*: the attacker still needs the database service to be reachable from their network, and many sane deployments keep MySQL bound to 127.0.0.1 or a private segment. That turns this from a clean unauthenticated internet exploit into a narrower two-condition failure: exposed file *plus* reachable DB.

Why this verdict

• Downgrade for attacker position: vendor starts at unauthenticated remote, but real impact usually requires reachable MySQL; if DB is internal-only, exploitation implicitly requires *internal network access* or prior foothold.
• Downgrade for exposed population: Open ISES Tickets is a niche PHP app with limited observed ecosystem footprint, so the population of reachable, directly exposed loader.php endpoints is likely much smaller than mainstream internet software.
• Downgrade for exploit chain friction: the chain compounds: readable file, valid unrotated creds, reachable DB listener, and meaningful DB privileges. Each prerequisite narrows real-world exploitability.
• Keep it above LOW: if the file is exposed and the DB is reachable, the attacker can get full app-data compromise without authentication or user interaction.
• No upward pressure from threat intel: no KEV listing, no active exploitation evidence reviewed, and EPSS is very low.

Why not higher?

This is not a clean edge-to-impact remote code execution bug. The public-facing file leak is only the first half of the story, and many competent deployments break the chain by keeping MySQL off the internet or localhost-only. There is also no meaningful exploitation signal pushing this above its technical potential.

Why not lower?

Hardcoded live database credentials in a web-accessible utility are still dangerous, especially in smaller or under-managed deployments where webroot sprawl and flat networks are common. If the conditions align, the attacker gets direct database access with no auth and no user interaction, which is too much impact to dismiss as backlog-only hygiene.

1. Block direct access to utility files — Deny web access to loader.php and similar admin/import/database helper scripts at the web server or reverse proxy. For a MEDIUM finding there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but if this app is internet-exposed, do this immediately because it collapses the first attack step.
2. Constrain MySQL network exposure — Bind MySQL/MariaDB to 127.0.0.1 or a private backend interface and restrict inbound DB access with host firewall, SG, or ACL rules. This directly breaks the highest-friction step in the chain and is the strongest non-patch control; complete during the 365-day remediation window if not already standard.
3. Rotate the application DB credential — Replace any credential that may have matched the exposed value and confirm the app uses the new secret from a local-only config path. Even without patching immediately, secret rotation invalidates harvested creds; complete within the 365-day remediation window.
4. Remove public source exposure — If this was deployed from a public repo checkout or with sample utilities intact, remove those files from the served document root and ensure .git or source archives are not exposed. This is cheap blast-radius reduction and should be folded into normal remediation work during the 365-day remediation window.
5. Turn on DB and web telemetry — Log requests to loader.php, failed/successful remote MySQL connections, and unusual query bursts or dumps against the application schema. This does not prevent abuse, but it gives you a fighting chance to spot a quiet credential-based intrusion before data walks out.

Run this on the target host or on a mounted webroot that contains the Open ISES installation. Invoke it as sudo bash check_cve_2026_48241.sh /var/www/html/tickets or point it at the application root; root is not strictly required, but you need read access to the install tree and any .git metadata if present.

#!/usr/bin/env bash
# check_cve_2026_48241.sh
# Detect likely exposure for CVE-2026-48241 in Open ISES Tickets.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/error

set -u

TARGET="${1:-}"
if [[ -z "$TARGET" || ! -d "$TARGET" ]]; then
  echo "Usage: $0 /path/to/openises-root"
  echo "UNKNOWN"
  exit 3
fi

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

extract_version() {
  local root="$1"
  local v=""

  # 1) git tag / describe if repo metadata exists
  if command -v git >/dev/null 2>&1 && [[ -d "$root/.git" ]]; then
    v="$(git -C "$root" describe --tags --always 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)"
    if [[ -n "$v" ]]; then
      echo "$v"
      return 0
    fi
  fi

  # 2) common release/changelog/version files
  v="$(find "$root" -maxdepth 2 -type f \( -iname 'RELEASE-NOTES*' -o -iname 'CHANGELOG*' -o -iname 'VERSION*' -o -iname 'README*' \) \
      -exec grep -Eho 'v?[0-9]+\.[0-9]+\.[0-9]+' {} + 2>/dev/null | sed 's/^v//' | sort -V | tail -n1)"
  if [[ -n "$v" ]]; then
    echo "$v"
    return 0
  fi

  return 1
}

find_loader() {
  find "$1" -type f -name 'loader.php' 2>/dev/null | head -n1
}

loader_has_hardcoded_creds() {
  local f="$1"
  # Heuristics for hardcoded DB credentials or inline mysqli connection literals.
  grep -Eiq "\$(db(host|name|user|pass|password)|mysql_(host|db|user|pass|password))\s*=\s*['\"][^'\"]+['\"]" "$f" && return 0
  grep -Eiq "(new[[:space:]]+mysqli|mysqli_connect|mysql_connect)[[:space:]]*\([[:space:]]*['\"][^'\"]+['\"][[:space:]]*,[[:space:]]*['\"][^'\"]+['\"][[:space:]]*,[[:space:]]*['\"][^'\"]+['\"]" "$f" && return 0
  return 1
}

ROOT="$(cd "$TARGET" && pwd)"
LOADER="$(find_loader "$ROOT")"
VERSION="$(extract_version "$ROOT" 2>/dev/null || true)"

if [[ -z "$LOADER" ]]; then
  echo "UNKNOWN"
  echo "Reason: loader.php not found under $ROOT"
  exit 2
fi

if loader_has_hardcoded_creds "$LOADER"; then
  echo "VULNERABLE"
  echo "Reason: loader.php appears to contain hardcoded DB credential material"
  echo "Path: $LOADER"
  [[ -n "$VERSION" ]] && echo "Version clue: $VERSION"
  exit 1
fi

if [[ -n "$VERSION" ]]; then
  if ver_ge "$VERSION" "3.44.2"; then
    echo "PATCHED"
    echo "Reason: discovered version clue is $VERSION and loader.php did not match hardcoded-credential heuristics"
    exit 0
  else
    echo "VULNERABLE"
    echo "Reason: discovered version clue is $VERSION (< 3.44.2)"
    echo "Path: $LOADER"
    exit 1
  fi
fi

echo "UNKNOWN"
echo "Reason: loader.php found but no reliable version metadata was discovered and no hardcoded-credential pattern matched"
echo "Path: $LOADER"
exit 2

Sources

1. NVD CVE-2026-48241
2. Open ISES Tickets v3.44.2 release
3. Open ISES fixing commit referenced by NVD
4. Open ISES loader.php raw file at v3.44.1
5. Open ISES loader.php raw file at v3.44.2
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS API documentation
8. SourceForge Open ISES project page