HCL BigFix Has a 9.8 SQL Injection — Cross-Tenant PII Is at Risk

• The Mess: HCL BigFix Service Management has a fresh SQL injection and cross-tenant data exposure flaw rated CVSS 9.8. The bug can expose sensitive system information and personal data belonging to other organizations.
• The Damage: One vulnerable service-management instance can become a database extraction point and potentially break the isolation boundary between tenants.
• The Fix: Check HCL’s security bulletin for CVE-2026-67100 and apply the vendor-provided remediation for affected BigFix Service Management V23 deployments.

HCL BigFix Service Management has just picked up a vulnerability that combines two things security teams really do not want to see together: SQL injection and cross-tenant data exposure.

The issue is tracked as CVE-2026-67100, published on September 18, 2026, with a CVSS 3.1 score of 9.8 — Critical. HCL is listed as the CNA responsible for the CVE. The affected product is HCL BigFix Service Management V23.

The vulnerability is mapped to:

• CWE-89 — SQL Injection
• CWE-200 — Exposure of Sensitive Information

The combination matters more than the CVSS number itself.

This is not merely a database bug where an attacker might retrieve one application’s records.

The CVE description specifically mentions the possibility of manipulating request values to obtain personal-profile information and PII belonging to other organizations.

The SQL injection is only half the story

SQL injection is old.

Painfully old.

Applications have been breaking because developers concatenate untrusted input into database queries for decades.

But CVE-2026-67100 adds another layer.

According to the published vulnerability description, an attacker may be able to inject database commands to extract sensitive system information and manipulate request values to access personal-profile data and PII across organizational boundaries.

That means defenders should think about two separate questions:

Can the attacker manipulate database queries?

And:

Can the attacker manipulate the application-level tenant context?

The second question is arguably more interesting.

A SQL injection can expose data inside one application’s database. A tenant-isolation failure can turn that into a multi-organization confidentiality problem.

Cross-tenant access is the ugly part

BigFix Service Management can handle service-management data across organizational environments.

That makes tenant isolation an important security boundary.

If an application trusts request parameters to determine which organization or profile should be returned, manipulating those values can become much more serious than ordinary unauthorized record access.

The CVE description explicitly states that request manipulation could provide access to full personal profiles and PII across different organizations.

The public CVE material does not currently disclose the vulnerable endpoint, exact parameter, database engine, query construction or a reliable exploit sequence.

That’s worth stating clearly.

There is enough information to understand the impact.

There isn’t enough public technical detail to responsibly publish a working exploit recipe.

There is an annoying CVSS contradiction

The published description says the vulnerability could be exploited by an authenticated attacker.

But the CVSS vector is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

The important part is:

PR:N

That means Privileges Required: None.

Several vulnerability databases reproduce the same discrepancy.

So which one should administrators believe?

For now, neither interpretation should be stretched beyond the available evidence.

The safest technical reading is:

HCL’s published description mentions authentication, while the CNA-assigned CVSS vector says no privileges are required.

Until HCL clarifies the precise precondition, defenders should not downgrade the issue simply because they assume an existing account is mandatory.

That’s particularly important for internet-facing deployments.

CVSS 9.8 tells us what the potential impact looks like

The vector gives:

• AV:N — Network
• AC:L — Low complexity
• PR:N — No privileges required
• UI:N — No user interaction
• S:U — Unchanged scope
• C:H — High confidentiality impact
• I:H — High integrity impact
• A:H — High availability impact

So the assigned model describes a remotely reachable vulnerability with low complexity and high impact across confidentiality, integrity and availability.

Again, CVSS is not proof that all three impacts have been demonstrated in the wild.

It is the severity model attached to the vulnerability.

What an attacker would actually want

Forget the Hollywood version of SQL injection.

An attacker doesn’t necessarily need to “take over the server.”

The valuable target may simply be the database.

If the application processes:

• customer profiles;
• employee information;
• tickets;
• organizational records;
• service requests;
• account metadata;
• internal system information;

then unauthorized database access can already be enough to create a serious incident.

And if tenant boundaries are enforced partly through application logic, manipulating identifiers becomes particularly interesting.

A successful attack could potentially move from:

one legitimate request

to:

another organization’s data

without the victim organization ever interacting with the attacker’s account.

That’s the cross-tenant problem.

No public exploit has been confirmed

At the time of publication, there is no reliable evidence in the sources reviewed of confirmed exploitation of CVE-2026-67100.

