CVE-2026-32287

What it actually does

The flaw is a denial-of-service condition in antchfx xpath where certain top-level Boolean XPath expressions that evaluate to true, such as `1=1` or `true()`, can cause `logicalQuery.Select` to enter an infinite loop. If an application accepts untrusted XPath selectors and evaluates them with the vulnerable library, a remote unauthenticated attacker may be able to drive a worker thread or process to 100% CPU usage. Confidentiality and integrity are not directly affected, but service availability can be severely degraded or lost depending on concurrency, timeout handling, and process isolation.

Why it matters to the business

Applications that expose XPath-based search, filtering, scraping, XML/HTML parsing, rules, or query functionality may become slow or unavailable if attackers repeatedly submit crafted Boolean XPath expressions. Because no fixed version is currently listed, organizations using this library may need compensating controls such as input validation, execution timeouts, rate limiting, and dependency monitoring until a patched release is available. The vulnerability is not currently in CISA KEV, has low EPSS, and has no known exploit maturity reported, but it is simple to trigger where user-controlled XPath input is exposed.

How an attack unfolds

An attacker first identifies an application endpoint or workflow that accepts XPath selectors, filters, scraping rules, XML/HTML extraction expressions, or similar query input. They then submit a top-level Boolean expression that evaluates to true, such as `1=1` or `true()`. When the application passes this expression to the vulnerable antchfx xpath implementation, `logicalQuery.Select` can enter an infinite loop. The affected process consumes CPU continuously, potentially blocking request handling or exhausting available worker capacity. By sending repeated requests or maintaining multiple concurrent submissions, the attacker can degrade performance or cause an outage without needing authentication, user interaction, or access to sensitive data.

How to fix it

Upgrade antchfx xpath to a patched version as soon as one is released by the maintainer. No fixed version is currently provided in the input, so teams should monitor upstream advisories, package releases, and dependency scanners for the first corrected release. Until a patch is available, avoid evaluating untrusted XPath expressions with this library. Implement strict allow-list validation for permitted selectors, reject top-level Boolean expressions, and block expressions such as `true()`, `false()`, `1=1`, and equivalent always-true predicates where they are not required. Add execution timeouts, request deadlines, context cancellation, worker isolation, CPU quotas, rate limits, and circuit breakers around XPath evaluation. If feasible, replace vulnerable evaluation paths with safer, bounded parsing logic or a maintained library that is not affected.

How to confirm the fix worked

Confirm whether the application depends on antchfx xpath through source review, dependency manifests, software composition analysis, and compiled artifact inspection. Identify any endpoints, jobs, APIs, or configuration fields that pass user-controlled or externally supplied XPath selectors into the library. In a controlled non-production environment, test representative inputs such as `true()` and `1=1` and verify that they are rejected, safely handled, or terminated by timeouts without sustained CPU consumption. After mitigation, verify that malformed or always-true XPath expressions return errors quickly, request deadlines are enforced, and repeated submissions cannot drive the process to sustained high CPU. Continue monitoring dependency scanners for an upstream fixed version and validate that the deployed build contains it once available.

Typical attack path

1. Find a public or internal application feature that accepts XPath expressions or selector-like input.
2. Test whether Boolean XPath expressions such as `1=1` or `true()` are accepted and processed.
3. Submit a crafted top-level Boolean XPath expression that evaluates to true.
4. Trigger the vulnerable `logicalQuery.Select` code path in antchfx xpath.
5. Cause one or more application workers to enter an infinite loop and consume CPU.
6. Repeat or parallelize requests to exhaust service capacity and produce a denial of service.

How to detect it

To determine whether this was already exploited, review application access logs, API gateway logs, WAF logs, reverse proxy logs, and application error/debug logs for requests containing suspicious XPath-like Boolean expressions submitted to search, filter, selector, XML, HTML, scraping, rules, or query parameters. Correlate those requests with host and container telemetry showing sudden or sustained 100% CPU usage, request latency spikes, thread saturation, autoscaling events, health-check failures, process restarts, or timeout storms. Look for repeated low-volume requests that individually cause long execution times, as well as bursts of concurrent requests using the same selector payload. If request bodies are logged, search JSON, form data, and XML payloads for `true()`, `1=1`, and similar always-true top-level XPath expressions. For deeper investigation, capture stack traces or runtime profiles during high CPU events and look for execution in antchfx xpath selector evaluation, especially `logicalQuery.Select`. Because no public exploitation or KEV listing is reported, absence of known actor-specific indicators should not be treated as proof of safety; focus detection on payload patterns and CPU-correlated behavior.

• true()
• 1=1
• selector=true()
• selector=1=1
• xpath=true()
• xpath=1=1
• query=true()
• query=1=1
• filter=true()
• filter=1=1
• logicalQuery.Select
• antchfx/xpath

What your security team should do

• Inventory all applications and services that use antchfx xpath, including transitive and vendored dependencies.
• Prioritize review of internet-facing or multi-tenant features that accept XPath, selector, XML, HTML parsing, scraping, or filtering input from users or external systems.
• Apply an upstream patched version immediately when available; until then, deploy compensating controls for validation, timeouts, rate limiting, and CPU isolation.
• Block or reject top-level Boolean XPath expressions and known always-true patterns unless there is a clear business requirement.
• Add operational monitoring for sustained high CPU, request latency spikes, worker restarts, and repeated selector parsing errors.
• Create SIEM detections for repeated submission of suspicious XPath expressions such as `true()` and `1=1` to query, filter, selector, scraping, or XML-processing endpoints.
• Perform controlled validation testing after mitigation to ensure crafted expressions cannot cause unbounded CPU consumption.
• Track upstream advisory updates because exploit maturity is currently reported as none, but the trigger condition is simple and may become weaponized if public proof-of-concept examples appear.