WatchGuard published four advisories for its on-premises AuthPoint Authentication Gateway on 4 November 2026 and fixed all of them in version 7.6.0. Two of the flaws sit in the LDAP callback that tells the gateway whether a login succeeded, which is the part SMEs rely on to make MFA mean something.

What happened

CVE-2026-121637 (CVSS 8.9) is improper integrity validation in the gateway's LDAP authentication callback. An attacker who has obtained a valid header signature can alter the authentication result and transaction identifier in the request body, so the gateway accepts an outcome the identity provider never gave.

CVE-2026-121639 (CVSS 9.2) is missing authentication for a critical function: anyone who can reach the gateway host over the network can disrupt authentication services and delete the local directory synchronisation configuration. CVE-2026-121638 (CVSS 9.1) skips certificate validation between the gateway and the local authentication providers, letting an on-path attacker read and modify that traffic. CVE-2026-121640 (CVSS 9.1) allows capture-replay of a legitimate request between gateway components to perform administrative actions, including shutting authentication down.

WatchGuard says it has no evidence any of the four has been exploited in the wild.

Who is affected

Every AuthPoint Authentication Gateway release from 1.0 up to 7.6.0. The advisories name the gateway component specifically.

• Organisations running an on-premises AuthPoint Gateway in front of VPN, remote desktop, OWA or a RADIUS-backed appliance.
• Deployments where the gateway is reachable from the internet because remote staff authenticate through it.
• Sites that installed the gateway once and never revisited it, which is common when MFA was set up as a once-off project.
• Anyone who only consumes WatchGuard's cloud MFA service and never deployed a gateway host, but that should be confirmed in the management console rather than assumed.

What to do now

Upgrade the AuthPoint Gateway to 7.6.0 or later this week and put an allow-list in front of the gateway host.

• Inventory every gateway instance, including test or forgotten deployments that still point at production Active Directory.
• Upgrade to 7.6.0, then confirm the version on the host rather than trusting the console.
• Restrict reachability to the gateway to the addresses that genuinely need it, and close management ports to the internet.
• After upgrading, pull gateway and directory-sync logs for the deployment's lifetime and look for synchronisation configurations that were deleted or recreated, and for authentication events with no matching identity-provider log.

What this means for South African businesses

For most South African SMEs, MFA is one gateway in front of everything remote, so a forgeable callback is the difference between a password spray that fails and one that does not. The forgery needs a valid header signature before it works, so in practice it is a follow-on move after an attacker is already on the network, not something a scanner finds. The 9.2 denial of service is the opposite: it needs nothing but a route to the host, and a gateway that is down blocks every remote worker at once. If that host answers on a public address with no allow-list, that is the fix to make today, whatever version you are running.

Source: WatchGuard PSIRT advisory index.

Also on the blog

• GhostMap: one Android APK, no permissions, an endless reboot loop
• BookIt CVE-2026-62048: unauthenticated SQL injection at 9.3, patch 2.6.0.7

Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.