3.4.12 breaks clusters with Kong OSS (3.9)

[ocdlroux]

Hi, while I can understand you are pivoting business model and deprecating the Kong OSS & free versions, it seems you released a version of KIC breaking all the clusters running Kong v3.9.

However, from the PR in question (#7853), you knew this would happen (cf. https://github.com/Kong/kubernetes-ingress-controller/blob/247aeb9006abd52f92ae6d7ee306842bae098a54/internal/dataplane/testdata/golden/ingress-v1-rule-with-tls-and-consumer-ee/note.txt).

You still proceeded without any care for anyone working in the field, and released your backwards-incompatible version as a patch that would auto-update with the default tag in the Helm chart being 3.4.

This kind of predatory behavior is one you should be ashamed of.

---

For anyone stumbling into this issue, the fix is to lock the KIC to the 3.4.11 tag, maybe even with the hash to prevent any further breakage from upstream.

Further remediation will be to completely switch away from this software altogether.

[amatho]

This caused some significant downtime for our test environment yesterday, and it's only by sheer luck that it didn't happen in production. Not only is it insane to release a breaking change in a patch release, but the kong chart only pins the minor version in the image tag for the controller! As Helm themselves say in their docs, the image tag should not be "floating".

[CoSNaYe]

This broke our production for several hours. 😢

[pmalek]

The change that caused this (#7853) has been merged to mitigate an issue (#7831) which has been inaccurately triaged:
it aimed to fix a related issue which only affected 3.9.x versions where an invalid part of the config (e.g. invalid CA) would cause errors for SNIs with certificate backreference.
SNI certificate backreferences are optional in 3.10.x (they are not required in db less mode) and later versions of Kong but are required in 3.9 and older (due to a bug which was fixed in 3.10) hence this only breaking 3.9 (or older versions).

We've released 3.4.13 (and will release 3.5.6) reverting aforementioned change to mitigate the issue for 3.9.x users.

I'm going to leave this open for a while to monitor if there are any further reports about this.

[paulden]

Hello,

Thanks for the mitigation patch. I notice the CHANGELOG.md doesn't appear to be maintained anymore, and I can't find changelogs for the latest releases, including 3.4.12 which caused the recent issues. Is it available somewhere else? Since we've now seen that patch versioning cannot be fully trusted, being able to manually review changes before upgrading would be a significant help.

Anyway, my understanding is that Kong Gateway for OSS users will remain capped at version 3.9, based on this comment of December 2025 (not an official Kong statement). If that's the case, new releases would be Enterprise only, leaving OSS users who want to stay on an up-to-date gateway with two options: switch to the Enterprise edition or migrate to a different tool entirely.

[pmalek]

I notice the CHANGELOG.md doesn't appear to be maintained anymore, and I can't find changelogs for the latest releases, including 3.4.12 which caused the recent issues. Is it available somewhere else?

The changelog has been updated now, and contains the changes for 3.4.12 and 3.5.6

Anyway, my understanding is that Kong Gateway for OSS users will remain capped at version 3.9, based on this comment of December 2025 (not an official Kong statement). If that's the case, new releases would be Enterprise only, leaving OSS users who want to stay on an up-to-date gateway with two options: switch to the Enterprise edition or migrate to a different tool entirely.

OSS users can still use https://github.com/kong/kong but they will be required to build the images themselves as those are not provided anymore.

As for the 3.9.x OSS series: there's an update on the upcoming 3.9.2 release in Kong/kong#14833 (comment).