Aviatrix Controllers OS Command Injection Vulnerability (CVE-2024-50603)

What is affected, what to do

Aviatrix Controllers before version 7.1.4191 and 7.2.x before 7.2.4996 have an OS command injection vulnerability allowing unauthenticated attackers to execute arbitrary code. Shell metacharacters can be sent to /v1/api in cloud_type for list_flightpath_destination_instances, or src_cloud_type for flightpath_connection_test. This vulnerability is actively exploited in the wild and is listed in the CISA KEV catalog. Affected products include Aviatrix Controller versions up to 7.1.4191 and 7.2.x up to 7.2.4996. An immediate update to the latest version is crucial to mitigate this risk.

The vulnerability is being actively exploited; treat it as a priority. Update Aviatrix Controller to version 7.1.4191, Aviatrix Controller to version 7.2.4996. Immediate actions, mitigation and detection rules are in the runbook below.

Affected

• Aviatrix Controller lt *..7.1.4191
• Aviatrix Controller lt 7.2.0..7.2.4996

Fixed in

• Aviatrix Controller 7.1.4191
• Aviatrix Controller 7.2.4996

Not sure whether and how you are affected? Ask a question about this vulnerability

Metrics

Response and mitigation

1. 01

   Runbook step 1

   Immediate response (0-24 h)

   • Cut exposure now: Restrict the Aviatrix Controller's security group, NSG or firewall rule on TCP 443 to admin networks (VPN/bastion) and the EIPs or public IPs of your own Aviatrix gateways. Any 0.0.0.0/0 rule on the controller must go before you patch. Check the "Controller Security Group Management" feature so gateway connectivity keeps working.
   • Identify version and patch: Upgrade controllers older than 7.1.4191 to at least 7.1.4191, and 7.2.x builds older than 7.2.4996 to at least 7.2.4996. Move legacy release trains to a supported build. If the vendor ships a standalone security patch for your branch, the patch is available from the vendor — look up its name in the vendor advisory.
   • Preserve evidence before patching: If the controller was internet-reachable before you restricted it, snapshot the instance disk first. Also export web server, ALB/WAF and cloud audit logs. Only then patch, so that traces of compromise survive.
   • Rotate cloud credentials if compromise is suspected: The controller holds broad rights across every onboarded cloud account (AWS IAM roles such as aviatrix-role-app/aviatrix-role-ec2, Azure service principals, GCP service accounts). If you suspect compromise, rotate secrets and access keys, review trust policies and reset controller admin passwords.
   • Hunt for persistence: On the controller, look for new cron jobs, unknown users, modified authorized_keys, unfamiliar binaries in /tmp, /var/tmp and /dev/shm, and sustained high CPU load. High CPU load can point to a coinminer.
2. 02

   Runbook step 2

   Mitigation layers

   • Network segmentation: Place the controller in a dedicated management subnet with no direct internet access for administrators. Admins reach it only via VPN, a zero-trust proxy or a bastion. Limit controller egress to what it needs: cloud APIs, gateways and vendor update endpoints. Block outbound traffic to unknown IPs and common mining-pool ports.
   • WAF/reverse-proxy rule: Block requests to /v1/api where action is list_flightpath_destination_instances or flightpath_connection_test and cloud_type or src_cloud_type contains anything outside [0-9A-Za-z_-], in particular ;, |, &, `, $(, > and %0a. The rule must inspect both the query string and the POST body.
   • IAM/least privilege: Trim the controller's cloud roles to the minimum the vendor documents. Remove wildcard rights such as iam:*, s3:* and secretsmanager:*, and apply a permissions boundary. Use an SCP or Azure Policy to limit cross-account role assumption.
   • Instance hardening: In AWS, enforce IMDSv2 with a hop limit of 1. This does little against an attacker who already has a shell, but it stops simple SSRF follow-ups. Deploy an EDR or auditd agent where the vendor supports it.
   • Configuration: Disable unused remote access paths to the controller, such as public SSH and support access. Forward controller logs via syslog to the SIEM.
3. 03

   Runbook step 3

   Detection rules

   • Web/ALB/WAF logs: Look for requests to /v1/api carrying list_flightpath_destination_instances or flightpath_connection_test with shell metacharacters in cloud_type/src_cloud_type. Example SPL: index=web uri_path="/v1/api" (flightpath_connection_test OR list_flightpath_destination_instances) | regex _raw="(src_)?cloud_type=[^&]*(%3B|;|%7C|\||%60||$(|%24%28|%0a)"`. Note that POST bodies are often missing from access logs, so rely on WAF or full-request logging.
   • Process ancestry (EDR/auditd): Watch for the web server process (httpd/apache2/php) spawning sh/bash, followed by curl, wget, nc, python, base64 or chmod +x. Sigma shape: ParentImage|endswith: ['/apache2','/httpd','/php-fpm'] with Image|endswith: ['/sh','/bash','/curl','/wget']. With auditd you can capture this via -a always,exit -F arch=b64 -S execve -F uid=www-data -k web_exec.
   • Network telemetry (Zeek/Suricata/VPC Flow Logs): Flag new outbound connections from the controller to unknown destinations. Watch for long-lived TLS sessions to unknown IPs (reverse shell, C2), Stratum protocol traffic or connections on ports such as 3333, 4444 and 5555. Also watch for DNS lookups of mining pools.
   • Cloud audit (CloudTrail/Azure Activity/GCP Audit): Look for API calls by the controller role that don't fit normal operations, such as ListBuckets, GetSecretValue, CreateUser, CreateAccessKey, AttachUserPolicy or RunInstances in unusual regions. Instance-role credentials used from an IP other than the controller instance are also suspect. Example KQL: AWSCloudTrail | where UserIdentityArn has "aviatrix-role" and EventName in ("CreateUser","CreateAccessKey","GetSecretValue").
   • Host artefacts: Look for new files in /tmp, /var/tmp or /dev/shm, modified crontabs or systemd units, and processes with sustained high CPU usage.

