CVE-2026-77360 in orpc
Summary
by MITRE • 09/16/2026
oRPC is an tool that helps build APIs that are end-to-end type-safe and adhere to OpenAPI standards. Prior to 1.14.8, the @orpc/server CORS plugin in packages/server/src/plugins/cors.ts copies a client's incoming Vary request header into the response instead of controlling Vary as a response-only header and using Origin for request-origin variation. In deployments behind a shared cache, CDN, or reverse proxy that keys responses using Vary, a client can inject arbitrary variation values, pollute cache keys, and cause inconsistent CORS enforcement for other clients. Default non-cached configurations have no established direct confidentiality, integrity, or availability impact. This issue is fixed in version 1.14.8.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the oRPC framework prior to version 1.14.8 stems from an improper handling of HTTP headers within its CORS plugin, specifically located in packages/server/src/plugins/cors.ts. The core technical flaw involves the server blindly copying the Vary request header received from a client directly into the response headers. In standard web architecture and security practices, the Vary header is intended to be a response-only directive that informs caches about which request headers were used to determine cacheability. By echoing back arbitrary values provided by the client in the Vary field, the application fails to enforce strict control over this critical caching mechanism, allowing external actors to manipulate how intermediate network devices interpret and store responses.
This architectural oversight creates significant risks primarily for deployments situated behind shared caches, Content Delivery Networks (CDNs), or reverse proxies that utilize the Vary header to key their cache entries. When a malicious client injects arbitrary variation values into the Vary request header, these injected values are propagated into the response and subsequently used by caching infrastructure to differentiate cached content. This behavior leads to cache key pollution, where distinct requests with different injected Vary headers result in separate cache entries for what should be identical or related resources. Such manipulation can cause inconsistent CORS enforcement across different clients because the cache may serve a response generated under one set of origin constraints to another client operating under different security policies, effectively bypassing intended access controls.
The operational impact of this vulnerability is heavily dependent on the deployment environment and caching configuration. In scenarios where shared caching infrastructure is employed, an attacker can exploit this flaw to perform cache poisoning attacks or cause denial-of-service conditions by flooding the cache with unique keys derived from injected Vary values. This not only degrades performance but also compromises the integrity of content delivery for other users who may receive responses intended for different origins due to the polluted cache state. However, in default configurations that do not utilize shared caching mechanisms such as CDNs or reverse proxies, the direct impact on confidentiality, integrity, and availability is negligible because there are no intermediate caches to be manipulated by the injected headers.
From a classification perspective, this vulnerability aligns with CWE-16 regarding Configuration Issues, specifically involving improper handling of HTTP headers for security purposes. It also relates to CWE-524 which covers the use of cacheable data in session management or access control decisions when such usage leads to inconsistent enforcement. In terms of adversary tactics, this flaw can be leveraged within the MITRE ATT&CK framework under techniques associated with Cache Poisoning and potentially as part of broader attacks aimed at bypassing security controls through header manipulation. The vulnerability highlights the importance of strictly validating and controlling response headers rather than passively echoing client input, especially for headers that influence caching behavior.
To mitigate this risk, organizations must upgrade to oRPC version 1.14.8 or later where the CORS plugin has been corrected to control the Vary header as a response-only directive. The fix ensures that only appropriate values are included in the Vary response header and utilizes Origin for request-origin variation rather than echoing arbitrary client input. For environments already running older versions, immediate patching is recommended if shared caching infrastructure is present. Additionally, developers should implement strict validation rules on all HTTP headers to prevent injection attacks and ensure that security-critical headers like Vary are generated based on server-side logic rather than external user input. Regular audits of CORS configurations in conjunction with CDN or proxy settings can further reduce the attack surface associated with header-based vulnerabilities.