@jarrod.c Please provide a step by step "how to reproduce".

1. Install LimeSurvey
2. Attempt to access url/?.css or url/?.zip

Expected result: 404 or redirect to the root of the directory or redirect to index.php directly

Actual result: responds with 200 and blindly serves index.php

https://github.com/LimeSurvey/LimeSurvey/pull/4736

We are overriding a php ini setting.
If someone was already using a php.ini setting on this value, it could be an issue for them.

url/?.css or url/?.zip

? is the parameter separator in the URL. No reason to go to a 404. It must be a 200.

It's index.php?.css the must serves a 200 with index.php

It' not related to the issue reported !

@gabrieljenik : do you have a better link? System for testing?

The issue can be here: https://example.com/dashboard/view/test.css

but server configuration here for caching this URL. Not from LimeSurvey system!
LimeSurvey didn't set any cache for css/js file .
Server configuration issue in my opinion.

No issue on limequery https://shnoulle.limesurvey.net/themeOptions/index/check.css didn't enter in Server cache

Capture d’écran du 2026-03-03 15-27-39.png (50,165 bytes)   

Capture d’écran du 2026-03-03 15-27-39.png (50,165 bytes)   

Yes, it is probably a server configuration.

If LimeSurvey is deployed on a server where session.cache_limiter is set to "" (empty string), public, or private_no_expire, then:

• No Cache-Control headers would be sent on dynamic page responses.
• The Web Cache Deception attack would be fully exploitable if a caching layer is present.
  This is a realistic scenario — some frameworks and hosting setups override session.cache_limiter to manage caching themselves.

That is the issue reported.
Maybe (and I am realizing now), we can:

• Instead of setting up that ini setting
• Set an alert on the installation script if the ini setting is not "nocache"

What do you think?

I work with the original reporter.

Additional insight into our setup:

• We use the official php:8.5.2-apache container image
• We do not explicitly configure "session.cache_limiter"
• Akamai is our cache layer and we only configure it to respect cache-control headers
• We do not modify any cache-control headers at the apache level
• We do modify some headers at the apache level, listed below

  <IfModule mod_headers.c>
  Header always append X-Frame-Options SAMEORIGIN
  Header set X-XSS-Protection "1; mode=block"
  Header set X-Content-Type-Options nosniff
  Header set Referrer-Policy "no-referrer-when-downgrade"
  Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  </IfModule>

  Anything else we can share to help?

@thejoshhartmann Please look at the pull request. The edit is very simple.
Please, try it on a test installation of yours.

May be the issue is not much about the application but more about the server configuration in a mix in with the caching layer.
That's kind of the debate. Should the application do something in those cases?

We will apply the changes in the PR and test and get back with you.

The original issue is the way cache is managed: it must respect the header and not the name

shnoulle@isis-debian:~$ curl -Is https://shnoulle.limesurvey.net/themeOptions/index/check.css | grep content-type
content-type: text/html; charset=UTF-8
x-content-type-options: nosniff
shnoulle@isis-debian:~$ curl -Is https://shnoulle.limesurvey.net/tmp/assets/9ce1cae5/jquery-ui.min.css | grep content-type
content-type: text/css
x-content-type-options: nosniff

shnoulle@isis-debian:~$ curl -Is https://master.sondages.pro/admin/authentication/sa/login/check.css  | grep -i content-type
Content-Type: text/html; charset=UTF-8
shnoulle@isis-debian:~$ curl -Is https://master.sondages.pro/tmp/assets/ca67999b/jquery-ui.min.css  | grep -i content-type
Content-Type: text/css

You can set this setting in your config.php file

Some additional context:

Our vulnerability scanner is checking specifically for this vulnerability. Its doing this by checking responses to the following URLs. (I've used your domain as an example)

• https://shnoulle.limesurvey.net/?.css
• https://shnoulle.limesurvey.net/?.zip

If those requests return a 200, its going to flag it as vulnerable.

As an example, your domain is responding the same way and would be marked "vulnerable"

[root@localhost ~]$ curl -I https://shnoulle.limesurvey.net/?.css
HTTP/2 200 
server: nginx
date: Tue, 03 Mar 2026 16:09:25 GMT
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
set-cookie: PHPSESSID=3a2c9ba83b2d12d42b5909d1c99d364b; path=/; secure; HttpOnly
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
strict-transport-security: max-age=63072000; includeSubdomains;

If those requests return a 200, its going to flag it as vulnerable.

No ! no ! no !!!

It's an issue in your scanner: https://en.wikipedia.org/wiki/Query_string

Its not just my scanner... I just showed you that curl returns a 200 with those erroneous URLs on your own service... Even Chrome and Firefox will load your index.php and return a 200.

If the file doesn't exist, and the URL isn't a directory with an index.php, it should redirect instead of rewrite. This would solve the issue.

$ curl -I https://www.google.com/?.css
HTTP/2 200 
content-type: text/html; charset=ISO-8859-1

Any website must return a 200 with /?{anything} , it's not a security issue

If the file doesn't exist, and the URL isn't a directory with an index.php, it should redirect instead of rewrite. This would solve the issue.

You do not call ?.css file : you call the default index with parameters .css ! all characters after ? are parameters !
Please : read wikipedia !

@c_schmitz : my opinion here : No change required

You are correct. Anything after ? is being passed as a parameter.

For some reason, our scanner is hitting <url>/?.css to test this and not <url>/index.php/style.css like they explain in their vulnerability guide.

The biggest thing it wants is that cache-control headers get applied based on content-type and not file extension.

Thank you for your time and experience. I will reach out to our scanner vendor and ask why this is happening.

@thejoshhartmann No worries. Thanks for caring!
I am closing the issue for now.