CVE-2026-1037: Multiple vulnerabilities affect IBM License Key Server Administration and Reporting Tool and IBM LKS Administration Agent
IBM Common Licensing Agent 9.0, Agent 9.0.0.1, Agent 9.0.0.2, ART 9.0, ART 9.0.0.1, and ART 9.0.0.2 is vulnerable to cross-site scripting. This vulnerability allows an unauthenticated attacker to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.
Other sources
The non-blocking (async) JSON parser in jackson-core bypasses the maxNumberLength constraint (default: 1000 characters) defined in StreamReadConstraints. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS). The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy. WS-2026-0003 was later assigned CVE-2026-18401.
— IBM
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
IBM Common Licensingto a version that resolves this vulnerability.Fixed in 9.1 - Compensating control
Mitigate the Web UI XSS risk by ensuring the affected IBM License Key Server Administration and Reporting Tool / IBM LKS Administration Agent web interface is not exposed to unauthenticated external users (e.g., restrict access via network/ACL or firewall to trusted clients).
- Compensating control
Mitigate DoS from the JSON async parser issue by limiting or rate-controlling requests to the affected APIs (e.g., apply throttling at the network/WAF/API gateway in front of the IBM components).
- Operational
If exploitation is suspected or occurred, rotate any credentials that may have been exposed during a trusted session after upgrading to IBM Common Licensing 9.1.
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using jackson-core's non-blocking (async) JSON parser API are exposed. The standard synchronous parser enforces the maximum number length and is not affected by this bypass.
What must an attacker be able to do to exploit it?
An attacker must be able to submit JSON to a code path that processes it with the async parser. They can use arbitrarily long numeric values to drive excessive memory allocation and CPU consumption, causing denial of service.
Are default settings sufficient to prevent the issue?
No. The default StreamReadConstraints maxNumberLength is 1000 characters, but the async parser bypasses that constraint.