Skip to content

Bug template

Security fix

Close a hole without opening another. Use it when: someone can read, change or do something they should not.

MarkdownHighlighted: fill these in
# [Who] can [do what they should not] ## Intent[Who] can [read / change / do what] although they should not, which exposes [what]. ## Context- Found by: [report, scan, review], severity [low / medium / high]- Where: [endpoint, policy, function], [`path/to/file`]- Rule that should apply: [who may do it, from the permissions docs] ## Steps to reproduce1. As [role or anonymous], [do the exact request].2. Observe [what is returned or changed]. ## Expected[Refused with what status, nothing returned or changed.] ## Actual[What happens.] ## Constraints- People who may do it today keep being able to.- Fix it where the rule is enforced (database, server), not only in the UI. ## Out of scope- Disclosure and customer communication (handled separately) ## Open questions- [Is there any sign the weakness was used, and who must know before the release? Remove it when settled.] ## Acceptance checks- As [role], the request is refused and nothing is returned or changed- As [allowed role], it works as before- An automated test covers both cases 

Give your next agent a brief.

Free for up to 10 people, with MCP for every agent. No credit card.