A Maximo worker that exhausts memory may look like an application incident. Users report timeouts, a pod restarts, and the service recovers briefly. The security question is whether malformed ASN.1 input reached pyasn1 0.6.1. CVE-2026-23490 makes that question relevant for Maximo 8.10, 8.11, 9.0, and 9.1 deployments that include the vulnerable package.
The flaw is a denial of service in the BER decoder. Excessive continuation octets in a malformed RELATIVE-OID can drive repeated accumulation and memory exhaustion. The package is fixed in pyasn1 0.6.2. IBM's fixed Maximo releases are 8.10.35, 8.11.32, 9.0.21, and 9.1.10, with no vendor workaround.
Decide what the evidence can support
A memory spike is not proof of exploitation. It can come from a batch job, a leak, or a legitimate burst. The responder should look for convergence: unexplained memory growth, a process or container termination, a reachable certificate or ASN.1 path, and an input pattern that precedes the event. If one element is missing, keep the incident classification conditional.
Do not label a confirmed outage as a confirmed attack. The article and incident record should distinguish a vulnerable deployment, a suspicious input, and a verified security event. That vocabulary keeps technical evidence separate from speculation.
Contain the input path
The first operational decision is whether the suspected input can be stopped without causing more harm. A public certificate endpoint might be restricted to known clients. A queue consumer might be paused. A partner integration might be routed through a temporary maintenance response. The service owner should choose a control that blocks the suspected path without disabling unrelated Maximo functions.
Every containment action needs a rollback step. A network rule that is too broad can break identity federation or administrative access. A queue pause can create a backlog that replays the malicious object after recovery. Record the change, the scope, and the person who approved it.
Preserve bounded evidence
Capture the memory curve, container termination reason, restart count, relevant service logs, deployment digest, and the request or queue context around the event. Treat certificates, tokens, and encoded identity data as sensitive. Do not copy full payloads into chat or broad incident channels when metadata is enough for triage.
If the payload is needed for analysis, place it in an access-restricted evidence location and record who handled it. Preserve the exact package version and image digest. A later reviewer should be able to connect the affected time window to the running artifact.
Recover with the fixed release
The durable response is to deploy the fixed Maximo release for the installed branch and verify pyasn1 0.6.2 or the vendor-corrected equivalent in the running workload. Restarting the old container may restore service, but it leaves the same parser reachable.
Before restoring traffic, test the certificate or ASN.1 workflow that could reach the decoder. Check that malformed input is rejected without sustained memory growth. Confirm that queues do not replay the triggering object into the newly started service. The recovery decision should include the application owner, platform operator, and security responder.
Review the wider estate
A single restart can reveal a product-wide inventory gap. Search for other Maximo deployments on the same affected branches. Review components that accept external certificates or BER data. Use public product matches such as the 673 results from a title="IBM Maximo" ZoomEye Search as a discovery prompt, not as a vulnerability list. The CVE Filter returned 0 in the same observation, so internal version and reachability evidence remains essential.
After recovery, document the timeline and the limits of the evidence. If the team cannot determine whether hostile input caused the event, say so. The outcome can still be a completed remediation without an unsupported attribution.
Close the incident on verifiable facts
The closure record should show the affected Maximo branch, the running image after recovery, the package version, the containment changes that remain, the tests performed, and the owner for any residual risk. If the service was exposed during the incident, review authentication and gateway logs for related input attempts without assuming they succeeded.
CVE-2026-23490 is an availability flaw with a concrete fix. The response should remove the vulnerable parser, restore service deliberately, and keep the difference between exposure, suspicious behavior, and confirmed exploitation visible to everyone using the record.