VizAir Vulnerabilities: Unauthenticated Admin Access and Exposed API Keys

Radiometrics’ VizAir—a piece of equipment trusted at airports worldwide to detect wind shear and other hazardous low‑level wind phenomena—has been the subject of an urgent security advisory that elevates the product from “operational asset” to high‑risk attack surface for aviation infrastructure. Multiple vulnerabilities affecting VizAir’s web/admin interfaces and REST API keys were disclosed in coordinated advisories and assigned three CVE identifiers (CVE‑2025‑61945, CVE‑2025‑54863, CVE‑2025‑61956). Each entry carries a maximum severity profile under modern scoring frameworks: vendors and tracking services report CVSS base scores of 10.0, and public vulnerability trackers classify the issues as remotely exploitable with low attack complexity. This feature unpacks what is known, verifies technical claims against independent sources, evaluates operational risk to airports and airspace safety, and explains concrete mitigations and monitoring actions that airports, system integrators, and enterprise defenders should adopt immediately. The piece also flags areas where public claims remain unverifiable and offers practical steps to validate vendor remediation.

Background / Overview​

Radiometrics VizAir is an integrated weather‑decision system used at airports to monitor wind shear, low‑level jets, head/tail winds, and other parameters that directly influence takeoff and landing safety. The product integrates sensor feeds (wind profilers, radars, sodars and surface sensors) and converts them into live alerts and decision support for air traffic control (ATC) and flight crews. VizAir is widely deployed in transport and meteorological environments where accurate, trustworthy data is mission‑critical. On November 4, 2025, coordinated vulnerability disclosures described a set of critical flaws that together enable unauthenticated remote control of VizAir system functions and exposure of REST API keys in publicly accessible configuration files. The three CVEs assigned to these findings describe two missing/insufficient authentication problems and one insufficiently protected credentials issue; public trackers list each as scoring 10.0 on CVSS scales and describe them as exploitable over the network without user interaction. Independent vulnerability aggregators and threat‑intelligence feeds corroborate the CVE assignments and scoring. CISA’s standard guidance for ICS/OT vulnerabilities—minimize network exposure, isolate control systems behind firewalls, and prefer secure remote‑access methods such as hardened VPNs and jump hosts—was reiterated in the advisory material and recommended actions for defenders. The disclosure credits security researcher(s) who reported the issues through coordinated channels; one public mention names Souvik Kandar as a reporting researcher in the broader ICS context, underscoring coordinated disclosure practice across similar advisories.

---

What the vulnerabilities are (technical summary)​

CVE‑2025‑61945 — Unauthenticated admin panel access​

• Nature: Missing authentication for critical function (CWE‑306).
• Impact: Remote unauthenticated access to the VizAir admin panel, enabling modification of core weather parameters (wind shear thresholds, inversion depth, CAPE values) and control over alerting logic and runway‑related configuration.
• Attack vector: Network (remote). No privileges or user interaction required.
• Scoring: Public trackers report CVSS v3.1 and v4 base scores of 10.0.

CVE‑2025‑54863 — Exposed REST API key / insufficient credential protection​

• Nature: Insufficiently protected credentials — REST API key exposed in a publicly readable configuration file or web‑accessible resource.
• Impact: Attackers who retrieve the key may perform authenticated API operations against local or remote VizAir instances, automate attacks across multiple installations, and exfiltrate raw meteorological data or inject false alerts. The attack could also be used as a pivot to spam the system with bogus events (false positives), resulting in degraded service or denial‑of‑service via alert flood. Public trackers assign a CVSS score of 10.0.

CVE‑2025‑61956 — Missing authentication on additional critical functions / APIs​

• Nature: Related Missing authentication problems affecting other admin and API endpoints.
• Impact: Allows unauthenticated remote calls that change configurations or operational modes, potentially including runway assignment indicators and other automated decision‑support outputs. Public trackers again list the CVSS base score at 10.0 and the described impact as grave.

