Security teams can publish a CVE notice quickly. The harder task is proving that every affected service has a named owner, a supported fix, and a tested recovery path. CVE-2026-23490 deserves that treatment because the vulnerable pyasn1 0.6.1 package sits inside IBM Maximo Application Suite, where platform, application, and identity teams may each control part of the exposure.
IBM lists Maximo 8.10, 8.11, 9.0, and 9.1 as affected. The fixed releases are 8.10.35, 8.11.32, 9.0.21, and 9.1.10. The library fix is pyasn1 0.6.2, and IBM reports no workaround. These are the minimum facts a service-owner checklist must preserve.
Name the accountable service
A cluster name is not an owner. The checklist should identify the business service, the Maximo deployment, the OpenShift namespace, the running image, and the team accountable for availability. It should also name a technical contact for certificate handling or integrations, because those teams may know which components decode untrusted ASN.1 data.
Ownership needs to cover non-production systems that can still affect production. A certificate-testing environment may trust the same external partners or share integration credentials. It should not disappear from the inventory simply because its business criticality is lower.
Record vulnerability evidence
The evidence set should show the affected branch, the running suite version, the image digest, the pyasn1 version, and the reason the parser path is considered reachable or unreachable. A package scanner result can be attached, but it does not replace the runtime record. A title match from an internet search can be attached as context, but it does not prove that a host is vulnerable.
The ZoomEye observations for this topic provide an example of careful labeling. Search for title="IBM Maximo" returned 673 product-title matches. The CVE Filter returned 0. The larger successful count is Exposure, but the description must say that these are product fingerprint matches, not confirmed vulnerable systems.
Assign the fix and the test
For each affected service, the owner should record the required target: 8.10.35, 8.11.32, 9.0.21, or 9.1.10. Add the approved change record, maintenance window, deployment date, and rollback plan. The plan should preserve the fixed image during rollback.
The test should exercise the certificate or ASN.1 workflow that could reach pyasn1. A login test alone is not enough. Where practical, validate malformed input handling, memory behavior, and queue recovery. Record who performed the test and what evidence was retained.
Make temporary controls explicit
While the update is pending, the service owner may restrict access to the parser path, limit the caller set, or apply request controls. Each item needs a reason, an owner, an expiry date, and a closure condition. A control that is not tested is an assumption, not evidence.
IBM says no workaround exists. The checklist should reflect that statement. Access controls can reduce the chance that an attacker reaches the vulnerable decoder, but they do not repair it. They should never be marked as the permanent resolution.
Account for residual risk
Some deployments may have a blocker that prevents immediate movement to the fixed release. The record should state the blocker, the affected business function, the exposure window, the compensating controls, and the date of the next decision. Risk acceptance belongs to the accountable owner, not to an unnamed security team.
Residual risk should also cover detection limits. There is no published universal signature for this resource-exhaustion path. The service owner should document what monitoring is available, how memory and restart events are reviewed, and what evidence would trigger escalation.
Verify closure centrally
A central register can track the same fields across deployments: service, owner, branch, fixed target, runtime image, package version, reachability, test result, deployment date, and residual risk. The register should be reconciled with the vulnerability scanner and the application inventory rather than treated as a separate reporting exercise.
When a service closes the item, verify the deployed artifact, not just the change ticket. The running workload should show the corrected Maximo release and package. The test record should show the relevant parser workflow. If either is missing, the status remains open or explicitly conditional.
Keep the language precise
Exposure is not exploitation. A product match is not a vulnerable host. A CVSS score is not a confirmed business outage. The checklist works when it forces those distinctions into the evidence record and still gives the owner a clear action: identify the branch, reach the fixed release, test the parser path, and document the residual risk.
CVE-2026-23490 is manageable with a supported update. The value of the checklist is that the update reaches the actual running workload and leaves evidence strong enough for the next responder to trust.