# GHSA-3278-c88v-xrh4: A vulnerability in the Kong Ingress Controller (KIC) allows for the unauthorized exposure of sensitive plugin credentials through > Unauthenticated attackers on the cluster network can read sensitive plugin credentials from the Kong Ingress Controller diagnostics endpoint if diagnostics are enabled. - **Severity:** Not scored - **Exploited in the wild:** Not known - **Login needed:** Not needed - **Attackable:** Local or same network only - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 19 May 2026 - **Also known as:** GO-2026-5010 ## What is GHSA-3278-c88v-xrh4? GHSA-3278-c88v-xrh4 is a vulnerability in github.com/kong/kubernetes-ingress-controller, published on 19 May 2026. It can only be exploited from the same machine or local network, with no action from the victim. ### Official description ## Summary A vulnerability in the Kong Ingress Controller (KIC) allows for the unauthorized exposure of sensitive plugin credentials through the diagnostics interface. Even when configured to redact sensitive information (using `--dump-sensitive-config=false`), KIC fails to sanitize the `Plugins` field in diagnostic configuration dumps. This causes secrets referenced via `configFrom.secretKeyRef` to be resolved and displayed in plaintext. Because the diagnostics HTTP endpoints require no authentication, any process within the cluster network capable of reaching the KIC pod can exfiltrate sensitive data, including API keys, bearer tokens, and database passwords. ## Am I affected? You are affected if all of the following hold: 1. You are using Kong Ingress Controller with **diagnostics enabled** (`--dump-config=true`). 2. You have **not explicitly enabled** sensitive dumping (`--dump-sensitive-config=false`), creating an expectation of redaction. 3. You use `KongPlugin` or `KongClusterPlugin` resources that reference Kubernetes Secrets via **`configFrom.secretKeyRef`**. 4. The KIC diagnostics port (default `10256`) is reachable by other workloads or users within your cluster. You are not affected if: - The `--dump-config` flag is set to `false` (default behavior). - You do not use secret-backed configurations in your Kong plugins. - Access to the KIC pod's diagnostic port is strictly blocked by NetworkPolicies. ## Mitigation 1. **Disable Diagnostics**: If not actively debugging, disable the diagnostic server by setting `--dump-config=false`. 2. **Network Isolation**: Implement a `NetworkPolicy` to restrict access to the KIC diagnostics port (default `10256`), ensuring only authorized administrative pods or IPs can reach it. 3. **Restrict Port-Forwarding**: Limit `kubectl port-forward` RBAC permissions to prevent unauthorized users from accessing the pod's local ports. ## Fix The fix introduces proper sanitization for the `Plugins` field within the configuration state. When sensitive dumping is disabled, the controller now replaces all plugin configuration values with a redaction placeholder before they are served via the diagnostics endpoints. Additionally, it is recommended to ensure your deployment environment follows the principle of least privilege regarding network access to controller components. Users should upgrade to the latest patched version of Kong Ingress Controller to ensure diagnostic dumps are correctly redacted. ## Which versions are affected by GHSA-3278-c88v-xrh4? 9 open source packages ship an affected version, including github.com/kong/kubernetes-ingress-controller, github.com/kong/kubernetes-ingress-controller/v2 and github.com/kong/kubernetes-ingress-controller/v3. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `github.com/kong/kubernetes-ingress-controller` | Go | All versions | None | | `github.com/kong/kubernetes-ingress-controller` | Go | All versions to 1.3.4 | None | | `github.com/kong/kubernetes-ingress-controller` | Go | All versions to 1.3.4 | None | | `github.com/kong/kubernetes-ingress-controller/v2` | Go | All versions | None | | `github.com/kong/kubernetes-ingress-controller/v2` | Go | All versions to 2.12.8 | None | | `github.com/kong/kubernetes-ingress-controller/v2` | Go | All versions to 2.12.8 | None | | `github.com/kong/kubernetes-ingress-controller/v3` | Go | All versions | 3.5.7 | | `github.com/kong/kubernetes-ingress-controller/v3` | Go | All versions | 3.5.7 | | `github.com/kong/kubernetes-ingress-controller/v3` | Go | All versions | 3.5.7 | ## How do I fix GHSA-3278-c88v-xrh4? Apply the vendor's patch. ## Is GHSA-3278-c88v-xrh4 being exploited? There is no known exploitation of GHSA-3278-c88v-xrh4 in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for GHSA-3278-c88v-xrh4 and fix it if it is affected. What it is: GHSA-3278-c88v-xrh4 is a vulnerability in github.com/kong/kubernetes-ingress-controller, published on 19 May 2026. It can only be exploited from the same machine or local network, with no action from the victim. Exploitation: There is no known exploitation of GHSA-3278-c88v-xrh4 in the wild and no public exploit code. Affected packages and fixed versions: - github.com/kong/kubernetes-ingress-controller (Go): affected all versions; no fix listed - github.com/kong/kubernetes-ingress-controller (Go): affected all versions up to 1.3.4; no fix listed - github.com/kong/kubernetes-ingress-controller (Go): affected all versions up to 1.3.4; no fix listed - github.com/kong/kubernetes-ingress-controller/v2 (Go): affected all versions; no fix listed - github.com/kong/kubernetes-ingress-controller/v2 (Go): affected all versions up to 2.12.8; no fix listed - github.com/kong/kubernetes-ingress-controller/v2 (Go): affected all versions up to 2.12.8; no fix listed - github.com/kong/kubernetes-ingress-controller/v3 (Go): affected all versions; fixed in 3.5.7 - github.com/kong/kubernetes-ingress-controller/v3 (Go): affected all versions; fixed in 3.5.7 - github.com/kong/kubernetes-ingress-controller/v3 (Go): affected all versions; fixed in 3.5.7 Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/GHSA-3278-c88v-xrh4/ (Markdown: https://insights.sbomify.com/GHSA-3278-c88v-xrh4/index.md) ``` ## Sources - OSV: https://osv.dev/vulnerability/GHSA-3278-c88v-xrh4 --- From sbomify Insights: https://insights.sbomify.com/GHSA-3278-c88v-xrh4/ Summaries are generated and may contain mistakes; the official description above is the record.