Post-patch verification for CVE-2026-6322 in OpenShift Container Platform
An upgrade ticket can close before the risk is gone. CVE-2026-6322 affects OpenShift Container Platform and the fast-uri package that applications can bundle independently. Verification needs two tracks: the platform release and the workload image.
The vulnerability allows percent-encoded authority delimiters in a host to be decoded during normalization and emitted as raw separators. A later parser can then interpret a different host. A host allowlist, redirect validator, or outbound router that trusts the normalized authority can be bypassed.
Verify the platform track
Red Hat lists OpenShift Container Platform 4.20, 4.21, and 4.22 as affected. The fixed releases are 4.20.27, 4.21.22, and 4.22.3. Confirm the cluster version after the supported update process completes. A successful command submission is not the same as a completed control-plane and worker rollout.
Check the cluster version object, update history, operator health, and any open alerts. Retain the before-and-after version evidence. If the cluster uses an extended update process, record the maintenance window and any components that remained on the prior release.
The Red Hat errata fix platform packages and images. They do not inventory every custom image that runs on the platform. The second track is therefore necessary even when the cluster version is correct.
Verify the application track
For each application image that includes Node.js, inspect the resolved fast-uri version. The affected ranges are 3.0.0 through 3.1.1 and versions up to 2.4.0. Patched versions are 3.1.2 and 2.4.1. Rebuild the image after the lockfile changes so the running digest reflects the intended dependency.
Record the image digest, package manager, resolved version, and deployment time. If a platform-provided base image was updated, still check whether the application build copied an older lockfile or dependency layer into the final image.
Applications without a direct dependency can still contain a transitive copy. Use the resolved graph or SBOM rather than reading only package.json. A clean direct dependency list is not proof of a clean image.
Test the security decision
A patched library removes the known malformed normalization behavior. The application still needs a URL trust test. Use a controlled allowlist host and a separate test destination. Submit a URL with %40 or %3A in the host and confirm that the final transport request is rejected or sent only to the approved destination.
Test redirects separately from direct requests. A redirect location can become a new authority decision after the first connection. The test should record the actual host, scheme, and port used by the client, not only the value returned by the first parser.
If the application supports userinfo, define that support explicitly. Most outbound URL consumers do not need it. Rejecting userinfo and encoded authority delimiters in host positions reduces the chance of a second-parse mismatch.
Review logs and change records
Search application logs for requests that contain percent-encoded delimiters in a URL authority. A log entry alone does not prove exploitation, but it can identify systems that accept unusual URL forms. Preserve the original input, the normalized value, and the final destination when the application records them.
Review recent changes to URL validation, HTTP client libraries, and redirect handling. A patch can be overwritten by a later image build that restores the older lockfile. Compare the running image digest with the rebuild record.
External evidence
The saved ZoomEye Search query title="OpenShift" returned 5,443 matches. The CVE Filter vul.cve="CVE-2026-6322" returned 0. Exposure is 5,443, but the result is broad title data and not a confirmed vulnerable count.
Use the external figure only as a portfolio signal. The completion decision belongs to the owned system's version and test evidence. A cluster can match a title query without running the vulnerable release, and a vulnerable workload can be invisible to a public title query.
Completion checklist
The platform track is complete when the cluster reports a fixed OpenShift release and the update evidence is retained. The application track is complete when each relevant image reports a patched fast-uri version, is rebuilt and deployed, and passes the encoded-delimiter routing tests.
The final record should name any application that cannot be rebuilt, the untrusted URL path that remains reachable, and the verified control that blocks it. That is more useful than a single scanner status. It shows which risk was removed, which risk remains, and who owns the next action.
Top comments (1)
Version confirmation is necessary but not sufficient after a security patch. The strongest verification pairs the fixed version with a bounded test of the affected behavior and records the cluster, image digest, and timestamp, so the evidence answers both “what is deployed?” and “is the exposure actually closed?”