SURIQ
Kong's API gateway shipped a fix for a way to walk straight past its single sign-on. Tracked as CVE-2026-14917, the flaw sits in the gateway's SAML plugin, the component that lets an external identity provider vouch for who a user is. On affected deployments, a request carrying a forged, unsigned SAML response could be accepted as genuine, and the attacker could log in as any user the gateway knows, administrators included. One configuration flag decides whether this touches you, so the first job is not to patch blindly. It is to find out which of your gateways were ever set up the risky way.
Kong assigned the CVE and published it on September 16, 2026, and rates it High, CVSS 7.7. There is no sign of exploitation in the wild, it is not on the US cybersecurity agency's Known Exploited Vulnerabilities list, and we found no public proof-of-concept at the time of writing. That makes this a patch-and-audit story rather than a fire drill, but the audit half matters more than usual here.
What the flaw lets an attacker do
SAML, short for Security Assertion Markup Language, is the login standard that lets one system trust another to authenticate users. The trust rests on a cryptographic signature: the identity provider signs its response, and the service that receives it checks that signature before believing anything inside. CVE-2026-14917 is a case where that check could be skipped.
Kong's own CVE record is precise. With the SAML plugin's validate_assertion_signature option set to false, the plugin would read the identity straight out of an unsigned assertion and log that user in, with no signature check performed at all. Any unauthenticated attacker who can reach the login endpoint could then send a hand-built SAML response and take on any account the gateway manages. Kong classes the weakness as CWE-288, authentication bypass using an alternate path or channel.
Read the CVSS vector and the real prize comes into focus. Kong scores no confidentiality, integrity, or availability impact on the gateway itself, but High impact on the systems downstream of it, in the vector's subsequent-system confidentiality metric. The gateway is not the target. Everything it sits in front of is. A bypass here is a skeleton key to the APIs and applications the gateway was deployed to protect.
| Release branch | Affected | Fixed in |
|---|---|---|
| 3.15.x | below 3.15.0.3 | 3.15.0.3 |
| 3.14.x | below 3.14.0.12 | 3.14.0.12 |
| 3.13.x | below 3.13.0.9 | 3.13.0.9 |
| 3.12.x | below 3.12.0.10 | 3.12.0.10 |
| 3.10.x | below 3.10.0.17 | 3.10.0.17 |
| 3.4.x | below 3.4.3.29 | 3.4.3.29 |
Who is exposed
Here is the part the one-line advisory summaries flatten. The vulnerable behavior only appears when validate_assertion_signature has been turned off, and that option is enabled by default. A stock Kong SAML setup, left as shipped, is not exposed. The deployments at risk are the ones where an operator deliberately set that flag to false.
Why would anyone do that? SAML lets an identity provider sign the assertion, the surrounding response, or both. Teams whose provider signs the response rather than each individual assertion sometimes switch off assertion-signature validation to make the integration work, assuming the plugin would fall back to checking the response signature instead. Per Kong's Gateway changelog, that fallback never fired. A branch that should have taken over was unreachable, so when the assertion carried no signature of its own, nothing got checked at the response level either. The setting read like "verify a different signature." In practice it meant "verify no signature." That gap between operator intent and plugin behavior is the whole vulnerability.
Why SAML keeps handing out this bug
This is not the first signature-validation bypass we have written up this quarter, and it will not be the last. We covered a near-identical failure in CoreWCF's SAML token handling and another in Keycloak. Authentication and account-takeover bugs are not exotic: our threat desk has logged 1,133 of them in the last 90 days, the fourth-heaviest bug class we track. SAML's optionality is a big part of the reason. A protocol that lets you sign this element, or that one, or both, invites implementations that verify the wrong one, or nothing. Kong's fix also hardens the plugin against XML Signature Wrapping, a long-standing trick where an attacker keeps a genuinely valid signature in the document but points it at the wrong element, so this specific bug is one instance of a pattern the plugin now guards more broadly.
plugins:
- name: saml
config:
validate_assertion_signature: true
idp_certificate: "your IdP signing certificate in PEM form"Audit the signature flag before you patch
Upgrading is the durable fix, and the versions are in the table above: move to 3.15.0.3, 3.16.0.0, or the backport for your branch. But because the exposure is config-gated, the faster win is to inventory it. Check every Kong node running the SAML plugin and confirm whether validate_assertion_signature was ever set to false. Where it was, treat those gateways as the priority and assume any SAML-authenticated session on them could be forged until you patch.
On detection, the fixed plugin logs a warning when neither validate_assertion_signature nor idp_certificate is set, so that warning is a signal to watch after you upgrade. The higher-value hunt is correlation. A forged SAML login never touched your identity provider, so a privileged sign-in recorded at the gateway with no matching authentication event at the provider is exactly the anomaly to alert on. That cross-source check is what an XDR approach and an active threat-hunting practice are built to catch, and it is worth wiring up whether or not you run Kong. When a bypass slips through, the record that proves it lives at the identity provider, not the gateway that was fooled.