The scanner question
CVE-2026-44494 affects Axios before 1.16.0. A straightforward scanner can detect the package name and version, but an OpenShift environment adds another layer of complexity: the vulnerable copy may be in an application image, a build stage, a sidecar, or a vendor-maintained component. Red Hat lists OpenShift Container Platform among affected products and directs customers to errata, while application teams remain responsible for their own images.
The GitHub advisory describes a prototype-pollution gadget in config.proxy. If an attacker can set Object.prototype.proxy, Axios can send a request through an attacker proxy without the application explicitly asking for one. The attack requires a separate pollution source and a process that makes Axios requests.
Build inventory that answers the right question
A package list from a developer workstation is not enough. Start with the final runtime image digest. Use an SBOM or package inventory generated from that image to find Axios versions below 1.16.0. Record the layer and path when the scanner provides them. If a multi-stage build installs dependencies and then copies a production directory, verify what survived into the final stage.
Separate direct and transitive dependencies. A team may update its own package.json while a library or a copied lockfile still installs an older Axios version. The package manager should resolve the fixed version and the final image should show it. A clean build log is useful, but it is not a substitute for inspecting the artifact that will run.
Search all workload types. A deployment is obvious, but cron jobs, operators, admission controllers, and short-lived utility containers can also carry Node.js dependencies. An image that runs only during maintenance can still have access to credentials and service endpoints.
Risk ranking
For each affected image, ask whether attacker-controlled data reaches a merge, parser, or object-construction path that can modify a shared prototype. Then ask whether the same process makes Axios calls with authentication headers or access to internal services. An image used for a public API can rank above a batch job with no untrusted object input.
Retain the image digest, namespace, deployment name, and owner in the result. This keeps the finding actionable after a pod restarts or a tag changes. A mutable tag such as latest can point to a fixed build in one environment and an older build in another, so use digests for the inventory decision.
What external exposure can and cannot show
ZoomEye returned 5,443 matches for the title="OpenShift" Search on 2026-11-03 UTC. The CVE filter returned 0. This is useful as a broad count of OpenShift-related product titles in a public search index. It does not reveal Axios version, JavaScript package contents, prototype-pollution reachability, or whether a service is exploitable.
An external scanner should not be treated as a replacement for an SBOM. It can help prioritize internet-facing products, but the remediation decision comes from the image inventory and the application's data flow.
Remediation
Upgrade Axios to 1.16.0 or later and rebuild the final image. Apply the Red Hat errata for OpenShift Container Platform and other affected Red Hat products. Red Hat reports no supported mitigation, so replacing the vulnerable library is the dependable control.
After deployment, rerun the image inventory and compare the result with the prior digest. Verify that an old vulnerable package did not remain in an unremoved layer or a copied dependency directory. The rebuilt image should have a fixed package record, a new digest, and a deployment that uses the new digest.