Executive brief
The oRPC CORS plugin incorrectly allowed client-supplied HTTP Vary headers to be reflected back in responses, a header that should be controlled only by the server. In deployments using shared caches or CDNs that key responses based on the Vary header, attackers could manipulate cache behavior and bypass CORS protections, potentially serving incorrect cached responses to other users. Default non-cached deployments are not affected.
Technical details
The vulnerability is an HTTP header injection (CWE-113) in the CORS plugin of oRPC versions ≤ 1.14.7. The plugin copied the incoming request's Vary header directly into the response instead of treating Vary as a response-only header controlled by the server. Because the Vary header instructs downstream caches and proxies how to key cached responses, a client could inject arbitrary values (e.g., "Accept-Encoding") into the response Vary header, distorting cache keys in shared caches or CDNs positioned in front of an oRPC server. This could lead to cache key pollution, inconsistent CORS policy enforcement across clients, and potentially serve responses cached for one origin to requests from different origins. Exploitation requires a shared cache/CDN layer configured to key on the Vary header; the vulnerability has no direct impact on confidentiality, integrity, or availability in default (non-cached) configurations. The fix, released in version 1.14.8, ensures the CORS plugin derives Vary exclusively from the response, appending Origin and preserving existing response-controlled values without reflecting request headers.
Affected products
- middleapi @orpc/server <= 1.14.7
Timeline
- 2026-07-12: disclosed: Issue reported and vulnerability disclosed
- 2026-07-12: patched: Fix merged and version 1.14.8 released
- 2026-09-16: advisory: Published to NVD
- 2026-09-17: advisory: Published to GitHub Advisory Database