CVE-2026-126073: Action Pack: Possible cache poisoning in Action Pack content negotiation

Q: Which deployments are exposed to this issue?

Applications are affected when they render negotiated responses from actions marked public and place them behind a shared cache that honors Vary, such as Thruster or Rack::Cache. Applications without publicly cacheable negotiated responses do not meet the described affected conditions.

Q: What does an attacker need to do to trigger the cache mismatch?

The attacker needs to cause a shared cache to store a response whose representation was selected using headers that are not reflected in Vary. This can include requests without an Accept header, XHR requests, or responses where the application had already set a Vary header before rendering.

Q: What is the practical impact of a successful attack?

Later visitors may receive a cached representation intended for a different request, such as a page without its layout or HTML instead of JSON, until the cache entry expires. The attacker cannot choose the response content.

Q: How can teams identify potentially affected endpoints?

Review public actions that use content negotiation based on Accept, X-Requested-With, or Content-Type headers. Prioritize endpoints served through a shared Vary-aware cache, especially where responses may be cached publicly or where the application sets Vary before rendering.

Q: What can be changed if updating is not immediately possible?

Avoid publicly caching negotiated responses behind shared caches that honor Vary. This removes the combination of public negotiated responses and shared caching described as affected.

Published Nov 10, 2026

Updated

Impact Action Pack negotiates the format of a rendered response from the Accept, X-Requested-With and, for XHR requests without Accept, Content-Type request headers, but ActionController::Rendering#setvaryheader adds Vary: Accept only when the request carries a usable Accept header and the response has no Vary header yet. A response to a request without Accept, or to an XHR request, therefore omits the headers that selected its representation, and a response whose Vary the application set before rendering (for example Vary: Accept-Language) never gains Accept. A shared cache that honours Vary could store such a response and serve it to later clients that request a different representation, possibly leading to cache poisoning in which visitors receive, until the entry expires, a page without its layout or HTML in place of JSON. The attacker cannot choose the content of the response.

Applications that render negotiated responses from actions marked public (for example with expiresin ..., public: true) behind a shared cache that honours Vary, such as Thruster or Rack::Cache, are affected.

Details In the fixed releases, a rendered response whose format is not given by the URL lists Accept and X-Requested-With in Vary, and also Content-Type for an XHR request without Accept; when config.actiondispatch.ignoreacceptheader is enabled, it lists only X-Requested-With. These fields are appended to an existing Vary value rather than skipped, and Vary: is left unchanged. Shared caches can store more variants of such responses than before. See the Action Pack CHANGELOG for details.

Workarounds Set Vary: Accept, X-Requested-With on negotiated responses in the application, for example in an afteraction, or do not mark negotiated responses public.

Releases The fixed releases are available at the normal locations.

Patches for those who cannot upgrade at once: - 8.1: https://github.com/rails/rails/commit/7a955ca36779938267c93902c47d1f55bab99b4b.patch - 8.0: https://github.com/rails/rails/commit/b58c107abe9c1f10c1d6a4941402c60e4dc4742c.patch

Credit This issue was found by the Anthropic OSS Scanner (ANT-2026-7GHGLQGO, ANT-2026-5MT6C2R3).

Other sources

Action Pack is a framework for handling and responding to web requests. Prior to 8.1.4.1 and 8.0.5.2, Action Pack negotiates the format of a rendered response from the Accept, X-Requested-With and, for XHR requests without Accept, Content-Type request headers, but ActionController::Rendering#setvaryheader adds Vary: Accept only when the request carries a usable Accept header and the response has no Vary header yet. A response to a request without Accept, or to an XHR request, therefore omits the headers that selected its representation, and a response whose Vary the application set before rendering (for example Vary: Accept-Language) never gains Accept. A shared cache that honours Vary could store such a response and serve it to later clients that request a different representation, possibly leading to cache poisoning in which visitors receive, until the entry expires, a page without its layout or HTML in place of JSON. The attacker cannot choose the content of the response. Applications that render negotiated responses from actions marked public (for example with expiresin ..., public: true) behind a shared cache that honours Vary, such as Thruster or Rack::Cache, are affected. This issue is fixed in versions 8.1.4.1 and 8.0.5.2.

— MITRE

Affected Software

2 affected componentsFixes available

rubygems/actionpack<8.0.5.2

8.0.5.2

rubygems/actionpack>=8.1<8.1.4.1

8.1.4.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade rubygems/actionpack to a version that resolves this vulnerability.
Fixed in 8.0.5.2
Upgrade
Upgrade rubygems/actionpack to a version that resolves this vulnerability.
Fixed in 8.1.4.1
Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 8.1.4.1
Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 8.0.5.2
Configuration
Set Vary: Accept, X-Requested-With on negotiated responses, for example in an after_action.
Action Pack Vary = Accept, X-Requested-With

Event History

Nov 10, 2026

CVE Published

via MITRE·08:46 PM

Data Sourced

via MITRE·08:46 PM

DescriptionSeverityWeakness

Data Sourced

via NVD·09:19 PM

DescriptionSeverityWeakness

Advisory Published

via GitHub·09:26 PM

Data Sourced

via GitHub·09:26 PM

DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

Which deployments are exposed to this issue?

Applications are affected when they render negotiated responses from actions marked public and place them behind a shared cache that honors Vary, such as Thruster or Rack::Cache. Applications without publicly cacheable negotiated responses do not meet the described affected conditions.

What does an attacker need to do to trigger the cache mismatch?

The attacker needs to cause a shared cache to store a response whose representation was selected using headers that are not reflected in Vary. This can include requests without an Accept header, XHR requests, or responses where the application had already set a Vary header before rendering.

What is the practical impact of a successful attack?

Later visitors may receive a cached representation intended for a different request, such as a page without its layout or HTML instead of JSON, until the cache entry expires. The attacker cannot choose the response content.

How can teams identify potentially affected endpoints?

Review public actions that use content negotiation based on Accept, X-Requested-With, or Content-Type headers. Prioritize endpoints served through a shared Vary-aware cache, especially where responses may be cached publicly or where the application sets Vary before rendering.

What can be changed if updating is not immediately possible?

Avoid publicly caching negotiated responses behind shared caches that honor Vary. This removes the combination of public negotiated responses and shared caching described as affected.

CVE-2026-126073: Action Pack: Possible cache poisoning in Action Pack content negotiation

Other sources

Affected Software

Remediation

Event History

Frequently Asked Questions

Which deployments are exposed to this issue?

What does an attacker need to do to trigger the cache mismatch?

What is the practical impact of a successful attack?

How can teams identify potentially affected endpoints?

What can be changed if updating is not immediately possible?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed to this issue?

What does an attacker need to do to trigger the cache mismatch?

What is the practical impact of a successful attack?

How can teams identify potentially affected endpoints?

What can be changed if updating is not immediately possible?