Microsoft Security Response Center (MSRC)

Gotchas & limits

• Despite the OData-shaped @odata.context envelope, most OData query syntax 500s on this API: confirmed live, /updates?$top=1 returns 500 An exception was thrown. and /updates?$filter=ID eq '2026-Jan' returns 500 {"message":"Internal server error"}. Only $filter on the two fields the project's own docs mention — InitialReleaseDate and CurrentReleaseDate — actually works, as in the worked example above.
• Both endpoints content-negotiate on Accept, but their defaults are OPPOSITE — this is the trap, not a missing format. All four cases probed live in this run on /cvrf/1999-Sep and /updates: /cvrf/{id} returns application/xml on a bare request (18,699 bytes) and application/json under Accept: application/json (12,940 bytes), while /updates returns application/json on a bare request (48,099 bytes) and application/xml under Accept: application/xml (66,040 bytes, an <ArrayOfUpdate> document). Accept: text/xml also works on /updates, returning text/xml with the same 66,040 bytes. Sending the Accept that matches an endpoint's own default is a no-op (probed both ways). So always set Accept explicitly rather than relying on a default that differs per endpoint.
• That JSON is CVRF serialised to JSON, NOT CSAF — don't wire a CSAF parser to it. Confirmed live on /cvrf/1999-Sep under Accept: application/json, the document has exactly 7 PascalCase CVRF top-level keys: DocumentTitle, DocumentType, DocumentPublisher, DocumentTracking, DocumentNotes, ProductTree, and Vulnerability. CSAF 2.0's required top-level keys (document, product_tree, vulnerabilities, snake_case) are all absent — checked explicitly, all three missing.
• An invalid document ID on /cvrf/{id} (confirmed live with /cvrf/not-a-real-id) returns a plain-text 404 body reading literally FileNotFound, not a JSON error object.
• A /csaf/{id} route IS documented — it is the first of the 14 paths in the live swagger at api.msrc.microsoft.com/cvrf/v3.0/swagger/v3/swagger.json, carrying its own Csaf tag — but every id format probed in this run returned 400 Invalid ID format. The spec declares the id as a bare type: string with no pattern, example, or description, and 17 candidate formats were tried: 2026-Jan, 2026-jan, 2026Jan, Jan-2026, 2026-01, 2026, 2026-Jan.json, 2026-Jan-csaf, cvrf-2026-Jan, CVE-2026-21441, CVE-2021-44228, 2026-21441, msrc_cvrf_2026-Jan, msrc_cve-2026-21441, msrc_cve-2026-21441.json, all, and latest. All 17 returned the same rejection, so the route is documented but was not usable from here — treat it as unusable unless you find a published id format, rather than assuming it is absent. The error body shape depends on the request: bare it is 400 text/plain with a 17-byte Invalid ID format, while under Accept: application/json it is the same message JSON-quoted (19 bytes).
• Note that the copy of swagger.json committed in the GitHub repo behind this entry's docsUrl is STALE relative to the live spec: it lists only 9 paths and no /csaf at all, while the live swagger served by the API host lists 14 including /csaf/{id}. Enumerate the live spec, not the repo copy. The repo's README doesn't mention CSAF anywhere either (0 hits for csaf, 2 for cvrf, confirmed live).
• There is no CVE-to-bulletin resolution endpoint. /cvrf/v3.0/cves/CVE-2021-44228 404s with an empty body (confirmed live), and no /cves path appears among the live swagger's 14 paths — which are /csaf/{id}, /cvrf/{id}, /cvrf({id}), /updates, /Updates, /Updates/$count, /updates({key}), /updates/{key}, /Updates({key}), /Updates/{key}, and the four metadata paths /, /., /$metadata, /./$metadata. Don't build around a CVE lookup that isn't there.
• No CORS support: confirmed live, /updates returns no access-control-allow-origin header at all, whether the request is bare or carries an Origin: https://example.com header — matches this entry's stored cors: no.