CVE-2026-102278 can terminate a Node.js process that expands a deeply nested brace pattern. IBM identifies QRadar SOAR 51.0.7 through 51.0.11 as affected and names 51.0.11.2 as the fixed release.

The patch itself is a vendor upgrade, but a controlled change needs evidence, a rollback point, and validation after deployment. This plan keeps those steps explicit.

Vulnerability overview

The GitHub advisory rates the flaw High with CVSS 3.1 score 7.5. Red Hat records 6.5 with user interaction. IBM uses 7.5. The impacted property is availability; the reviewed sources do not describe code execution or data disclosure.

Affected brace-expansion ranges are below 1.1.20, 2.0.0 through below 2.1.6, 3.0.0 through below 3.0.8, and 4.0.0 through below 5.0.11. Fixed releases are 1.1.20, 2.1.6, 3.0.8, and 5.0.11.

Before the change

Record the current QRadar SOAR build. IBM lists several affected versions and also prints 51.06, so preserve the exact product string and resolve any ambiguity with the installed system or vendor documentation.

Export the configuration required for recovery under the vendor procedure. Identify dependent integrations, automation jobs, and notification paths that could be affected by a restart. Note their owners and verification steps.

Build an asset list from both product records and network measurements. A ZoomEye Search for app="IBM QRadar" returned 628 application-fingerprint matches. The CVE Filter returned 0. Exposure is 628, but that figure does not prove any host is running a vulnerable or reachable QRadar SOAR build.

Change design

Use IBM's documented upgrade path to 51.0.11.2. IBM states that no workaround is available. Schedule the update with enough time to validate case handling and integrations before returning the platform to normal use.

If other Node.js services are in scope, update brace-expansion to a fixed release and rebuild their images in the same change window or a separately controlled one. Do not mix unverified dependency overrides with the product upgrade.

Validation

After the upgrade, confirm the QRadar SOAR build identifier. Test case creation, enrichment, automation, and notification paths that matter to the deployment. Verify that background workers start and remain stable.

For Node.js components, inspect the running artifact for the package version and image digest. Run a safe fixture with deeply nested comma-member and single-set patterns under a hard timeout. On the fixed build, the expansion should remain bounded and the process should stay alive.

The fixing commit uses a maximum depth of 1,000 and returns deeper groups literally. Test ordinary patterns as well, because a fix that blocks normal workflow patterns is not a successful operational change.

Rollback

Keep the previous image, build artifact, and configuration backup available for the vendor-supported rollback window. Document the exact conditions that trigger rollback, such as failed startup, broken enrichment, or repeated worker termination.

If rollback is necessary, restore the supported product state and record the failed upgrade evidence. Do not claim that the vulnerability is fixed based on a partially installed package. Reopen the change and keep compensating input controls in place.

Monitoring and closure

Monitor for unexpected Node.js process exits, worker restarts, failed automation jobs, and gaps in case processing. Correlate anomalies with the deployment timeline and pattern-submission activity. The reviewed sources do not provide indicators of compromise, so alerts should focus on availability symptoms and reachability.

Close the change when the product build is verified, dependent services are healthy, deployed package evidence is collected, and the nested-pattern regression test passes. Attach the exact asset scope and retain the ZoomEye measurement as supporting context.

References