chore(cats): CATS comma-joins array query params despite explode: true, causing 10 spurious findings

[ericfitz]

Summary

CATS serializes array-valued query parameters as a single comma-joined value regardless of the
parameter's declared explode: true, so the server receives one malformed value instead of repeated
keys. TMI correctly rejects it, and CATS reports the correct rejection as a failure.

Split out of #657 (the upstream example-vs-schema defect) because it is a distinct bug with its
own blast radius, and because it now costs real triage time: it produced 10 true positives in run
20260731T200650Z, three of them from HappyPath, which is exactly the signature of a genuine
server regression.

Evidence

GET /threat_models/{id}/threats (HappyPath, test 95506) — CATS sent:

?severity=low%2Clow&priority=UKADVXSDT%2CUKADVXSDT&threat_type=KSDLBKSRNSCAZ%2CKSDLBKSRNSCAZ

The server saw a single severity value of low,low, which is not in the enum, and answered:

{"error": "invalid_id", "error_description": "error in openapi3filter.RequestError: parameter \"severity\" in query has an error: Error at \"/0\": value is not one of the allowed values [\"unknown\",\"informational\",\"low\",\"medium\",\"high\",\"critical\"]"}

DELETE /threat_models/{id}/threats/bulk (HappyPath, test 97146) — same shape:

?threat_ids=2725d0d1-1e7d-460c-825d-84aff58ff8d6%2C2725d0d1-1e7d-460c-825d-84aff58ff8d6

{"error": "invalid_input", "error_description": "Invalid bulk delete request format"}

Note CATS does build the array correctly in its own JSON view of the request
("severity":["low","low"]) — it is only the wire serialization that collapses it. Per RFC 6570 /
OpenAPI style: form, explode: true, the correct encoding is severity=low&severity=low.

Impact

• 10 spurious true positives in run 20260731T200650Z, across 2 paths.
• Costs triage time disproportionately: a HappyPath 400 reads as a real regression until the raw
  URL is examined.
• Suppresses real coverage. Because every array-param request is malformed, no fuzzer ever
  exercises these endpoints' array filters with valid input, so genuine bugs behind severity,
  priority, threat_type and threat_ids handling would not be found. This is the same class of
  hidden coverage loss as chore(cats): anchor-path decoys erase ~97% of the anchor's own coverage (zero 2xx on PATCH/PUT for /threat_models/{id}) #651.

Affected findings

path	method	count
/threat_models/{threat_model_id}/threats	GET	7
/threat_models/{threat_model_id}/threats/bulk	DELETE	3

Options

1. Report upstream alongside Endava/cats#206, which
   noted this as possibly sharing a code path. Preferred — it is a clear spec-conformance bug.
2. Add a false-positive rule matching the comma-joined-array signature. Cheap, but it would also
   mask a genuine 400 on these endpoints, and it does nothing about the lost coverage.
3. Do nothing and re-triage the same 10 findings every campaign.

Recommend 1, with 2 only as a stopgap if the campaign noise becomes a problem before upstream moves.

Acceptance Criteria

• Confirm the behavior against the current CATS release (the run used the pinned plugin version)
• File upstream with the two reproductions above
• Decide whether to add an interim false-positive rule
• Once fixed, verify the array filters actually get exercised — the coverage was never there

References

• chore(cats): track upstream Endava/cats#206 — CATS validates 2xx responses against example, not schema #657 — the upstream example-vs-schema defect, where this was first noted
• chore(cats): anchor-path decoys erase ~97% of the anchor's own coverage (zero 2xx on PATCH/PUT for /threat_models/{id}) #651 — the other known cause of silently-erased coverage
• Run 20260731T200650Z, tests 95506 and 97146

[ericfitz]

Upstream report filed: Endava/cats#207

Reported against CATS 13.8.0 with the reproducer spec, the observed URLs, and both impacts (false
positives and the silent coverage loss). No pre-existing upstream issue covered it — Endava/cats#206
is ours and unrelated.

Correction: 3 of the 10 findings were a TMI bug, not a CATS bug

While writing the upstream report I checked explode on each parameter involved, and the split is
not what this issue originally claimed:

parameter	style / explode	correct wire form	CATS
severity, priority, threat_type, status	form / true	?severity=low&severity=high	wrong — comma-joins
threat_ids	form / false	?threat_ids=a,b	correct

ThreatIdsQueryParam declares explode: false, so the comma-joined value CATS sent to
DELETE /threat_models/{id}/threats/bulk was exactly right. The 400 came from us.

Root cause: BulkDeleteThreats read threat_ids from a JSON request body via
c.ShouldBindJSON, while the spec declares the operation with a required threat_ids query
parameter and no request body at all. The generated wrapper had already parsed and UUID-validated
the query parameter into BulkDeleteThreatModelThreatsParams.ThreatIds, and
api/server_threat.go was discarding it:

func (s *Server) BulkDeleteThreatModelThreats(c *gin.Context, threatModelId openapi_types.UUID, params BulkDeleteThreatModelThreatsParams) {
	s.threatHandler.BulkDeleteThreats(c)   // params dropped on the floor
}

So every spec-conforming bulk delete has been failing with 400 Invalid bulk delete request format — not just the fuzzer's. Any client generating from the spec (tmi-ux does) could never
have called this endpoint successfully.

Fixed: the handler now takes the parsed ThreatIdsQueryParam and no longer reads a body. While
there, the per-id delete failure was changed from ServerError (500) to
StoreErrorToRequestError (404 for an unknown id) — that path becomes reachable by fuzzers for the
first time now that requests get past validation, and 404 is already documented for the operation.

The HappyPath signature this issue warned about was therefore reading correctly in 3 of 10 cases.
The "do not re-triage these" note in the 2026-08-01 handoff was wrong for the threats/bulk half
and has been corrected.

What remains

The 7 GET /threat_models/{id}/threats findings are genuine CATS defects and stay suppressed
pending Endava/cats#207. The coverage point still stands for those four filters: severity,
priority, threat_type and status have never been fuzzed with valid input.