Repository navigation
Harden Teams & WhatsApp Cloud webhook adapters (security audit) #48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
8504501
fix(webhook): harden Teams and WhatsApp Cloud adapters
lao 0a36bdf
docs: add security & performance audit report
lao 7d7e465
test(webhook): assert shed requests never read the body
lao 7ece811
docs(audit): per-adapter auth detail, exact toolchain versions, preci…
lao 1b53f8a
docs(audit): apply review fixes to security & performance report
botbooter-test[bot] f12c72f
fix(webhook): apply review fixes to Teams adapter and audit report
botbooter-test[bot] f1ea2fe
docs(audit): apply review fixes to security & performance report
botbooter-test[bot] abd2186
docs: drop audit plan and report from the repo
lao File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[low] Teams holds readSem through JWT/JWKS validation, unlike the HMAC-fast siblings it copies
The
readSemslot is acquired at the top ofhandleMessagesand released only when the function returns (defer func() { <-a.readSem }()), so it is held acrossvalidateInbound— RS256 verification plus a potential cold JWKS fetch bounded byjwksFetchTimeout(~15s). In the GitHub/GitLab siblings this constant (maxConcurrentReads = 16) gates only a fast HMAC/token compare, so a slot frees almost immediately. In Teams, under a legitimate burst that coincides with a JWKS refresh, up to 16 slots can stay occupied for seconds, shedding the 17th+ authentic request with 503. The behavior is safe (the platform retries) but the reused16doesn't account for the much longer hold, so this is a genuine divergence from the scaffolding it claims to mirror. Consider either releasingreadSemright after the body read/unmarshal (beforevalidateInbound) or documenting/sizing the constant for the JWT path. Marking low/uncertain — it only bites during a cold JWKS fetch under concurrent load.🤖 AI prompt to fix (review before running)