Six Critical Flaws in Red Hat's OpenShift Migration Advisor: vCenter and Kubernetes Credentials at Risk, CVE-2026-53474 and More

A free tool for "scoping out" a move off VMware can itself become the way into your VMware estate and what sits behind it──six serious flaws have been disclosed at once in Red Hat's OpenShift Migration Advisor. The IDs are CVE-2026-53469, CVE-2026-53470, CVE-2026-53471, CVE-2026-53474, CVE-2026-53475, and CVE-2026-53476, with five rated CVSS 9.1–9.6 (Critical).

Many enterprises are now weighing a move off VMware (the "VMware exodus") after price hikes following the Broadcom acquisition, and one leading destination is Red Hat's OpenShift Virtualization. OpenShift Migration Advisor is a cloud service (SaaS) that assesses, for free, "how readily your VMware virtual machines can move to OpenShift." Users place an OVA-format assessment agent inside their own VMware environment and send the VM inventory to Red Hat for analysis.

These six flaws pierce both the tenant isolation of that "scoping tool" and the agent you run on-prem. At worst, other tenants' VMware configuration data and long-lived tokens can be stolen, every customer's assessment data can be wiped at once, Kubernetes credentials can be read out of an uploaded spreadsheet, and the agent-to-vCenter traffic can be sniffed to steal admin passwords. The SaaS side is fixed by Red Hat, but customers must update the agent they run on-prem and rotate the relevant credentials. Check Red Hat's security advisory and act now.

What OpenShift Migration Advisor Is, and Why It Matters Amid the VMware Exodus

OpenShift Migration Advisor is a free assessment service available to anyone with a Red Hat account. There are two ways to use it: upload the output of RVTools (a staple tool that exports a VMware environment's configuration to Excel), or run an OVA-format agent inside your own VMware to automatically collect the VM inventory from vCenter (VMware's management server). The collected data is sent to Red Hat's cloud, which scores migration readiness.

What matters here is that this tool aggregates extremely sensitive information — the contents of each company's VMware estate. What VMs exist, how many, their OS, IP addresses, and network layout — to an attacker, that is the blueprint of your infrastructure. On top of that, the on-prem agent holds vCenter credentials, and Red Hat's SaaS holds those for many companies in a multi-tenant design. It looks like a harmless scoping tool, but it is in fact a single place where "a keyring to multiple companies' virtual platforms" piles up.

The six split by nature into two groups. One is the four that break tenant isolation on the Red Hat-operated SaaS (53469, 53470, 53471, 53474). The other is the two on the agent companies run on-prem (53475, 53476), enabling traffic sniffing to vCenter and intrusion into the agent.

Where the Risk Lies, by Your Role

"Six flaws in the migration advisor" reads differently for the side using the SaaS and for Red Hat operating it. Here's the split.

The ① SaaS side is fixed server-side by Red Hat — not something users patch. By contrast, ② is a problem in the agent the customer placed inside its own network, so updating and reconfiguring are the customer's responsibility. Any company that ran even one assessment should check now whether the vCenter credentials the agent touched may have leaked.

When These Six Are Triggered, What Walks Off from a Migration "Scoping"

The migration advisor gathers the blueprints and keyrings of multiple companies' virtual platforms. The party that wants this is no abstract "attacker." It is the malicious co-tenant who can join the same SaaS with a free sign-up, the industrial spies and competitors after a target's infrastructure layout, the recon crews scouting an entry point ahead of a ransomware attack, and the disgruntled insiders using the on-prem agent as a foothold. What's carried off is other companies' VM inventories, long-lived JWTs, OVA images, Kubernetes credentials read out of an RVTools spreadsheet, and vCenter admin passwords sniffed from traffic. One uploaded inventory spreadsheet, or a single assessment agent on your network, becomes in that instant the entry point into your own and others' VMware platforms.

What follows is severe. If vCenter admin credentials leak, an attacker seizes the whole virtual platform and is free to start, stop, clone, and siphon every VM. From there, deploying ransomware across the entire platform and exfiltrating customer data becomes real, and if the SaaS's Kubernetes keys change hands, the operating platform itself is taken over. Impersonating another tenant with a stolen JWT also enables tampering with assessments and injecting fake credentials.

The responsibility returns to both Red Hat, operating the SaaS, and the customer that placed the agent on-prem. Red Hat bears the operational responsibility for the collapse of tenant isolation; the customer bears the leak of its own vCenter credentials and the duty to notify. That a scoping tool meant to make migration safe turns into an entry point is itself the biggest loss — one no CVSS number captures. Whether you can update and rotate credentials now decides the safety of the migration.

Each of the Six CVEs: Where and What Goes Wrong

Four are on the SaaS, two on the agent. In order:

CVE-2026-53474: Reading Kubernetes Keys via a Spreadsheet Upload (SQL Injection)

