Leaving the master key under the doormat, but only tenants who already live in the building can grab it
CVE-2026-67100 bundles two flaws in HCL BigFix Service Management V23: a classic SQL injection (CWE-89) that lets an authenticated user run arbitrary database commands and extract sensitive system internals, and a cross-tenant data exposure flaw (CWE-200/CWE-284) that lets one tenant's user manipulate request identifiers to pull full PII and personal profile data belonging to *other* organizations hosted on the same instance. Together, these turn any low-privilege seat into a data-exfiltration vector across tenant boundaries.
HCL scored this a 9.8 CRITICAL using CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, but the advisory's own description states the attacker must be *authenticated*. That makes PR:N a misclassification — the correct privileges-required value is at least PR:L, which by itself drops the CVSS to ~8.8. Factor in the narrow installed base of BigFix SM (a niche ITSM competitor to ServiceNow and Jira SM), the absence of any public proof-of-concept, zero KEV listing, and no confirmed in-the-wild exploitation, and the effective risk for most enterprises falls to HIGH, not CRITICAL. That said, for MSPs and shared-hosting operators running multi-tenant BigFix SM, the cross-tenant PII leak is a genuinely dangerous finding that warrants urgent action.
4 steps from start to impact.
Obtain valid BigFix SM credentials
- Valid BigFix SM user account on the target instance
- Network access to the BigFix SM web interface (typically HTTPS/443)
- BigFix SM portals are rarely exposed to the public internet — most deployments sit behind VPN or corporate network boundaries
- MFA on the SM login portal blocks credential-spray and phished-password scenarios
- The product's relatively small market share means fewer attacker tools and playbooks target it specifically
Identify injectable parameter
- Authenticated session from Step 1
- Knowledge of or ability to fuzz SM API/form endpoints
- No public exploit code or Nuclei template exists as of disclosure date
- Web Application Firewalls (WAFs) with SQL injection rule sets will catch many common injection patterns
- Without a known parameter, discovery requires non-trivial effort
', UNION, SELECT, --); database slow-query or error logs showing malformed queriesExtract sensitive data via SQL injection
UNION SELECT or error-based/blind injection payloads to enumerate database schemas, extract credentials, configuration secrets, and tenant data. Because BigFix SM stores ITSM ticket data, asset records, and user PII, the database is a rich target. The attacker can also target internal system tables to harvest database credentials or escalate within the DB tier.- Confirmed injectable parameter from Step 2
- Database user context used by the application has read access to sensitive tables
- Database-level least-privilege (if the app DB user is read-only on its own schema) limits lateral movement within the DB
- Parameterized query enforcement at the ORM layer may protect some endpoints even if others are vulnerable
INFORMATION_SCHEMA queries or bulk SELECT across tenant tables; DLP alerts on large data exports from SMCross-tenant PII exfiltration
- Authenticated session
- Multi-tenant deployment (MSP or shared-hosting model)
- Single-tenant deployments are not affected by the cross-tenant component
- Organizations using dedicated BigFix SM instances per business unit eliminate this vector entirely
UNION SELECT, ' OR 1=1, stacked queries). Deploy within 30 days per the noisgate mitigation SLA.INFORMATION_SCHEMA or cross-database queries. This limits SQLi blast radius even if injection succeeds.- Network segmentation between SM and BigFix Platform servers — while good hygiene, it does not prevent SQLi or cross-tenant data access within SM's own database. The vulnerability is application-layer, not network-layer.
- Endpoint Detection and Response (EDR) — EDR agents on the SM server won't detect SQL injection; it's valid HTTP traffic that abuses application logic. EDR only helps if the attacker pivots to OS-level post-exploitation after extracting DB credentials.
- Patching the BigFix Platform agent/server — BigFix Service Management is a separate product from BigFix Platform. Patching the endpoint-management stack does not remediate the SM vulnerability.
The supporting signals.
| In-the-Wild Exploitation | No confirmed exploitation as of 2026-09-18. Not listed in CISA KEV. No threat-intelligence vendor (Mandiant, CrowdStrike, Unit 42) has reported active campaigns. |
|---|---|
| Proof-of-Concept | None public. No GitHub repos, no Nuclei templates, no Metasploit modules. The SQLi is described generically — no specific parameter or endpoint has been disclosed. |
| EPSS Score | Not yet scored. CVE was published 2026-09-18 (today). EPSS typically populates within 24–72 hours of NVD ingestion. |
| KEV Status | Not listed in CISA KEV catalog as of 2026-09-18. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — 9.8 CRITICAL per vendor. However, the advisory states *authenticated attacker*, which contradicts PR:N. Corrected to PR:L the score drops to ~8.8. |
| Affected Versions | HCL BigFix Service Management V23 (all builds prior to the fix referenced in KB0133782). Specific sub-version ranges not disclosed by HCL. |
| Fixed Version | Patch referenced in HCL KB0133782, published 2026-09-18. Exact version string not publicly enumerated; check the KB article with your HCL support entitlement. |
| Internet Exposure | Minimal. BigFix Service Management is an internal ITSM portal. Shodan/Censys/FOFA show negligible public-facing instances. The vast majority of deployments sit behind VPN or corporate firewalls. |
| Disclosure Date | 2026-09-18 (coordinated disclosure by HCL Software). |
| Reporter | Not publicly attributed. HCL's security bulletin does not credit an external researcher. |
Sources.
Why this verdict
- CVSS vector mismatch (PR:N → PR:L): The advisory explicitly states 'authenticated attacker,' yet the CVSS vector claims no privileges required. Correcting to
PR:Lalone drops the base score from 9.8 to ~8.8. This is the single largest scoring error. - Narrow installed base: BigFix Service Management is a niche ITSM product competing with ServiceNow, Jira SM, and BMC Helix. It manages 155M+ endpoints as a *platform* family, but the Service Management module has a small fraction of that footprint. Fewer targets means fewer real-world attack opportunities.
- No exploit availability: Zero public PoCs, no Metasploit/Nuclei modules, no named researchers. Weaponization requires original vulnerability research against a relatively obscure codebase, raising the practical bar significantly.
- Role multiplier: BigFix *Service Management* is a ticketing and workflow tool — a line-of-business application (role b). It is not the BigFix endpoint-management agent/server that controls patching across fleets. Compromise of SM yields ITSM ticket data and user PII, not remote code execution on managed endpoints. The blast radius is *tenant-level data exposure*, not fleet compromise. For MSPs running multi-tenant instances, the cross-tenant PII leak elevates risk within that deployment model, but does not reach domain-takeover or supply-chain-pivot scale. This keeps the floor at HIGH, not CRITICAL.
- Internet exposure near zero: BigFix SM is deployed as an internal portal. Scanner data (Shodan/Censys) shows negligible public exposure, meaning attackers must already have internal network access or VPN credentials before reaching the login page — an additional friction layer not captured in the CVSS vector.
Why not higher?
The vulnerability cannot remain CRITICAL because the CVSS vector's PR:N is contradicted by the advisory's own requirement for authentication, no public exploit exists, the product has a small installed base, and the blast radius is limited to data within the ITSM platform rather than fleet-scale code execution. Even for multi-tenant MSP deployments where cross-tenant PII exposure is serious, the chain does not escalate to domain takeover, supply-chain pivot, or infrastructure compromise — it stays at data exposure scope.
Why not lower?
SQL injection with cross-tenant data exposure in a product that stores PII and ITSM records across organizations is a genuine privacy and compliance hazard. The authentication barrier lowers the bar but does not eliminate it — any employee with an SM account is a potential insider threat vector. The SQLi component could yield database credentials or configuration secrets that enable lateral movement beyond the SM tier. For MSPs, the cross-tenant angle makes this a contractual and regulatory emergency (GDPR, SOC 2 tenant-isolation controls). These factors establish a firm HIGH floor.
Crowdsourced verification payload.
Run this script on the BigFix Service Management application server (or any host with curl and network access to SM). Invoke as: sudo bash check_cve_2026_67100.sh https://bigfix-sm.corp.local. Requires curl and read access to the SM installation directory if checking locally. No authentication needed for the version-file check path.
#!/usr/bin/env bash
# check_cve_2026_67100.sh — Detect CVE-2026-67100 in HCL BigFix Service Management
# Usage: bash check_cve_2026_67100.sh [SM_BASE_URL]
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
SM_URL="${1:-}"
RESULT="UNKNOWN"
# Method 1: Check version via SM API/about endpoint
if [[ -n "$SM_URL" ]]; then
echo "[*] Checking BigFix SM version at $SM_URL ..."
VERSION=$(curl -sk --max-time 10 "${SM_URL}/api/v1/version" 2>/dev/null \
| grep -oP '"version"\s*:\s*"\K[^"]+' || true)
if [[ -z "$VERSION" ]]; then
VERSION=$(curl -sk --max-time 10 "${SM_URL}/about" 2>/dev/null \
| grep -ioP 'version[:\s]+\K[0-9]+\.[0-9]+\.[0-9]+[^\s<"]*' | head -1 || true)
fi
if [[ -n "$VERSION" ]]; then
echo "[*] Detected version: $VERSION"
# HCL has not published exact fixed sub-version; flag all V23.x as potentially vulnerable
if echo "$VERSION" | grep -qP '^23\.'; then
echo "[!] Version $VERSION is in the affected V23 range."
echo "[!] Check HCL KB0133782 to confirm if your exact build includes the fix."
RESULT="VULNERABLE"
else
echo "[+] Version $VERSION does not appear to be in the affected V23 range."
RESULT="PATCHED"
fi
else
echo "[?] Could not retrieve version from $SM_URL. Trying local file check..."
fi
fi
# Method 2: Local file version check (run on SM app server)
if [[ "$RESULT" == "UNKNOWN" ]]; then
INSTALL_DIRS=("/opt/hcl/bigfix-sm" "/opt/BigFix/SM" "/usr/local/bigfix-sm")
for DIR in "${INSTALL_DIRS[@]}"; do
if [[ -d "$DIR" ]]; then
echo "[*] Found installation at $DIR"
VERFILE=$(find "$DIR" -maxdepth 3 -name 'version*.properties' -o -name 'build.info' 2>/dev/null | head -1)
if [[ -n "$VERFILE" ]]; then
echo "[*] Version file: $VERFILE"
cat "$VERFILE"
if grep -qiP '23\.' "$VERFILE"; then
RESULT="VULNERABLE"
echo "[!] VULNERABLE — V23 detected. Verify patch status against KB0133782."
else
RESULT="PATCHED"
echo "[+] PATCHED — version outside affected range."
fi
fi
break
fi
done
fi
if [[ "$RESULT" == "UNKNOWN" ]]; then
echo "[?] UNKNOWN — Could not determine BigFix SM version."
echo " Manually verify against HCL KB0133782."
exit 2
elif [[ "$RESULT" == "VULNERABLE" ]]; then
echo "VULNERABLE"
exit 1
else
echo "PATCHED"
exit 0
fi