Actually the security scanner doesn’t recognize the actual version as the latest patch level.
Running Nextcloud 31.0.0.18
NOT on latest patch level
Major version still supported
Scanned at 2025-02-26 18:18:05 trigger re-scan
KR
Koenisch
Today I updated Nextcloud to 31.0.0. I dont have any errors in logs just affter scaning vulnerabilities on https://scan.nextcloud.com/ i found
Running Nextcloud 31.0.0.18 NOT on latest patch level & __Host-Prefix - The __Host prefix mitigates cookie injection vulnerabilities within potential third-party software sharing the same second level domain. It is an additional hardening on top of ‘normal’ same-site cookies.
is it some bug on scaner side ? on previous version Nextcloud 30.0.6.2 i had all correct with rating A+
This should be fixed by tomorrow, at least the part about not being on latest version. Sorry for the trouble.
This should be fixed by tomorrow. Sorry for the trouble.
Thank you for fast reply. No troubles 
I was just not sure affter update to Nextcloud 31.0.0 if became some problem on my side or on scaner. Still im not really sure on Host-prefix topic, on 30.0.6 and previous versions was working and after upgrade to latest 31.0.0 scaner says not. should i search for some solution or problem is on scaner side? Thank you
Thanks. The patch level bug is fixed.
I have the same behavior as Martin has. Before my rating was A+ and no Host_Prefix mismatch.
my 4 cockies:
oc_sessionPassphrase
session
Other
__Host-nc_sameSiteCookielax
1 year 1 month 4 days
Other
__Host-nc_sameSiteCookiestrict
1 year 1 month 4 days
Other
ocs21fn3ib37
session
Other
KR Koenisch
I just did the test before and I still get an A+. Baremetal installation, Apache, no reverse proxy.
I also did a little googling and asked a well-known LLM about this, and it says that a host_prefix mismatch typically refers to a situation where the host header or URL prefix of the incoming request does not match what the web application expects.
So what exactly causes this error in individual cases is hard to say without knowing exactly how the affected instances are configured, but I would probably start by checking the web server/reverse proxy configuration and the corresponding trusted_domains, trusted_proxies and overwrite parameters in the Nextcloud config.php: Reverse proxy — Nextcloud latest Administration Manual latest documentation
- setup details see PR testing see test result
- double checked config.php overwrites
- double checked trusted domains
- double checked reverse proxy settings
issue persists
Just to be clear, I’m not saying that it’s impossible for a bug in the security scanner to cause the host_prefix check to fail under certain circumstances, or that maybe something has changed in Nextcloud’s URL handling that the check is now misinterpreting as an error. My post was just meant to point people in the right direction
2 Likes
you point out correctly to web server/reverse proxy configuration and Nextcloud config.php , on new fresh intalations it need to be set up correctly, but in my case i hade all correct on previous versions including 30.0.6 on rating A+ with no issue with Host prefix, im not that skilled to say exactly where issue come from if is it on scaner side or something was changed in version 31.0.0 anyhowe im not alone with this issue and i have feeling it is not issue with reverse proxy or webserver because there was no any changes.
I fully agree with scubamuc and Martin.
As you see on my cockies. These are the “normal” cockies you should have. The URL in the cockies I haven’t shown here, but they match. I have checked all the hints without success. My nextcloud is running in a subdomain and in the prevoius versions I never had this issue. I have no reverse proxy.
KR
Koenisch
Same problem here but easy to fix.
tl:dr:
Edit your php.ini and add/set:
session.cookie_secure=1
Your may need to do a reload of your php-fpm process depending on your installation.
Explanation:
Since Nextcloud version 31 the missing __Host-prefix can be seen when requesting /status.php:
curl -I https:///status.php
[…]
set-cookie: nc_sameSiteCookielax=true; path=/; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: nc_sameSiteCookiestrict=true; path=/; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
[…]
The nextcloud security scanner requests this file and consequently gives the A rating.
On any other request the __Host-prefix was set correctly.
The reason can be found in lib/base.php, line 365:
// Do not initialize sessions for 'status.php' requests
// Monitoring endpoints can quickly flood session handlers
// and 'status.php' doesn't require sessions anyway
if (str_ends_with($request->getScriptName(), '/status.php')) {
return;
}
[...]
if ($request->getServerProtocol() === 'https') {
ini_set('session.cookie_secure', 'true');
}
So session.cookie_secure does not get set to true for status.php.
This was a change from Nextcloud 30 and 31.
I think this should be mentioned in the upgrade and or changelog documentation.
Users with A+ rating after upgrading to version 31 had this setting already in there php.ini.
1 Like
It looks like this PR was the cause: fix(status): Avoid session creation for status requests by solracsf · Pull Request #49406 · nextcloud/server · GitHub
1 Like
Yes, that’s the one.
session.cookie_secure=1 fix it thank you
1 Like
I created a pull request.
2 Likes
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.