These flaws form a clustered threat: unauthenticated control paths plus exposed credentials escalate both the ease and scale of remote manipulation. Independent vulnerability feeds replicate the core claims and the scoring, providing corroboration beyond the initial advisory.

---

Why this matters: operational and safety implications​

VizAir is not “just another web appliance.” Its outputs feed decision workflows used by ATC, dispatch, and pilots during critical phases of flight. The vulnerabilities therefore map to tangible safety and operational risks:

• Tampering with wind‑shear alerts or thresholds could suppress warnings or generate false alarms at times that directly affect takeoff/landing decisions, increasing the chance of hazardous approaches or unnecessary diversions.
• Manipulating runway or operational flags that feed ATC displays—and, in some implementations, automated runway assignments—could create conflicts between competing flight plans or mislead controllers about runway status. These are system‑level hazards with real safety implications if attackers can alter data that crews and controllers trust.
• Credential exposure enabling mass automation raises the specter of broad‑scale manipulation: an attacker who harvests API keys can target many VizAir installations in parallel, amplifying the operational impact across airports or regional meteorological services.
• Denial‑of‑service via false‑alert floods could overwhelm operators and automated handlers, creating outages or reducing confidence in instrumented warnings.

These scenarios are both plausible and serious. However, some of the most catastrophic outcomes (for example, direct evidence that manipulated VizAir outputs have produced near‑misses or accidents) are not publicly documented; the published advisories and trackers describe technical impact and risk, not confirmed real‑world incidents. That distinction is critical: the potential for safety consequences is high and actionable, but public proof of an exploit leading to physical harm is not present in advisory material at this time. Analysts and operators should therefore treat the vulnerabilities as high urgency for remediation and monitoring, even while acknowledging that publicly reported exploitation has not yet been confirmed.

---

Verification and cross‑checking: what we confirmed and what remains unclear​

To meet rigorous reporting standards, the key technical claims were cross‑checked against multiple independent sources:

• CVE and vulnerability trackers (aggregators such as Feedly/CVEfeed entries and other trackers) independently list CVE‑2025‑61945, CVE‑2025‑54863 and CVE‑2025‑61956, with matching descriptions and CVSS scores. These independent feeds corroborate the scoring and the core impact statements.
• Radiometrics’ own product documentation confirms VizAir’s role in wind‑shear detection and decision support—i.e., the system’s functions are safety‑critical and deserve high protection. The vendor literature confirms which sensor types and decision workflows VizAir supports.
• CISA/ICSA listings and ICS advisory indexes describe the pattern of ICS/OT advisories and the recommended mitigations (isolation, segmentation, and secure remote access)—the exact ICSA advisory entry for this set is referenced in public trackers as ICSA‑25‑308‑04; the CISA advisory ecosystem’s guidance is consistent with the mitigations published in the advisory material.
• The advisory material names a researcher (Souvik Kandar) in coordination/attribution notes, consistent with standard coordinated disclosure workflows in the ICS community. Independent community files referencing related disclosures also mention him.

What could not be independently verified from public sources at the time of reporting:

• The vendor statement included in some summaries that "Radiometrics performed updates on all affected systems and resolved these vulnerabilities. No further action is needed on the user's end." That specific remediation claim—i.e., universal, automatic updates applied to every affected customer—could not be located on Radiometrics’ public product‑support or advisory pages at the time of verification. Organizations should therefore treat any claim of “no action required” with caution and independently confirm remediation status with their vendor contacts or through verified patch manifests. This is particularly important in aviation and ICS ecosystems where vendor patch distribution often requires operator coordination. If Radiometrics provided targeted updates or pushed fixes, operations teams must still validate installed firmware/software versions in situ.

Because the advisory ecosystem is dynamic, defenders should treat "no known exploitation" statements as time‑sensitive: weaponization and public proof‑of‑concepts can appear quickly after public disclosures. Continuous monitoring of threat feeds and vendor advisories is mandatory.

