F5’s September Fixes Span BIG-IP and NGINX—Use the Product Matrix

F5’s September security release reaches beyond BIG-IP. On September 3, 2026, Hong Kong GovCERT’s alert identified affected BIG-IP, BIG-IQ, F5OS and NGINX products and said software updates and mitigations were available for affected systems.

The release does not define one universal F5 upgrade. CERT-FR’s September 3 notice connects it to F5 bulletins dated September 2–3 and says some of the vulnerabilities can enable remote code execution, privilege escalation or remote denial of service, among other effects. Operators therefore need to match each installed product, component and software branch to the applicable bulletin.

The release extends beyond BIG-IP appliances

The affected estate can include application-delivery software, central management, endpoint clients, appliance platforms and Kubernetes networking components. The confirmed product families are BIG-IP, BIG-IQ, BIG-IP APM, APM Clients, F5OS, F5OS-A, F5OS-C, NGINX Gateway Fabric, NGINX Ingress Controller and NGINX JavaScript.

That breadth creates a practical ownership problem. An organization may administer BIG-IP and BIG-IQ through one infrastructure team while maintaining F5OS at the platform layer and NGINX controllers through separate Kubernetes pipelines. Updating the most visible BIG-IP systems does not establish that the other affected components were assessed.

The advisories also describe a collection of vulnerabilities rather than one flaw shared identically by every product. Exposure and remediation depend on the installed component, branch and configuration, so the consolidated list is best treated as an inventory boundary—not as evidence that every listed consequence applies to every listed system.

The product and fixed-version matrix

The Canadian Cyber Centre’s September 3 matrix supplies consolidated “prior to” thresholds for the principal BIG-IP, BIG-IQ, APM client and NGINX branches. The version at each boundary is the relevant corrected threshold within that branch; it is not a recommendation to move between release branches without consulting F5’s product-specific guidance.

• BIG-IP, all modules: 17.1.x releases prior to 17.1.3.4, 17.5.x releases prior to 17.5.1.8, 21.0.x releases prior to 21.0.0.3 and 21.1.x releases prior to 21.1.0.1 are listed as affected.
• BIG-IQ: affected 8.4.x installations are those prior to 8.4.2.1.
• BIG-IP APM: the component-specific affected boundaries are 17.1.3.1 for the 17.1.x branch and 17.5.1.4 for the 17.5.x branch. These narrower APM lines do not replace the all-modules BIG-IP thresholds.
• APM Clients: 7.2.x releases prior to 7.2.6 are affected.
• NGINX Gateway Fabric: affected 2.x releases are those prior to 2.6.8.
• NGINX Ingress Controller: affected releases are earlier than 5.6.0 on the 5.x track and earlier than 2026-lts-r5 on the 2026 LTS track.
• NGINX JavaScript: releases prior to 1.0.1 are affected.
• F5OS families: F5OS, F5OS-A and F5OS-C appear in the affected inventory, but the consolidated alerts do not provide one shared corrected threshold. The corresponding F5 advisory must determine the update or mitigation for the installed platform and branch.

This matrix separates branch boundaries that the government advisories state explicitly from F5OS entries that still require product-specific instructions. It should not be used to infer that an unlisted or unsupported branch is safe; the vendor bulletin and product lifecycle status remain controlling for such deployments.

An inventory-first upgrade sequence

A defensible remediation record begins with installed assets rather than a single change ticket for the F5 estate. The objective is to connect every deployed component to a reviewed bulletin, an approved target release or mitigation, and post-change evidence.

1. Enumerate the product families. Record BIG-IP appliances and modules, BIG-IQ managers, BIG-IP APM, endpoint APM Clients, the underlying F5OS family, and deployed NGINX Gateway Fabric, Ingress Controller and JavaScript components.
2. Capture the exact branch. Compare an installed release only with the threshold for its own branch. For example, BIG-IP 17.1.x maps to the 17.1.3.4 boundary, while 17.5.x maps to 17.5.1.8; the standard and 2026 LTS Ingress Controller tracks likewise have separate targets.
3. Resolve each row against the F5 bulletin. Confirm affected configurations, prerequisites, the corrected release and any permitted mitigation. This is essential for F5OS and for any branch whose complete instructions are not reproduced by the consolidated alerts.
4. Plan separate change units. Appliance software, its management plane, the platform layer and Kubernetes controllers may have different owners, dependencies and rollback procedures. Their remediation records should remain distinct even when they belong to the same security release.
5. Re-enumerate after deployment. Record the resulting versions and retain evidence for every product row. Any asset left on a mitigation, awaiting a compatible release or running an unsupported branch should remain an explicit exception.

The release is complete for an organization only when every deployed family has a documented disposition; a successful BIG-IP upgrade alone cannot close the wider scope. Fixed boundaries are available for the principal BIG-IP, BIG-IQ, APM and NGINX lines, while F5OS actions remain tied to the relevant vendor bulletin and deployment conditions. Any later revision to an affected range or remediation instruction should be reconciled against the same asset-to-bulletin record.

Also read:

• Microsoft July 2026 Patch Tuesday: Apply KB5101650 for Windows 11 Security Fixes
• How to Use Big Data to Improve Content Marketing Strategy?
• Fashion Ecommerce SEO: Beautiful Product Pages Can Still Hide Inventory