CVE-2026-53474 (CVSS 9.6): the "cluster name" field in an uploaded RVTools spreadsheet is improperly handled, enabling SQL injection (CWE-89). A logged-in user who sends a crafted spreadsheet executes arbitrary SQL and can read sensitive files on the system, including Kubernetes credentials — leading to compromise of the entire SaaS environment. The single most impactful of the six.

CVE-2026-53469: Wiping Every Customer's Data with One DELETE (Missing Auth)

CVE-2026-53469 (CVSS 9.1): the DELETE request to /api/v1/sources lacks authorization and filtering (CWE-306). A logged-in user simply sending a delete request can destroy not just their own but every customer's sources, agents, and assessments at once — a direct hit on availability.

CVE-2026-53470: Stealing Other Tenants' OVA Images and Long-Lived Tokens (Authz Bypass)

CVE-2026-53470 (CVSS 9.6): the ownership check on /api/v1/sources/{id}/image-url can be bypassed (CWE-639). A logged-in party specifying someone else's ID obtains a presigned S3 URL for another company's OVA image and can grab the long-lived JWTs and source configs inside, as a foothold for unauthorized access and tampering.

CVE-2026-53471: Breaking Tenant Isolation via Unchecked Token Scope (Broken JWT Validation)

CVE-2026-53471 (CVSS 9.6): the agent-API middleware fails to validate the source_id claim in a JWT against the requested source ID. This breaks tenant isolation, enabling corruption of others' inventory, injection of fake credentials, and poisoning of assessments.

CVE-2026-53475: Plaintext Agent-to-vCenter Traffic Leaks Admin Creds (Improper Cert Validation)

CVE-2026-53475 (CVSS 9.3): the on-prem agent (assisted-migration-agent) hardcodes insecure TLS for its connection to vCenter (CWE-295). An attacker on the same network can man-in-the-middle the traffic and intercept vCenter admin credentials — the most direct threat, happening inside the customer's own network.

CVE-2026-53476: Unauthenticated Intrusion into the Agent via a Crafted Archive (Path Traversal)

CVE-2026-53476 (CVSS 9.6): the agent's path checks on a gzipped tarball it receives are weak, allowing path traversal (CWE-22) to write arbitrary files. An unauthenticated attacker on the same network just sends a crafted tarball, leading to arbitrary code execution on the agent.

Impact and Remediation at a Glance

At publication, no listing in the CISA KEV (Known Exploited Vulnerabilities) catalog is confirmed. The four SaaS-side flaws are fixed by Red Hat server-side, but customers must keep their agent up to date and rotate the relevant credentials.

What Customers Should Do Right Now

In priority order. This applies to any company that ran even one assessment with OpenShift Migration Advisor, or is currently considering it.

1. Update the on-prem agent (OVA) to the latest. CVE-2026-53475 and 53476 are agent-side. Check the remediation status in Red Hat's security advisory, and if an old assessment agent is still on your network, shut it down and replace it.

2. Rotate vCenter credentials. CVE-2026-53475 lets attackers sniff admin credentials from plaintext agent-to-vCenter traffic. Treat the vCenter account password you gave the agent as leaked and rotate it.

3. Re-check the isolation of the agent's network. Both 53475 and 53476 assume "an attacker on the same network." Place the assessment agent in a restricted segment such as a management zone, and remove it promptly once it's no longer needed. In migration projects, test environments tend to linger, and a forgotten agent makes an easy target.

4. Inventory what you uploaded. The SaaS side is Red Hat's to fix, but the fact that your VMware configuration and inventory are stored in the SaaS doesn't change. Know what you uploaded, and if it contained sensitive details, share the impact scope internally.

Timeline

Conclusion: A Tool Meant to Make Migration Safe Endangered Both Ends

What these six reveal is the picture in which a "scoping tool" riding the big wave of the VMware exodus has become a new attack surface that aggregates the keyrings of multiple companies' virtual platforms. The advisor draws in information about the VMware source and connects to the OpenShift destination's operating platform, so both ends were endangered at once. The more convenient the free SaaS, the more you must weigh the gravity of what you hand it.

There are two things customers should do right now: update (or remove) the on-prem assessment agent, and rotate the vCenter credentials you gave it. Leave the SaaS-side fix to Red Hat, but shore up your own ground inside your network. Migration-project security has entered a stage where it must be designed with the same weight as the migration work itself.

References

• ▸NVD - CVE-2026-53469 (missing auth on DELETE, wipe all data)
• ▸NVD - CVE-2026-53470 (authz bypass, steal others' tokens)
• ▸NVD - CVE-2026-53471 (broken JWT validation, cross-tenant)
• ▸NVD - CVE-2026-53474 (SQL injection, read K8s keys)
• ▸NVD - CVE-2026-53475 (improper cert validation, intercept vCenter creds)
• ▸NVD - CVE-2026-53476 (path traversal, unauth code execution)
• ▸Red Hat Security - CVE-2026-53474
• ▸Red Hat - Introducing the OpenShift Migration Advisor
• ▸OpenShift Migration Advisor documentation
• ▸CISA KEV Catalog