It is also not currently listed in the CISA Known Exploited Vulnerabilities catalog according to the vulnerability tracking data reviewed.

That status can change.

The CVE was published today.

There is therefore a very small amount of historical data available for judging exploitation.

The absence of a public PoC should be treated as current status, not as a security guarantee.

HCL disclosed more than one BigFix problem

CVE-2026-67100 is not the only BigFix Service Management vulnerability appearing in the current CVE stream.

The same product has also received:

• CVE-2026-67101 — SSRF;
• CVE-2026-67102 — improper access control;
• CVE-2026-67103 — XSS.

There are additional BigFix Service Management security records in the current database feed as well.

That changes the patching strategy.

Administrators should not treat CVE-2026-67100 as an isolated defect and then stop.

If the deployment is affected, review the complete HCL security bulletin and determine which additional BigFix Service Management vulnerabilities apply to the same installation.

What defenders should inspect

Before and after remediation, review application and database telemetry.

Look for:

• unusual requests containing unexpected tenant or organization identifiers;
• users accessing records outside their normal organization;
• sudden increases in profile-data retrieval;
• database errors correlated with unusual request parameters;
• abnormal query volume;
• unexpected access to large numbers of personal records;
• requests originating from unfamiliar networks;
• unusual API activity;
• service accounts accessing data outside their normal scope.

One particularly useful signal is cross-tenant access.

If a user normally works with organization A but suddenly requests records associated with organizations B, C and D, that deserves investigation.

It is not proof of exploitation.

It is a useful anomaly.

Don’t try to “fix” SQL injection with keyword blocking

A common emergency response is to throw a WAF rule at SQL keywords.

UNION.

SELECT.

OR 1=1.

And then everybody goes home.

Don’t.

Generic SQL keyword filtering is not a reliable fix for an application vulnerability.

Encoding, alternative syntax and application-specific query behavior can make simplistic filters ineffective.

If HCL provides a vendor fix, use it.

If the patch cannot be applied immediately, reduce exposure instead:

• restrict network access;
• place the service behind an approved access gateway;
• limit administrative interfaces;
• reduce unnecessary accounts;
• review tenant permissions;
• monitor database access;
• preserve logs for retrospective analysis.

Those are compensating controls.

They do not remove the vulnerable code.

The PII problem is bigger than the SQLi

A normal SQL injection incident can already trigger regulatory headaches.

Cross-tenant PII exposure makes the situation worse.

If records belonging to another organization become accessible, the incident-response process potentially moves beyond vulnerability management.

Organizations may need to determine:

1. whether unauthorized access occurred;
2. which tenants were affected;
3. what records were exposed;
4. whether data was modified;
5. whether data was exported;
6. how long the exposure existed;
7. which identities performed the activity.

That requires logs.

Not screenshots.

Not assumptions.

Logs.

Preserve them before retention policies rotate potentially useful evidence.

Patch first, investigate second — but don’t forget the logs

For a critical vulnerability, remediation should not wait for a complete forensic investigation.

At the same time, blindly patching and deleting evidence is another classic mistake.

A sensible sequence is:

1. Identify affected BigFix Service Management V23 deployments.

2. Obtain HCL’s current remediation guidance for CVE-2026-67100.

3. Restrict unnecessary external access while remediation is being prepared.

4. Preserve relevant application, authentication and database logs.

5. Apply the vendor-provided update or fix.

6. Verify tenant isolation after remediation.

7. Review historical access for suspicious cross-tenant activity.

8. Investigate and escalate any confirmed unauthorized data access.

The exact fixed version should come from HCL’s security bulletin rather than from third-party CVE aggregators.

Bugstoday’s take

CVE-2026-67100 isn’t interesting because SQL injection is exotic.

It isn’t.

It’s interesting because SQL injection plus cross-tenant PII exposure is a nasty combination for a service-management platform.

The public disclosure is still thin, and the authentication requirement currently doesn’t line up cleanly with the CVSS PR:N vector. That uncertainty is a reason to verify HCL’s advisory, not a reason to ignore the vulnerability.

If you run BigFix Service Management V23, this belongs on the patch queue now.

And while you’re there, check the other BigFix Service Management CVEs published alongside it.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• HCL Software — Security Bulletin KB0133782 for HCL BigFix Service Management.
• MITRE/CVE — CVE-2026-67100.
• NVD — CVE-2026-67100.
• CISA Known Exploited Vulnerabilities Catalog — exploitation-status check.