> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Aviatrix Controller 8.1.60 Release Notes

> Release Date: 26 October 2026

Release Date: 27 October 2026

## Corrected Issues in Aviatrix Release 8.1.60

This release installs the security patches for the following CVE advisories, detailed on the [PSIRT Advisories](https://docs.aviatrix.com/docs/enterprise/10.0/reference/release-notices/psirt-advisories/index.md) page:

* [CVE-2026-109618](https://nvd.nist.gov/vuln/detail/CVE-2026-109618) and [CVE-2026-109619](https://nvd.nist.gov/vuln/detail/CVE-2026-109619) (PHP2Shell): remote code execution in PHP.
* [CVE-2026-115560](https://nvd.nist.gov/vuln/detail/CVE-2026-115560) (PHP session upload progress).
* [CVE-2025-2171](https://nvd.nist.gov/vuln/detail/CVE-2025-2171) and [CVE-2025-2172](https://nvd.nist.gov/vuln/detail/CVE-2025-2172): removal of the compromised eMudhra intermediate certificates from the Controller trust store.

<table>
  <thead><tr><th>Issue</th><th>Description</th></tr></thead>

  <tbody>
    <tr><td>AVX-82516</td><td>Fixed an issue where traffic through an Azure Transit FireNet HA gateway pair could stop forwarding reliably after both gateways in the pair were shut down and brought back online. In the earlier behavior, traffic resumed briefly after both gateways came back up but began dropping packets within about one minute of recovery. The issue applied only to Azure Transit FireNet HA deployments and did not affect AWS Transit gateways or non-FireNet Azure deployments.</td></tr>
    <tr><td>AVX-83174</td><td>Fixed an issue where a Controller upgrading directly from 8.0.x into 8.1.50 could send a spoke gateway routes to its own custom advertised VPC/VNet CIDRs through an attached transit gateway with Connected Transit enabled, which could cause temporary traffic loops for those CIDRs until an unrelated routing change cleared them. This release prevents the issue on new upgrades from 8.0.x. It does not repair a Controller that is already affected, including one that upgraded through 8.1.50 before reaching this release; see the Known Issue in the 8.1.50 release notes for the recovery procedure.</td></tr>
  </tbody>
</table>

## Known Issues in Aviatrix Release 8.1.60

<table>
  <thead><tr><th>Issue</th><th>Description</th></tr></thead>

  <tbody>
    <tr><td>AVX-72940</td><td>Creating a new gateway with the same name as an existing gateway may cause local files of the existing gateway to be deleted when the creation fails. The existing gateway name disappears from the Controller CLI once this occurs. This can break SSH access to the existing gateway.\
    \
    **Impact:**\
    \
    <ul><li>SSH access to the existing gateway may stop working</li><li>Gateway recovery may require manual intervention</li></ul>**Affected Scenario:**\
    \
    Gateway creation using a name that already exists.\
    \
    **Workaround:**\
    \
    Do not reuse gateway names. Contact [Aviatrix Support](https://support.aviatrix.com) if recovery is required.</td></tr>
    <tr><td>AVX-73436</td><td>When using the update\_spoke\_vpc\_route\_table API to onboard an Azure route table, the default route (0.0.0.0/0) is not programmed in the spoke VNET route table if the Spoke Gateway has learned the default route from any of the following sources: an attached Egress Transit Gateway (Transit with egress functionality enabled), a Transit Gateway that learned the default route via an external Site-to-Cloud (S2C) connection (for example, from an on-premises network or third-party appliance advertising 0.0.0.0/0 over IPSec/BGP), or another Spoke Gateway that is propagating the default route within the Aviatrix network. In all of the above cases, although the Spoke Gateway has successfully learned and installed the default route in its own routing table, the route is not re-programmed into the associated Azure VNET route table during the onboarding operation.\
    \
    **Impact:**\
    \
    Default route (0.0.0.0/0) is not installed in the onboarded Azure spoke VNET route table.\
    \
    Traffic that depends on the default route, including traffic destined for the internet through an egress transit, for on-premises networks through an S2C-connected transit, or for another spoke, may not be routed correctly from the Azure VNET.\
    \
    **Workaround:**\
    \
    Manually add the default route to the Azure route table. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-75452</td><td>In Azure environments, when Distributed Cloud Firewall (DCF) Security Group Orchestration attaches a Network Security Group (NSG) to a subnet, the subnet name is changed to all lowercase. Although Azure resource names are generally case-insensitive, this modification causes issues with Infrastructure as Code tools such as Terraform, which treat resource names as case-sensitive. Terraform may flag affected subnets for replacement, potentially disrupting existing deployments.\
    \
    **Impact:**\
    \
    Subnet names in Azure are modified to lowercase when Security Group Orchestration attaches NSGs\
    \
    Terraform plans may show unexpected resource replacements for affected subnets\
    \
    Customer naming conventions in the cloud may be altered without consent\
    \
    **Workaround:**\
    \
    In Terraform, add a `lifecycle` block with `ignore_changes` for `subnet_id` (as well as `id` in the `azurerm_subnet` resource) to prevent forced resource replacement. Note that this workaround does not restore the original subnet name casing.</td></tr>
    <tr><td>AVX-75607</td><td>Gateway launch may fail with a `tls: bad certificate` error when pulling container images. The Controller's registry TTL eviction (garbage collection) may fire while images are being downloaded to the gateway, corrupting in-flight blob transfers. The gateway's container initialization cannot complete, and an internal identity-helper service on the gateway exits with code 125.\
    \
    **Impact:**\
    \
    <ul><li>Gateway creation fails with tls: bad certificate or unexpected EOF errors during container image pull</li><li>The gateway's identity-helper service crash-loops with exit code 125</li><li>Manual intervention is required to recover</li></ul>**Workaround:**\
    \
    Restart the Controller's core application service to reset the registry state, then retry gateway creation. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-79057</td><td>Auto-restart of a failed Aviatrix gateway deployed in GCP (GCE) may not succeed, leaving the gateway in a down state until manual intervention.\
    \
    **Impact:**\
    \
    A failed Aviatrix gateway deployed in GCP (GCE) will not be automatically recovered. Traffic through the affected gateway remains disrupted until an operator manually restarts the gateway.\
    \
    **Workaround:**\
    \
    Manually restart the failed GCE gateway from the Controller, or contact Aviatrix Support for assistance.</td></tr>
    <tr><td>AVX-79521</td><td>On Controller versions prior to 10.1.0, it is possible to onboard multiple Aviatrix access accounts that map to the same underlying cloud service provider (CSP) account. Because several Controller features assume a one-to-one relationship between an Aviatrix access account and a CSP account, duplicate access accounts can lead to unpredictable configuration and operational behavior. Duplicate is defined per CSP as follows:\
    \
    <ul><li>**AWS** (including AWS GovCloud and AWS China): same account number, for both IAM role and access/secret key authentication.</li><li>**Azure** (including Azure Government and Azure China): same subscription.</li><li>**GCP**: same project.</li><li>**OCI** (including OCI Government): same tenancy and compartment combination.</li><li>**Alibaba**: same account number.</li></ul>Starting in Controller 10.1.0, the Controller blocks new onboarding of duplicate access accounts across all supported CSPs. Existing duplicate access accounts continue to operate as-is and are not automatically removed.\
    \
    **Impact:**<ul><li>New duplicate access accounts can still be onboarded on Controller versions prior to 10.1.0.</li><li>Environments that already have duplicate access accounts may see inconsistent behavior in features that assume a unique CSP account per Aviatrix access account.</li></ul>**Workaround:**\
    \
    Onboard only one Aviatrix access account per underlying CSP account. If duplicate access accounts have already been onboarded and are causing issues, contact [Aviatrix Support](https://support.aviatrix.com/) for assistance with identifying and removing the duplicates.</td></tr>
    <tr><td>AVX-80977</td><td>A VPN user's profile assignment could appear as N/A immediately after the user was attached to a profile through the API, until the user's next reconnection.\
    \
    **Impact:**\
    \
    The user's profile displays as N/A until the user's next reconnection, even though the profile attachment succeeded.\
    \
    This can cause confusion when auditing or verifying profile-based access policies shortly after attachment.\
    \
    **Workaround:**\
    \
    Have the affected user reconnect to update the displayed profile assignment. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-81230</td><td>Enabling both Policy-Based Routing (PBR) and NAT logging under User VPN settings can cause high CPU utilization on the User VPN gateway during data-plane traffic. The high CPU usage occurs because NAT log entries generated by PBR are written to the gateway's serial console.\
    \
    **Impact:**\
    \
    User VPN gateways with both PBR and NAT logging enabled may experience elevated CPU utilization while passing data-plane traffic, which can degrade VPN gateway performance.\
    \
    **Workaround:**\
    \
    Disable NAT logging on the affected User VPN gateway. If NAT logging must remain enabled, contact [Aviatrix Support](https://support.aviatrix.com/) to apply a backend workaround.</td></tr>
    <tr><td>AVX-81576</td><td>During a Gateway resize operation (for example, changing the Gateway's underlying instance or VM size), the Gateway can experience a temporary period of traffic loss during the resize. This has been observed during testing on GCP, AWS, and Azure Gateways, where a resize between certain instance sizes produced approximately 2 minutes of packet loss.\
    \
    **Impact:**\
    \
    A Gateway resize can result in a brief traffic interruption, observed at approximately 2 minutes in testing.\
    \
    This has been confirmed to occur on GCP, AWS, and Azure Gateways.\
    \
    **Workaround:**\
    \
    No workaround is currently available. A fix is planned for a future 10.1.x maintenance release.</td></tr>
    <tr><td>AVX-82308</td><td>When the primary gateway in an HA pair is upgraded from Controller 8.0.x to 8.1.x, the controller can temporarily skip BGP route-approval filtering for the HA gateway, because it evaluates only the primary gateway's upgraded setting for both gateways in the pair.\
    \
    **Impact:**\
    \
    Unfiltered BGP routes from the HA gateway can propagate network-wide during the upgrade window, from the time the primary gateway completes its upgrade until the HA gateway also completes its upgrade. This can cause unexpected routing changes or route leaks.\
    \
    **Workaround:**\
    \
    Upgrade all HA gateways before upgrading the corresponding primary gateways. This has been observed to leave an unfiltered-route window of approximately 1 minute immediately after the primary gateway's upgrade completes, after which filtering recovers automatically. You can prevent the breakage by configuring outbound route-maps on the remote BGP peer during the upgrade window.</td></tr>
  </tbody>
</table>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.
Issue	Description
AVX-72940	Creating a new gateway with the same name as an existing gateway may cause local files of the existing gateway to be deleted when the creation fails. The existing gateway name disappears from the Controller CLI once this occurs. This can break SSH access to the existing gateway.\ \ Impact:\ \ SSH access to the existing gateway may stop working Gateway recovery may require manual intervention Affected Scenario:\ \ Gateway creation using a name that already exists.\ \ Workaround:\ \ Do not reuse gateway names. Contact [Aviatrix Support](https://support.aviatrix.com) if recovery is required.
AVX-73436	When using the update\_spoke\_vpc\_route\_table API to onboard an Azure route table, the default route (0.0.0.0/0) is not programmed in the spoke VNET route table if the Spoke Gateway has learned the default route from any of the following sources: an attached Egress Transit Gateway (Transit with egress functionality enabled), a Transit Gateway that learned the default route via an external Site-to-Cloud (S2C) connection (for example, from an on-premises network or third-party appliance advertising 0.0.0.0/0 over IPSec/BGP), or another Spoke Gateway that is propagating the default route within the Aviatrix network. In all of the above cases, although the Spoke Gateway has successfully learned and installed the default route in its own routing table, the route is not re-programmed into the associated Azure VNET route table during the onboarding operation.\ \ Impact:\ \ Default route (0.0.0.0/0) is not installed in the onboarded Azure spoke VNET route table.\ \ Traffic that depends on the default route, including traffic destined for the internet through an egress transit, for on-premises networks through an S2C-connected transit, or for another spoke, may not be routed correctly from the Azure VNET.\ \ Workaround:\ \ Manually add the default route to the Azure route table. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.
AVX-75452	In Azure environments, when Distributed Cloud Firewall (DCF) Security Group Orchestration attaches a Network Security Group (NSG) to a subnet, the subnet name is changed to all lowercase. Although Azure resource names are generally case-insensitive, this modification causes issues with Infrastructure as Code tools such as Terraform, which treat resource names as case-sensitive. Terraform may flag affected subnets for replacement, potentially disrupting existing deployments.\ \ Impact:\ \ Subnet names in Azure are modified to lowercase when Security Group Orchestration attaches NSGs\ \ Terraform plans may show unexpected resource replacements for affected subnets\ \ Customer naming conventions in the cloud may be altered without consent\ \ Workaround:\ \ In Terraform, add a `lifecycle` block with `ignore_changes` for `subnet_id` (as well as `id` in the `azurerm_subnet` resource) to prevent forced resource replacement. Note that this workaround does not restore the original subnet name casing.
AVX-75607	Gateway launch may fail with a `tls: bad certificate` error when pulling container images. The Controller's registry TTL eviction (garbage collection) may fire while images are being downloaded to the gateway, corrupting in-flight blob transfers. The gateway's container initialization cannot complete, and an internal identity-helper service on the gateway exits with code 125.\ \ Impact:\ \ Gateway creation fails with tls: bad certificate or unexpected EOF errors during container image pull The gateway's identity-helper service crash-loops with exit code 125 Manual intervention is required to recover Workaround:\ \ Restart the Controller's core application service to reset the registry state, then retry gateway creation. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.
AVX-79057	Auto-restart of a failed Aviatrix gateway deployed in GCP (GCE) may not succeed, leaving the gateway in a down state until manual intervention.\ \ Impact:\ \ A failed Aviatrix gateway deployed in GCP (GCE) will not be automatically recovered. Traffic through the affected gateway remains disrupted until an operator manually restarts the gateway.\ \ Workaround:\ \ Manually restart the failed GCE gateway from the Controller, or contact Aviatrix Support for assistance.
AVX-79521	On Controller versions prior to 10.1.0, it is possible to onboard multiple Aviatrix access accounts that map to the same underlying cloud service provider (CSP) account. Because several Controller features assume a one-to-one relationship between an Aviatrix access account and a CSP account, duplicate access accounts can lead to unpredictable configuration and operational behavior. Duplicate is defined per CSP as follows:\ \ AWS (including AWS GovCloud and AWS China): same account number, for both IAM role and access/secret key authentication. Azure (including Azure Government and Azure China): same subscription. GCP: same project. OCI (including OCI Government): same tenancy and compartment combination. Alibaba: same account number. Starting in Controller 10.1.0, the Controller blocks new onboarding of duplicate access accounts across all supported CSPs. Existing duplicate access accounts continue to operate as-is and are not automatically removed.\ \ Impact: New duplicate access accounts can still be onboarded on Controller versions prior to 10.1.0. Environments that already have duplicate access accounts may see inconsistent behavior in features that assume a unique CSP account per Aviatrix access account. Workaround:\ \ Onboard only one Aviatrix access account per underlying CSP account. If duplicate access accounts have already been onboarded and are causing issues, contact [Aviatrix Support](https://support.aviatrix.com/) for assistance with identifying and removing the duplicates.
AVX-80977	A VPN user's profile assignment could appear as N/A immediately after the user was attached to a profile through the API, until the user's next reconnection.\ \ Impact:\ \ The user's profile displays as N/A until the user's next reconnection, even though the profile attachment succeeded.\ \ This can cause confusion when auditing or verifying profile-based access policies shortly after attachment.\ \ Workaround:\ \ Have the affected user reconnect to update the displayed profile assignment. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.
AVX-81230	Enabling both Policy-Based Routing (PBR) and NAT logging under User VPN settings can cause high CPU utilization on the User VPN gateway during data-plane traffic. The high CPU usage occurs because NAT log entries generated by PBR are written to the gateway's serial console.\ \ Impact:\ \ User VPN gateways with both PBR and NAT logging enabled may experience elevated CPU utilization while passing data-plane traffic, which can degrade VPN gateway performance.\ \ Workaround:\ \ Disable NAT logging on the affected User VPN gateway. If NAT logging must remain enabled, contact [Aviatrix Support](https://support.aviatrix.com/) to apply a backend workaround.
AVX-81576	During a Gateway resize operation (for example, changing the Gateway's underlying instance or VM size), the Gateway can experience a temporary period of traffic loss during the resize. This has been observed during testing on GCP, AWS, and Azure Gateways, where a resize between certain instance sizes produced approximately 2 minutes of packet loss.\ \ Impact:\ \ A Gateway resize can result in a brief traffic interruption, observed at approximately 2 minutes in testing.\ \ This has been confirmed to occur on GCP, AWS, and Azure Gateways.\ \ Workaround:\ \ No workaround is currently available. A fix is planned for a future 10.1.x maintenance release.
AVX-82308	When the primary gateway in an HA pair is upgraded from Controller 8.0.x to 8.1.x, the controller can temporarily skip BGP route-approval filtering for the HA gateway, because it evaluates only the primary gateway's upgraded setting for both gateways in the pair.\ \ Impact:\ \ Unfiltered BGP routes from the HA gateway can propagate network-wide during the upgrade window, from the time the primary gateway completes its upgrade until the HA gateway also completes its upgrade. This can cause unexpected routing changes or route leaks.\ \ Workaround:\ \ Upgrade all HA gateways before upgrading the corresponding primary gateways. This has been observed to leave an unfiltered-route window of approximately 1 minute immediately after the primary gateway's upgrade completes, after which filtering recovers automatically. You can prevent the breakage by configuring outbound route-maps on the remote BGP peer during the upgrade window.