> ## 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 9.0.31 Release Notes

> Release Date: 5 November 2026

Release Date: 5 November 2026

> [!WARNING]
>
> **Upgrade guidance for this security fix release**: This release applies a mitigation for a Linux kernel vulnerability (CVE-2026-98432) on gateways. The Controller
> receives the kernel fix through operating system updates, so you do not need
> to upgrade the Aviatrix software first. The fix takes effect only after you
> reboot the Controller, so check the Controller kernel version and reboot the
> Controller as soon as you can. Gateways running 8.1.x or later are mitigated shortly after the Controller is upgraded. When you have a maintenance window, upgrade
> the Controller to 9.0.31, and then upgrade the gateways to 9.0.31. For how to check
> the kernel version and the fixed versions, see the [PSIRT Advisories](https://docs.aviatrix.com/docs/enterprise/8.2/reference/release-notices/psirt-advisories/index.md#cve-2026-98432-linux-kernel-tcp-vulnerability).

## Corrected Issues in Aviatrix Release 9.0.31

This release applies a mitigation for the following CVE advisory, detailed on the [PSIRT Advisories](https://docs.aviatrix.com/docs/enterprise/8.2/reference/release-notices/psirt-advisories/index.md#cve-2026-98432-linux-kernel-tcp-vulnerability) page:

* [CVE-2026-98432](https://nvd.nist.gov/vuln/detail/CVE-2026-98432): Linux kernel IPv4 TCP race condition.

## Known Issues in Aviatrix Release 9.0.31

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

  <tbody>
    <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:\
    \
    <ul><li>An attached Egress Transit Gateway (Transit with egress functionality enabled)</li><li>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)</li><li>Another Spoke Gateway that is propagating the default route within the Aviatrix network</li></ul>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:**\
    \
    <ul><li>Default route (0.0.0.0/0) is not installed in the onboarded Azure spoke VNET route table.</li><li>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.</li></ul>**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:**<ul><li>Subnet names in Azure are modified to lowercase when Security Group Orchestration attaches NSGs</li><li>Terraform plans may show unexpected resource replacements for affected subnets</li><li>Customer naming conventions in the cloud may be altered without consent</li></ul>**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-78500</td><td>When Distributed Cloud Firewall (DCF) is disabled on a gateway, DCF policy enforcement may not be fully removed from all gateway interfaces. As a result, traffic can continue to be evaluated against the previously applied DCF policy even though DCF appears disabled. This can occur when DCF is disabled without any accompanying policy change.\
    \
    **Impact:**\
    \
    \* After DCF is disabled, a gateway may continue enforcing the last applied DCF policy on some interfaces.\
    \* This residual enforcement is not reflected in the DCF status shown for the gateway and may persist until DCF is re-enabled or the gateway configuration changes.\
    \
    **Workaround:**\
    \
    When disabling DCF, also make a minor DCF policy change (for example, add and then remove a rule) so enforcement is fully cleared from all interfaces. If you suspect DCF policy is still being enforced after disabling DCF, contact [Aviatrix Support](https://support.aviatrix.com/).</td></tr>
    <tr><td>AVX-78671</td><td>Enabling Logging on the Default Action Rule and then disabling it can cause the Monitor tab to continue showing log entries for that rule for up to one hour after Logging is turned off.\
    \
    **Impact:**\
    \
    \* After you disable Logging on the Default Action Rule (following a period when Logging was enabled and traffic was flowing), the Monitor tab continues to display log entries for that rule for up to one hour.\
    \* Excess log volume during that hour can make it harder to review logs for other Distributed Cloud Firewall (DCF) rules.\
    \
    **Workaround:**\
    \
    No action is required. Logging for the Default Action Rule stops automatically once the one-hour period elapses. Until then, you can filter Monitor tab entries by rule name to distinguish residual Default Action Rule logs from current rule activity.</td></tr>
    <tr><td>AVX-79012</td><td>Some gateways may become stuck in a failed configuration-push state for an extended period after an Image Upgrade to Aviatrix 10.0.0 (from 9.0.10). This has been observed primarily on lower-memory gateway instance types (for example, AWS t3.micro).\
    \
    **Impact:**\
    \
    Affected gateways may show a "Not Up-To-Date" config status and a down backup tunnel hours after the image upgrade completes. The root cause is a Distributed Cloud Firewall (DCF) configuration push failure caused by insufficient available memory on memory-constrained instance types.\
    \
    **Workaround:**\
    \
    Retry the gateway Image Upgrade. If the gateway remains stuck in this state, increase the gateway's instance size for additional memory headroom, or contact [Aviatrix Support](https://support.aviatrix.com/).</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-80997</td><td>GCP event logging can fail with an InvalidArgument error when a Cloud Asset Inventory service account is linked to a large number of GCP projects, causing the logging filter to exceed the Google Cloud Logging API 20,000-character limit.\
    \
    **Impact:**<ul><li>GCP event monitoring stops working for the affected service account, and any event-based alerts or automation depending on it do not fire.</li><li>The error recurs on every polling attempt until the number of linked GCP projects is reduced.</li></ul>**Workaround:**\
    \
    Reduce the number of GCP projects linked to a single Cloud Asset Inventory service account to fewer than 100. 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:**<ul><li>A Gateway resize can result in a brief traffic interruption, observed at approximately 2 minutes in testing.</li><li>This has been confirmed to occur on GCP, AWS, and Azure Gateways.</li></ul>**Workaround:**\
    \
    No workaround is currently available. A fix is planned for a future 10.1.x maintenance release.</td></tr>
  </tbody>
</table>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.
Issue	Description
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) 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-78500	When Distributed Cloud Firewall (DCF) is disabled on a gateway, DCF policy enforcement may not be fully removed from all gateway interfaces. As a result, traffic can continue to be evaluated against the previously applied DCF policy even though DCF appears disabled. This can occur when DCF is disabled without any accompanying policy change.\ \ Impact:\ \ \* After DCF is disabled, a gateway may continue enforcing the last applied DCF policy on some interfaces.\ \* This residual enforcement is not reflected in the DCF status shown for the gateway and may persist until DCF is re-enabled or the gateway configuration changes.\ \ Workaround:\ \ When disabling DCF, also make a minor DCF policy change (for example, add and then remove a rule) so enforcement is fully cleared from all interfaces. If you suspect DCF policy is still being enforced after disabling DCF, contact [Aviatrix Support](https://support.aviatrix.com/).
AVX-78671	Enabling Logging on the Default Action Rule and then disabling it can cause the Monitor tab to continue showing log entries for that rule for up to one hour after Logging is turned off.\ \ Impact:\ \ \* After you disable Logging on the Default Action Rule (following a period when Logging was enabled and traffic was flowing), the Monitor tab continues to display log entries for that rule for up to one hour.\ \* Excess log volume during that hour can make it harder to review logs for other Distributed Cloud Firewall (DCF) rules.\ \ Workaround:\ \ No action is required. Logging for the Default Action Rule stops automatically once the one-hour period elapses. Until then, you can filter Monitor tab entries by rule name to distinguish residual Default Action Rule logs from current rule activity.
AVX-79012	Some gateways may become stuck in a failed configuration-push state for an extended period after an Image Upgrade to Aviatrix 10.0.0 (from 9.0.10). This has been observed primarily on lower-memory gateway instance types (for example, AWS t3.micro).\ \ Impact:\ \ Affected gateways may show a "Not Up-To-Date" config status and a down backup tunnel hours after the image upgrade completes. The root cause is a Distributed Cloud Firewall (DCF) configuration push failure caused by insufficient available memory on memory-constrained instance types.\ \ Workaround:\ \ Retry the gateway Image Upgrade. If the gateway remains stuck in this state, increase the gateway's instance size for additional memory headroom, or contact [Aviatrix Support](https://support.aviatrix.com/).
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-80997	GCP event logging can fail with an InvalidArgument error when a Cloud Asset Inventory service account is linked to a large number of GCP projects, causing the logging filter to exceed the Google Cloud Logging API 20,000-character limit.\ \ Impact: GCP event monitoring stops working for the affected service account, and any event-based alerts or automation depending on it do not fire. The error recurs on every polling attempt until the number of linked GCP projects is reduced. Workaround:\ \ Reduce the number of GCP projects linked to a single Cloud Asset Inventory service account to fewer than 100. 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.