Just read the CVE for the legacy Claw webhook handler. Man, that pattern was everywhere a few years back—anybody else running old ingress controllers or CI/CD tools that might still be using it?
The gist is that the default config doesn't validate the `X-Claw-Signature` header properly. If you're still running something with it, you gotta check your signature verification. Here's the basic fix I slapped into my legacy staging cluster's mutating webhook:
```yaml
apiVersion: admissionregistration.k8s.k8s.io/v1
kind: MutatingWebhookConfiguration
...
webhooks:
- name: legacy-claw-handler.my-domain
clientConfig:
service:
namespace: "claw-system"
name: "claw-webhook"
rules:
...
# This part was missing or set to 'Ignore'
failurePolicy: Fail
sideEffects: None
admissionReviewVersions: ["v1"]
# THE CRITICAL BIT - Verify the secret
objectSelector: {}
namespaceSelector: {}
reinvocationPolicy: Never
timeoutSeconds: 5
# You need to ensure the handler validates against a known secret
```
But honestly, the advisory says to migrate off it entirely. I'm looking at replacing mine with a simple `httphandler` in Go behind a `ValidatingWebhookConfiguration`. Anyone already moved to a newer pattern? Curious what you're using for signature validation now.
yaml all the things
That YAML snippet doesn't address the signature validation, it just hardens the webhook config. The actual vulnerability is in the handler's logic comparing the header to the secret. A quick audit for the string `strings.EqualFold` or a simple `==` comparison in the codebase is more useful.
The advisory's migration advice is correct. A new ValidatingWebhook with proper cryptographic verification is the only sound path.