GLPI is a free asset and IT management software package

CVE-2026-40108 is a stored XSS in GLPI ITIL Costs on the 11.0 branch, affecting 11.0.0 through 11.0.6 and fixed in 11.0.7. The attacker plants script in a cost-related field tied to tickets or changes; when another user later opens the affected view, the browser executes attacker-controlled JavaScript in that user's GLPI session.

GLPI labels this issue High, but there is no published vendor CVSS score. For enterprise triage, this behaves more like a post-initial-access admin-console abuse bug than a perimeter emergency: the attacker needs a technician-level authenticated foothold to seed the payload, the victim must hit the right page, and the blast radius depends on which privileged user views it. That is why this is = ASSESSED AT MEDIUM, even though the technical impact can become serious after successful session riding.

Why this verdict

• Start from High technical impact: stored XSS inside a trusted ITSM/admin plane can absolutely become admin action replay, token theft, or sensitive ticket/data exposure.
• Down one notch for attacker position: the chain requires an authenticated technician-equivalent account to plant the payload, which implies prior compromise, insider access, or credential theft before the CVE even starts to matter.
• Down again for reachability: only the 11.0 branch is implicated, and the exploit still needs the right victim to open the right poisoned record, adding UI friction and reducing real-world execution rate.
• No exploitation amplifier: there is no KEV listing, no public campaign reporting, and no public PoC located, so there is no evidence-based reason to treat this as a hot exploit queue item.
• Blast radius is role-bound: XSS inherits whatever the viewing user can do in GLPI; if the viewer is low-privilege, the payoff is limited, and even with higher privilege it remains an application-session compromise, not immediate host takeover.

Why not higher?

This is not an unauthenticated internet exploit, not a direct server compromise, and not a universally reachable workflow. Requiring a technician-level foothold plus a second user interaction step creates compound friction that should keep it out of the HIGH bucket for most 10,000-host enterprises.

Why not lower?

It still sits inside a management plane that holds sensitive asset, ticket, and workflow data, and stored XSS in that context is more than cosmetic. If a privileged operator or admin regularly reviews cost-bearing tickets or changes, the attacker can convert one compromised technician account into broader GLPI control.

1. Restrict ITIL cost editing — Limit who can create or modify ITIL Costs to the smallest operational group possible, ideally finance-specific or senior service-management roles. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this permission trim is cheap risk reduction and should be done during your normal role-review cycle well before patch completion.
2. Put GLPI behind stronger identity controls — Require SSO and MFA for all technician and admin profiles, or at minimum restrict GLPI administration to VPN or trusted network paths. This directly attacks the most important prerequisite: getting the authenticated technician foothold in the first place; with no mitigation SLA on a MEDIUM item, fold it into your standard hardening backlog while still patching within the remediation window.
3. Harden session cookies and browser trust — Set PHP/GLPI session protections such as session.cookie_httponly=On, session.cookie_secure=On, and sane SameSite behavior so XSS has a harder time stealing reusable session material. This will not stop all in-session action riding, but it meaningfully reduces the easiest post-exploitation win and should be deployed as standard hygiene before the 365-day remediation deadline.
4. Review GLPI profile sprawl — Audit who actually has technician or elevated service-desk roles and remove stale access, shared accounts, and generic break-glass profiles. Because this CVE only matters after authenticated write access is obtained, entitlement cleanup is one of the highest-return compensating controls you can deploy during the normal remediation cycle.
5. Watch for suspicious script-bearing content — Add log or database review for cost fields containing <script>, onerror=, javascript:, encoded payloads, or abnormal HTML. This is detective control only, not prevention, but it can catch abuse attempts while you move toward the patch inside the 365-day remediation window.

Run this on the GLPI application host or in the container/VM where GLPI files live. Invoke it as bash verify-cve-2026-40108.sh /var/www/glpi or pass an explicit version string like bash verify-cve-2026-40108.sh 11.0.6; it needs only read access to the GLPI directory and the ability to execute php if you want automatic version detection from bin/console.

#!/usr/bin/env bash
# verify-cve-2026-40108.sh
# Checks whether a GLPI instance is vulnerable to CVE-2026-40108
# Affected: 11.0.0 through 11.0.6
# Fixed:    11.0.7+
# Not affected for this CVE: 10.x branch per vendor bulletin context
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=USAGE

set -u

TARGET="${1:-}"

usage() {
  echo "Usage: $0 <glpi_root_path|version>"
  exit 3
}

if [[ -z "$TARGET" ]]; then
  usage
fi

trim() {
  local s="$1"
  s="${s#${s%%[![:space:]]*}}"
  s="${s%${s##*[![:space:]]}}"
  printf '%s' "$s"
}

extract_version() {
  local input="$1"
  local root console_out ver

  # If caller passed a plain version, use it directly.
  if [[ "$input" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
    echo "$input"
    return 0
  fi

  root="$input"

  if [[ ! -d "$root" ]]; then
    return 1
  fi

  # Best effort 1: Symfony/GLPI console version output.
  if [[ -x "$root/bin/console" || -f "$root/bin/console" ]]; then
    if command -v php >/dev/null 2>&1; then
      console_out="$(php "$root/bin/console" --version 2>/dev/null || php "$root/bin/console" -V 2>/dev/null || true)"
      ver="$(printf '%s\n' "$console_out" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1 || true)"
      if [[ -n "$ver" ]]; then
        echo "$ver"
        return 0
      fi
    fi
  fi

  # Best effort 2: parse known GLPI diagnostic artifacts/logs for GLPI_VERSION.
  ver="$(grep -RhoE 'GLPI_VERSION[:=][[:space:]]*"?[0-9]+\.[0-9]+\.[0-9]+' "$root" 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1 || true)"
  if [[ -n "$ver" ]]; then
    echo "$ver"
    return 0
  fi

  return 1
}

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

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

VERSION="$(extract_version "$TARGET" || true)"
VERSION="$(trim "$VERSION")"

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN: could not determine GLPI version from '$TARGET'"
  exit 2
fi

# Branch logic.
case "$VERSION" in
  10.*)
    echo "PATCHED: GLPI $VERSION is not in the affected 11.0 branch for CVE-2026-40108"
    exit 0
    ;;
  11.*)
    if ver_ge "$VERSION" "11.0.0" && ver_lt "$VERSION" "11.0.7"; then
      echo "VULNERABLE: GLPI $VERSION is within the affected range 11.0.0-11.0.6"
      exit 1
    elif ver_ge "$VERSION" "11.0.7"; then
      echo "PATCHED: GLPI $VERSION is fixed for CVE-2026-40108"
      exit 0
    else
      echo "UNKNOWN: GLPI $VERSION is on 11.x but could not be classified"
      exit 2
    fi
    ;;
  *)
    echo "UNKNOWN: unrecognized GLPI version '$VERSION'"
    exit 2
    ;;
esac

Sources

1. GLPI official release note for 11.0.7 / 10.0.25
2. GLPI GitHub releases
3. CERT-FR advisory CERTFR-2026-AVI-0551
4. Feedly CVE tracking page
5. Zero Redgem CVE index entry
6. ITčko summary of GLPI 11.0.7 security fixes
7. GLPI Help Center CLI documentation
8. GLPI issue showing security recommendations for HttpOnly/Secure cookies