0.8.0-dev9: fix webhook HMAC verify silently failing open (security)#10
Merged
Merged
Conversation
Pre-existing bug caught while verifying the dev8 deploy. Both webhooks/meraki.py::_get_shared_secret and webhooks/catalyst_center.py::_get_shared_secret called backend.get_secret(...) — which is NOT a real method on AwsSecretsManagerBackend (actual method: backend.get(path, required=True)). The bare except Exception swallowed the AttributeError, _SECRET_CACHE stayed empty, and both handlers fell through to their "no secret configured" branch — which accepts the webhook without HMAC verification. In other words: every Meraki and Catalyst Center webhook received since these modules shipped has bypassed signature verification. With dev8 publishing :ReflexEvent nodes from those webhooks, any unauthenticated POST could now produce graph artifacts. Changes: - Both handlers now call await backend.get(path, required=False) and distinguish "no secret stored" (return None) from "backend error" (log loudly + return None). - New regression tests in tests/webhooks/test_secret_backend_integration.py that exercise the actual backend call path. The original bug hid because the existing route tests write to _SECRET_CACHE directly via fixture, bypassing _get_shared_secret. Tests now use a FakeBackend with the real .get(path, required) signature. Co-authored-by: Cursor <cursoragent@cursor.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary — security hotfix caught by the dev8 deploy
While verifying the dev8 Meraki webhook publisher end-to-end on `cpn-ful-netcortex1`, an introspection of the secret backend revealed that both `webhooks/meraki.py` and `webhooks/catalyst_center.py` were calling `backend.get_secret(...)` — which is not a real method on `AwsSecretsManagerBackend` (the actual method is `backend.get(path, required=True)`).
The bare `except Exception` swallowed the resulting `AttributeError`, `_SECRET_CACHE` stayed empty, and both handlers fell through to the "no-secret-configured" branch — which accepts the webhook without HMAC verification, with only a warning log.
In other words: every Meraki and Catalyst Center webhook received since these modules shipped has bypassed signature verification. With dev8 now publishing `:ReflexEvent` nodes from those webhooks, an unauthenticated POST could produce graph artifacts.
Why the existing tests didn't catch it
The pre-existing route tests (and the new dev8 ones I just added) inject the secret directly into `_SECRET_CACHE` via fixture, bypassing `_get_shared_secret` entirely. The bug only manifests when a real backend lookup happens — which only happens in production.
Fix
Tests
These tests would have caught the original bug.
Operational notes
After deploy:
Test plan
Made with Cursor