[GH-ISSUE #4423] "Cache Assets" option caches responses with cookies

kerem commented

2026-02-26 07:36:55 +03:00

Owner

Originally created by @ssddanbrown on GitHub (Mar 8, 2025).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/4423

Checklist

Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
- Yes
Are you sure you're not using someone else's docker image?
- Yes
Have you searched for similar issues (both open and closed)?
- Yes

Describe the bug

Hello,
I believe that the "Cache Assets" is currently caching responses which contain cookies, which isn't something I'd expect by default (at least without warning).
This can lead to responses with session cookies being cached and provided back to other users.
This is something I discovered when supporting a user of my software, who was using nginx-proxy-manager with this option enabled, who found that their login accounts would change somewhat randomly.

I believe this is down to the following proxy_ignore_headers line:

github.com/NginxProxyManager/nginx-proxy-manager@79d28f03d0/docker/rootfs/etc/nginx/conf.d/include/assets.conf (L9)

When reading initially, I thought that this line was specifically preventing responses with Set-Cookie headers from being cached, but this is not the case.
From what I understand, by default nginx won't cache proxy responses with the Set-Cookie field following the guidance here:

If the header includes the “Set-Cookie” field, such a response will not be cached.

The proxy_ignore_headers option then tells nginx to ignore certain headers for its own internal processing. It does not ignore responses that have these headers as I initially assumed when reading.
In this case, since Set-Cookie is used with this option, it's essentially telling nginx to ignore its default behaviour and allow Set-Cookie responses to be cached.

Testing/Replication

I tested this via a simple PHP script to set a cookie:

Script

<?php

$expires = time()+60*60*24*30;
$dateTime = str_replace(':', '-', date(DATE_ATOM));
$requestPath = $_SERVER["REQUEST_URI"];

setcookie("beans", $dateTime, $expires);

echo ("hello from {$requestPath}; Cookie value: {$dateTime}; Expires: " . $expires);

Then I ran that script with php -S 0.0.0.0:8000 server.php, then created a proxy server to that host, with the "Cache Assets" option enabled. A request to /cat.png would then become cached.

Then I removed Set-Cookie from line 9 of the /etc/nginx/conf.d/include/assets.conf, restarted the container, then tested again via a different endpoint (/dog.png) and observed that the response was no longer cached.

Nginx Proxy Manager Version
v2.12.3

Expected behavior

Responses with cookies applied should not be cached (by default).

Operating System
Fedora 41

Note: I did think about reporting this as a security issue, since it can interplay with user sessions via cookies, but I couldn't find any security reporting details or contact details, but instead found past similar requests for security contact details go unanswered. Should be a niche scenario anyway (instances with cache option active, where assets could be served with relevant cookies).

Originally created by @ssddanbrown on GitHub (Mar 8, 2025). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/4423 **Checklist** - Have you pulled and found the error with `jc21/nginx-proxy-manager:latest` docker image? - Yes - Are you sure you're not using someone else's docker image? - Yes - Have you searched for similar issues (both open and closed)? - Yes **Describe the bug** Hello, I believe that the "Cache Assets" is currently caching responses which contain cookies, which isn't something I'd expect by default (at least without warning). This can lead to responses with session cookies being cached and provided back to other users. This is something I discovered when supporting a user of my software, who was using nginx-proxy-manager with this option enabled, who found that their login accounts would change somewhat randomly. I believe this is down to the following `proxy_ignore_headers` line: https://github.com/NginxProxyManager/nginx-proxy-manager/blob/79d28f03d035114b80dcd04845306ecb98175074/docker/rootfs/etc/nginx/conf.d/include/assets.conf#L9 When reading initially, I thought that this line was specifically preventing responses with `Set-Cookie` headers from being cached, but this is not the case. From what I understand, by default nginx won't cache proxy responses with the `Set-Cookie` field following [the guidance here](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_valid): > If the header includes the “Set-Cookie” field, such a response will not be cached. The [`proxy_ignore_headers` option](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers) then tells nginx to ignore certain headers for its own internal processing. It does not ignore responses that have these headers as I initially assumed when reading. In this case, since `Set-Cookie` is used with this option, it's essentially telling nginx to ignore its default behaviour and allow `Set-Cookie` responses to be cached. ### Testing/Replication I tested this via a simple PHP script to set a cookie: <details> <summary>Script</summary> ```php <?php $expires = time()+60*60*24*30; $dateTime = str_replace(':', '-', date(DATE_ATOM)); $requestPath = $_SERVER["REQUEST_URI"]; setcookie("beans", $dateTime, $expires); echo ("hello from {$requestPath}; Cookie value: {$dateTime}; Expires: " . $expires); ``` </details> Then I ran that script with `php -S 0.0.0.0:8000 server.php`, then created a proxy server to that host, with the "Cache Assets" option enabled. A request to `/cat.png` would then become cached. Then I removed `Set-Cookie` from line 9 of the `/etc/nginx/conf.d/include/assets.conf`, restarted the container, then tested again via a different endpoint (`/dog.png`) and observed that the response was no longer cached. **Nginx Proxy Manager Version** v2.12.3 **Expected behavior** Responses with cookies applied should not be cached (by default). **Operating System** Fedora 41 --- Note: I did think about reporting this as a security issue, since it can interplay with user sessions via cookies, but I couldn't find any security reporting details or contact details, but instead found past similar requests for security contact details go unanswered. Should be a niche scenario anyway (instances with cache option active, where assets could be served with relevant cookies).

kerem added the

bug

label

2026-02-26 07:36:55 +03:00

kerem commented

2026-02-26 07:36:56 +03:00

Author

Owner

@Adiack06 commented on GitHub (Mar 21, 2025):

I have had the same issue while using book-stack (the software @ssddanbrown makes) with this nginx proxy setting enabled

@Adiack06 commented on GitHub (Mar 21, 2025): I have had the same issue while using book-stack (the software @ssddanbrown makes) with this nginx proxy setting enabled

kerem commented

2026-02-26 07:36:56 +03:00

Author

Owner

@faulpeltz commented on GitHub (Apr 3, 2025):

@ssddanbrown This causes problems with self-hosted GitLab instances as well, because some assets like user-profile images contain a cookie header (which they probably shouldn't), causing intermittent session takeover across accounts

I think NPM should, in a standard setting, never cache Set-Cookie headers or aggressively override caching based on file extension alone, instead I suggest maybe have a "standard" "force/aggressive" cache mode if you really need it?

@faulpeltz commented on GitHub (Apr 3, 2025): @ssddanbrown This causes problems with self-hosted GitLab instances as well, because some assets like user-profile images contain a cookie header (which they probably shouldn't), causing intermittent session takeover across accounts I think NPM should, in a standard setting, never cache Set-Cookie headers or aggressively override caching based on file extension alone, instead I suggest maybe have a "standard" "force/aggressive" cache mode if you really need it?

kerem commented

2026-02-26 07:36:56 +03:00

Author

Owner

@francescocaponio commented on GitHub (Apr 16, 2025):

As a reference, I'm attaching the link to gitlab's issue.

Please note that the issue happens even if the Cache Assets option is disabled from the UI.

@francescocaponio commented on GitHub (Apr 16, 2025): As a reference, I'm attaching the link to [gitlab's issue](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/34676). Please note that **the issue happens** even if the Cache Assets option is disabled from the UI.

kerem commented

2026-02-26 07:36:56 +03:00

Author

Owner

@ssddanbrown commented on GitHub (Apr 16, 2025):

Please note that the issue happens even if the Cache Assets option is disabled from the UI.

@francescocaponio Have you verified that from a (relatively) clean state? From when I opened this, it looks like the relevant nginx config was only at play with the setting enabled, so would be surprised unless there's some other level of caching config, or caching layer in play, or retained session after toggling the caching option.

@ssddanbrown commented on GitHub (Apr 16, 2025): > Please note that the issue happens even if the Cache Assets option is disabled from the UI. @francescocaponio Have you verified that from a (relatively) clean state? From when I opened this, it looks like the relevant nginx config was only at play with the setting enabled, so would be surprised unless there's some other level of caching config, or caching layer in play, or retained session after toggling the caching option.

kerem commented

2026-02-26 07:36:56 +03:00

Author

Owner

@francescocaponio commented on GitHub (Apr 16, 2025):

We noticed it on our instance, but also user alexhoisl on the gitlab issue tracker is experiencing the same problem with cache disabled.

@francescocaponio commented on GitHub (Apr 16, 2025): We noticed it on our instance, but also user [alexhoisl](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/34676#note_2431573233) on the gitlab issue tracker is experiencing the same problem with cache disabled.

kerem commented

2026-02-26 07:36:56 +03:00

Author

Owner

@ssddanbrown commented on GitHub (Apr 16, 2025):

@francescocaponio They confirm, in their next comment, that information was wrong and later confirm that they no longer have the issue with caching disabled. Since this applies to cookies those wrong cookies will remain in browsers for a while, so even after changing the setting existing sessions/cookies could need to expire or be deleted/invalidated otherwise wrong logins (or other problems caused by mixed cookies) may persist.

@ssddanbrown commented on GitHub (Apr 16, 2025): @francescocaponio They confirm, in their next comment, that information was wrong and later confirm that they no longer have the issue with caching disabled. Since this applies to cookies those wrong cookies will remain in browsers for a while, so even after changing the setting existing sessions/cookies could need to expire or be deleted/invalidated otherwise wrong logins (or other problems caused by mixed cookies) may persist.

kerem commented

2026-02-26 07:36:56 +03:00

Author

Owner

@francescocaponio commented on GitHub (Apr 16, 2025):

Now I see it, sorry, but I read it fast.

We should do a more consistent test here too. In our environment we have two instances of npm, one from external ips and one from internal ones. They were configured differently for the caching option. Let me check it better, but it's quite difficult to make it happen in a reliable way.

@francescocaponio commented on GitHub (Apr 16, 2025): Now I see it, sorry, but I read it fast. We should do a more consistent test here too. In our environment we have two instances of npm, one from external ips and one from internal ones. They were configured differently for the caching option. Let me check it better, but it's quite difficult to make it happen in a reliable way.

kerem commented

2026-02-26 07:36:56 +03:00

Author

Owner

@ahoisl commented on GitHub (Apr 16, 2025):

Sorry for the confusion!
Yes, after disabling "Cache Assets" the GitLab authentication problem was fixed.

@ahoisl commented on GitHub (Apr 16, 2025): Sorry for the confusion! Yes, after disabling "Cache Assets" the GitLab authentication problem was fixed.

kerem commented

2026-02-26 07:36:56 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Oct 19, 2025):

Issue is now considered stale. If you want to keep it open, please comment 👍

@github-actions[bot] commented on GitHub (Oct 19, 2025): Issue is now considered stale. If you want to keep it open, please comment :+1:

kerem commented

2026-02-26 07:36:56 +03:00

Author

Owner

@ssddanbrown commented on GitHub (Oct 19, 2025):

👍 I think it's worth keeping open @github-actions bot!

@ssddanbrown commented on GitHub (Oct 19, 2025): 👍 I think it's worth keeping open @github-actions bot!

Rows
Columns

[GH-ISSUE #4423] "Cache Assets" option caches responses with cookies #2832

Testing/Replication