---

Practical mitigation checklist (what airport SOCs and OT teams should do right now)​

The following steps combine CISA/ICS best practices with immediate triage actions tailored to VizAir deployments. Apply the list in the order that fits operational constraints: inventory → isolate → verify → remediate → monitor.

• Inventory and asset validation (immediate)
• Identify every VizAir instance and associated management endpoints (IP, MAC, physical location, firmware/software version).
• Maintain a verified manifest (control plane) that records installed build numbers and last update timestamps.
• Block internet exposure (hours)
• Ensure all VizAir management ports and the admin panel are not reachable from the public Internet.
• Deny inbound connectivity at perimeter firewalls and NAT devices; apply allow‑lists for required management IPs only.
• Network segmentation and isolation (hours to days)
• Move VizAir systems into a dedicated, tightly controlled management VLAN with explicit ACLs permitting access only from approved operator and maintenance hosts.
• Block outbound connections from VizAir to the broader enterprise unless expressly required and audited.
• Enforce strong access controls (days)
• If any authentication is present, enforce strong, unique credentials and multi‑factor authentication for human users.
• For systems with exposed API keys, assume current keys are compromised; rotate keys and ensure new keys are stored in secure vaults—not static config files or web‑exposed resources.
• Validate vendor remediation (days)
• Contact Radiometrics support or your vendor representative to obtain authoritative patch/firmware release notes and checksums.
• Validate installed versions on each device; do not rely solely on vendor statements that fixes were pushed. Confirm with device manifests and software checksums.
• If vendor patches are available, schedule out‑of‑hours maintenance windows as needed; test patches in a controlled environment before broad rollout.
• Apply compensating controls if patching is delayed (days to weeks)
• Use jump hosts or bastion systems with MFA for any remote maintenance.
• Deploy network IDS/IPS rules tuned to suspicious admin‑panel activity and anomalous API calls against VizAir endpoints.
• Rate‑limit or throttle alert‑ing ingestion points where VizAir outputs feed downstream systems, preventing simple flood attacks from overloading decision‑support downstream.
• Monitoring and detection (ongoing)
• Log admin panel access, API calls, configuration changes, and alert generation. Retain logs in a hardened, write‑once location for forensic traceability.
• Create detection rules for sudden changes in alert thresholds, multiple identical configuration updates, and unusual volumetric alert events.
• Monitor threat feeds and CVE trackers for proof‑of‑concept exploits or exploit code associated with the listed CVEs.
• Incident readiness (immediate)
• Update incident response playbooks to include VizAir compromise scenarios: false alerts, suppressed alerts, and credential theft.
• Coordinate with ATC and operational stakeholders so that an incident involving VizAir can be managed without confusion (e.g., failover to manual reporting and procedural cross‑checks).

---

Detection: indicators and what to log​

• Unexpected admin‑panel sessions from non‑operator IP addresses.
• Sudden configuration changes to wind‑shear thresholds, inversion profiles, CAPE thresholds, or runway flags that occur without scheduled maintenance windows.
• API requests using long‑lived keys or keys present in configuration files that were recently rotated.
• Unusual alert volumes (spikes of identical alerts across sensors) that could indicate injection/flooding attempts.
• Downstream system discrepancies: VizAir outputs inconsistent with other independent sensor feeds (e.g., ADS‑B wind reports, other radars) should trigger immediate manual verification of VizAir outputs.

Logging these items to a centralized SIEM and configuring fast‑path alerting for suspicious changes will materially reduce reaction time and limit impact.

---

Policy and procurement lesson: OT products must be treated like safety‑critical systems​

The VizAir advisories reinforce a persistent lesson for airports and infrastructure operators: when product outputs directly influence safety decisions, those products must be evaluated and procured under safety‑grade cybersecurity requirements. Practical procurement controls include:

