clawpatrol-plugin-aws

Both findings come from the same scan of at 0.3.9. Unrelated to each other; one commit each. Version -> 0.3.10. Integer overflow in the aws-chunked decoder () parses the hex chunk size as an int64 and bounded it with . The size field is written by the agent, so reaches it: the sum wraps to , lands below every length, clears the bound, and panics on an out-of-range high index. Agent reachable and a one-line request to trigger; 's recovers it, so the blast radius is the offending agent's own connection — no process exit and no gating bypass. the bound is now . The read offset holds to for the whole scan, so cannot go negative, and the comparison itself does no arithmetic. Clearing it proves exact and within the trailing-CRLF probe counts its two bytes the same way, so no bound in the function has the read offset as the left operand of an addition compared against a length. Not reachable at (256 MiB) and not on any released target (all 64-bit), but it leaves the invariant local to the function instead of resting on a caller's cap the negative-size guard above the bound is load-bearing and now says so: honors a sign prefix in base 16, and clears a subtractive bound and slices backwards covers the size field at with and without bytes left, past , negative, non-hex, zero, exactly the bytes that remain, and one byte over. The two cases fail against the previous bound (the harness turns the panic into a failure rather than taking the binary down); the rest pin boundaries that hold either way ~3M executions over the decoder, no panic Vulnerable indirect dependencies () , and are all indirect, reached only through 's go-plugin transport. One raises all three, since grpc 1.83.2 requires x/net 0.58.0 and x/text 0.41.0 itself — no direct dependency moves, no explicit require added, stable. grpc 1.81.1 -> 1.83.2 clears GO-2026-6061, GO-2026-6348, GO-2026-6443 and GO-2026-6441 (the fourth was not in the finding; same module, same bump). 1.84.0 is skipped because it falls inside GO-2026-6443's third affected range x/net 0.55.0 -> 0.58.0 clears GO-2026-5942; x/text 0.37.0 -> 0.41.0 clears GO-2026-5970. x/sys and genproto/googleapis/rpc move forward as a consequence hygiene, not exposure: the plugin's gRPC server speaks only to the local gateway over the go-plugin handshake socket and serves no xDS reports no issues, and the OSV API reports zero advisories against all 25 modules in the build (was 3 modules / 6 advisories) behaviour equivalence checked on the one gRPC surface the plugin has: and an unknown method driven over the handshake socket against a 1.81.1 build and a 1.83.2 build return identical status codes

Observed on the internal gateway with v0.3.8: a signed POST to with body was refused with , as intended. The gateway's actions table has only the preceding rows for that connection; the refused request itself produced no event, so it is invisible on the dashboard and in fixtures. returns before anything is evaluated or emitted. An agent probing for a decoy slot is exactly the request an operator wants to see, so the refusal should be reported through the normal result path (an evaluation with and the reason, or at least a with status 403) before the response is written.

Fixes #10. answered a conflicting-operation request with before anything was evaluated, and every action record this endpoint has comes from a — so the refusal produced no event, and the probe was invisible behind the connection's preceding rows. emit the refusal as a carrying the reason, then write the 403 — the order and shape the gateway's own brokered-dial refusals take ('s ) leave empty and omit / : no rule reached a verdict, and no operation was determined, so a record naming one would read in the audit trail as an API call AWS never saw clamp the operation names a refusal spells out, in length and in count. They are the agent's to choose and the gateway persists verbatim. The clamp is applied when the message is built, never before the distinctness check, so two names differing only past it still refuse the request cap collection at five distinct names. Two already refuse, so the cap cannot change the verdict; it keeps the distinctness scan off the quadratic a body packed with distinct values would cost clamp the method, service, region and resource the record carries, and the summary built from them. bounds neither the method nor the host those are read off — a 1 MiB method and host are both accepted — and the gateway inserts and the facet JSON into with no bound of its own. Clamping is safe here precisely because a refused request is never evaluated, so nothing clamped is matched by a rule The refusal itself does not move: it is still unconditional and still 403, and it is reached before the base key, the Organizations lookup and any dial. drives the issue's exact probe through with no gateway wired — the worst case, where nothing the plugin reports can be delivered — and asserts the 403 still goes out; asserts a request naming one operation consistently still reaches the policy decision untouched. Two notes for review: on a plugin-emitted event. 's doc comment names both and as hardcoded actions to avoid; the published plugin doc names only , and lists "anything where no rule fired" as a legitimate case. is used here because it is what happened and because the dashboard surfaces an event's reason only for a deny. As the refusal's reason never reaches the live feed, and an operator reads as a gateway fault rather than an agent probing. Say the word and this becomes . was the issue's fallback suggestion, but no-ops unless an left a pending action, so a bare on this path would still record nothing.