WatchGuard published three AuthPoint Authentication Gateway vulnerabilities on November 4, 2026. Two of them show how much security depends on the relationship between the gateway and the identity services it calls.
CVE-2026-121638 is an improper certificate-validation issue that affects AuthPoint Authentication Gateway before 7.6.0 when the deployment uses a RADIUS, LDAP, or ADFS resource. WatchGuard says an attacker in an on-path network position can intercept and modify communications between the gateway and local authentication providers. The vendor has no indication of exploitation in the wild.
CVE-2026-121637 is an integrity failure in the LDAP authentication callback. WatchGuard says a network attacker who has obtained a valid header signature can forge the authentication result and transaction identifier in the request body. CVE-2026-121639 is an improper-authentication flaw that permits an unauthenticated denial of service. All three fixes are in version 7.6.0.
A gateway is a trust broker
AuthPoint Gateway receives authentication requests from network equipment, consults local or remote identity sources, and returns an authorization result. That result may decide whether a VPN session, administrative login, or other protected service succeeds.
The certificate flaw sits on the outbound side of that exchange. The gateway is supposed to authenticate the local authentication provider before trusting its response. If certificate validation is wrong, an on-path attacker may be able to present a different endpoint and influence the exchange. The attacker still needs a network position and an affected deployment with a relevant resource. The advisory does not support a claim that any internet client can exploit every gateway.
The callback flaw is different. It concerns the integrity of an LDAP authentication response after a valid header signature is present. A forged body can separate the signed envelope from the authentication decision inside it. In a weak design, the signature covers a request but not the security-relevant fields that determine the outcome.
That is a recurring problem in federation and callback systems: teams validate that a message came from the right place but forget to bind the message to the transaction, user, result, and nonce. When those fields are separate, an attacker can reuse a valid envelope with a different payload.
Check the deployment shape
Start with an asset inventory of AuthPoint Gateways. Record the version, management address, internet reachability, and every RADIUS, LDAP, and ADFS resource they use. The affected scope is not every AuthPoint component. It is the Authentication Gateway deployment, and the certificate flaw requires a configured local authentication resource.
Trace the network path from each gateway to each provider. Identify where traffic crosses a shared network, a load balancer, a proxy, or an untrusted segment. TLS should authenticate the provider with a trusted certificate and the expected hostname or identity. Disabling validation, accepting self-signed certificates without a pinned trust anchor, or relying on an application-level secret without checking the peer certificate weakens the boundary.
Review the callback implementation as well. A valid signature must cover the authentication result, transaction identifier, user or device identity, and any request-specific nonce or timestamp. The gateway should reject replayed or mismatched callbacks. Logging should preserve the request identifier and the provider identity without recording passwords or tokens.
Patch and verify
Upgrade to AuthPoint Authentication Gateway 7.6.0 or later. After the upgrade, verify the running version through the management interface and confirm that each gateway connects to the intended providers. Do not assume that a successful package update changed every node in an HA pair.
Test certificate validation with a controlled endpoint. A gateway should reject an unexpected certificate and a certificate for the wrong hostname. In a lab, confirm that a proxy cannot terminate and replace the provider connection without producing a failure.
Then test callback rejection. Reuse a previously valid callback with a different transaction identifier and confirm that it fails. Change an authentication result without changing the signature and confirm that the gateway rejects the message. Test an unsigned or malformed callback as well. These checks are stronger than a version banner because they show that the intended trust relationship is enforced at runtime.
Review logs for failed provider validation, unexpected certificate changes, and callback signature failures. A burst of failures may be an operational error or an attempted interception. Responders should correlate it with network changes and authentication outcomes rather than treating a single log line as proof of compromise.
Protect the path after the patch
CVE-2026-121638 is especially relevant to on-path attackers. Network segmentation and TLS inspection policies should not create a new endpoint that the gateway silently trusts. Keep authentication traffic on a controlled management network where possible, and document every TLS-intercepting device.
Rotate any secret that could have been exposed if a forged callback changed an authentication outcome. Review sessions created during the exposure window, especially privileged accounts and service accounts. The gateway fix closes the coding defect; it does not erase the effect of sessions that were already approved.