• Require secure default configurations (authentication on by default) and secure key storage as contractual terms.
• Demand support and timely patch release SLAs, plus transparent vulnerability disclosure policies.
• Request signed firmware images and documented update processes (release notes and checksums) before installation.
• Force a strong asset‑management posture: vendors should provide upgrade manifests so operators can independently verify applied patches.

These commercial and contractual steps lower systemic risk by shifting remediation responsibility into the procurement lifecycle rather than relying on ad hoc operational compensations.

---

Critical appraisal of vendor statements and public claims​

Several public summaries of the VizAir advisory indicate Radiometrics “performed updates on all affected systems and resolved these vulnerabilities.” This article could not independently confirm universal automatic updates on every deployed system; radiometrics.com product pages describe the system and feature set but do not currently publish a public, machine‑readable patch manifest that proves universal remediation. Operators must therefore confirm with their vendor support channels and verify installed software versions on each device. Blind acceptance of vendor remediation claims—without evidentiary verification—would be negligent in an aviation safety context. Public trackers widely report CVSS base scores of 10.0 for the CVEs, which signals the advisory community’s consensus around the severity of unauthenticated control and exposed credentials. Multiple independent feeds echo the same CVE descriptions and scoring, increasing confidence in the technical severity. That said, public scoring is a severity indicator—not a guarantee of exploitability in a specific operational context; asset owners must evaluate exploitability relative to their own network exposure and compensations.

---

Recommended roadmap for airport security teams (30/60/90 days)​

First 30 days​

• Perform full inventory; isolate VizAir systems from public networks.
• Rotate API keys and credentials; enforce vaulting and on‑device secure storage practices.
• Validate vendor patches where available; seek explicit patch manifests and verification checksums.

30–60 days​

• Harden management access with bastion/jump hosts and MFA.
• Implement or tune SIEM alerts for VizAir events and anomalous configuration changes.
• Run tabletop exercises with ATC and operational stakeholders for VizAir compromise scenarios.

60–90 days​

• Revisit procurement and vendor contracts to mandate secure defaults, update SLAs, and signed firmware.
• Conduct a detailed security review of all aviation‑critical decision‑support systems, not just VizAir.
• Evaluate longer‑term architectural mitigations: redundant independent sensor chains and cross‑validation logic to reduce single‑point trust on any one instrument.

---

Final analysis and risk posture​

The combination of unauthenticated admin pathways and exposed API keys in Radiometrics VizAir creates a canonical ICS/OT high‑risk scenario: remote, low‑complexity exploitability of a safety‑critical device whose outputs are trusted by human and automated decision processes. Public vulnerability trackers and vendor product docs confirm the core attributes of the disclosure and the system’s safety role. The immediate defensive posture is straightforward: inventory, isolate, validate patches, rotate credentials, and monitor aggressively. But the strategic lesson is deeper: systems that materially affect safety decisions must be procured, deployed, and maintained under explicit security and verification regimes that reflect their real‑world risk. Vendors must publish verifiable, machine‑readable patch manifests and offer transparent notices when patches are delivered; operators must validate fixes in the field rather than relying on blanket vendor statements.
Until every VizAir instance has been verified as patched and locked down behind robust access controls—and until downstream consumers of VizAir outputs implement cross‑validation logic and procedural contingencies—these CVEs represent a high‑urgency operational threat that merits immediate attention from airport CISOs, OT engineers, and aviation safety authorities. Continuous monitoring of vendor advisories and threat feeds is required because the public disclosure window is often followed by rapid attempts at exploitation or automated scanning.

---

Radiometrics’ VizAir sits at the intersection of meteorology and aviation safety, and the recent vulnerability disclosures make a plain point: when software controls or materially informs safety action, cybersecurity cannot be optional. The immediate path forward is a disciplined mix of containment, verification, and long‑term procurement and design changes that treat OT as safety‑critical engineering.

---

Source: CISA Radiometrics VizAir | CISA