Detection rules

No NEOSEC detection rule is available for this vulnerability yet.

Classification under NIS2 and CRA

Rule-based classification from exploitation status and severity. It does not replace a case-by-case assessment.

NIS2

NIS2 is EU Directive (EU) 2022/2555 to raise the level of cybersecurity across the Union. It substantially broadens obligations compared with the first NIS directive: more sectors, mandatory risk management, staged reporting duties and personal accountability of senior management.

Read in glossary

Actively exploited: treat the vulnerability as a priority in vulnerability handling under Art. 21(2)(e) NIS2. If it is exploited in your environment, check the reporting obligation under Art. 23 (early warning within 24 hours).

CRA

The CRA is EU Regulation (EU) 2024/2847 setting horizontal cybersecurity requirements for „products with digital elements“ — from industrial controllers and software to connected consumer devices. For the first time manufacturers must ensure security across the entire product lifecycle, handle vulnerabilities and provide security updates.

Read in glossary

Since 11.09.2026, manufacturers of affected products with digital elements must report actively exploited vulnerabilities under Art. 14 CRA, with an early warning within 24 hours via ENISA's single reporting platform.

ISO/IEC 27001

ISO/IEC 27001 is the internationally leading standard for an information security management system (ISMS). It describes a risk-based, process-oriented framework to systematically plan, implement, review and improve information security.

Read in glossary

Control A.8.8, management of technical vulnerabilities: assess relevance to your systems, plan remediation and keep evidence.

Description

An issue was discovered in Aviatrix Controller before 7.1.4191 and 7.2.x before 7.2.4996. Due to the improper neutralization of special elements used in an OS command, an unauthenticated attacker is able to execute arbitrary code. Shell metacharacters can be sent to /v1/api in cloud_type for list_flightpath_destination_instances, or src_cloud_type for flightpath_connection_test.

Source: pwn.watch, NVD (NIST), cvelistv5, CISA KEV Catalog, CVE.org (MITRE)

Vendors and products

• Aviatrix Aviatrix Controller

Weakness classes (CWE)

• CWE-78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

  Base

  The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.

  Entry at MITRE CWE-78

References & sources

• docs.aviatrix.comdocumentation/latest/network-security/index.htmlProduct
• docs.aviatrix.comdocumentation/latest/release-notices/psirt-advisories/psirt-adv…Vendor advisory
• securing.plen/cve-2024-50603-aviatrix-network-controller-command-injection…Exploit, Third-party advisory
• cisa.govknown-exploited-vulnerabilities-catalog?field_cve=CVE-2024-50603government-resource, US government resource
• pwn.watchpwn.watch: Aviatrix Controllers: Controllers OS Command Injection Vulnerabilitypwn-watch
• docs.aviatrix.comAviatrix advisory: Aviatrix Controllerspwn-watch
• NVD (NIST)NVD: CVE-2024-50603pwn-watch
• cisa.govCISA Known Exploited Vulnerabilities Catalogpwn-watch