PRISMA-2022-0227 in kube-state-metrics: What It Is & How to Fix It

Q: Is PRISMA-2022-0227 a CVE?

No. PRISMA-2022-0227 is a Palo Alto Networks Prisma Cloud proprietary finding ID, not a CVE. It was assigned before the underlying go-restful issue received broad CVE coverage, which is why scanner output and public CVE databases don't always cross-reference cleanly.

Q: Does this affect kube-state-metrics directly?

Only transitively. kube-state-metrics doesn't call the vulnerable go-restful routing code path itself, but the module is present in its dependency tree via client-go/apimachinery, which is enough for container scanners to flag the image.

If a container security scanner flagged your kube-state-metrics image with finding ID PRISMA-2022-0227, here's exactly what it means, why it appears, and how to resolve it.

PRISMA-2022-0227 Is Not a CVE

PRISMA-2022-0227 is a Palo Alto Networks Prisma Cloud (formerly Twistlock) proprietary vulnerability-database finding ID — it is scanner-specific, not a CVE assigned by MITRE/NVD. That's why searching CVE databases directly for this exact string often comes up empty; you have to trace it back to the underlying library issue instead.

What It Actually Flags


Affected module	`github.com/emicklei/go-restful/v3`, versions prior to `v3.10.1`
Issue type	Authentication Bypass by Primary Weakness
Root cause	An inconsistency in how go-restful parses URL paths, which can cause routing/security-check mismatches in front of it (e.g. a reverse proxy and the application disagreeing on the effective path)
Severity	High — CVSS 7.5
Fix	Upgrade `go-restful` to `v3.10.1` or later — see the upstream go-restful advisory

Why It Shows Up in kube-state-metrics Scans

kube-state-metrics doesn't call go-restful's HTTP routing directly for its own /metrics endpoint. The module is pulled in transitively through k8s.io/client-go and k8s.io/apimachinery, which vendor go-restful as part of their API-machinery tooling. Any Go binary built against those Kubernetes client libraries will show go-restful in its dependency tree (and therefore in an SBOM/vulnerability scan), whether or not the binary ever exercises the vulnerable routing path.

ℹ️

This is the same reason PRISMA-2022-0227 shows up across a wide range of unrelated Kubernetes-adjacent projects — Terraform providers, Kong's ingress controller, cri-tools, sealed-secrets — anything built against client-go/apimachinery from that era inherits the same transitive dependency.

How to Remediate

Update the image. Pull a current kube-state-metrics release — see the Docker image & version guide for tags and the registry path. Recent releases build against updated client-go/apimachinery versions that carry the patched go-restful.

Verify the fix. Run your scanner against the new image and confirm the finding is gone, or check the binary's embedded module list:

skopeo inspect docker://registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.19.1 | grep -i go-restful
# or, if you have the binary:
go version -m ./kube-state-metrics | grep go-restful

If you're already patched but still flagged, your scanner may be matching on the vendored module path rather than the resolved version — check the actual resolved version in go.sum/the SBOM rather than trusting a version-string match alone, and file a waiver/exception in Prisma Cloud referencing the confirmed patched version.

FAQ

Is PRISMA-2022-0227 a CVE?

No — it's a Prisma Cloud-specific finding ID, not a CVE assigned by MITRE/NVD.

Does this affect kube-state-metrics directly?

Only transitively, via client-go/apimachinery's dependency on go-restful — kube-state-metrics's own /metrics endpoint doesn't use go-restful's routing.

Do I need to do anything besides upgrade the image?

No further application changes are required — this is purely a dependency-version fix, not a configuration or RBAC change.

PRISMA-2022-0227 in kube-state-metrics: Explained