[Bug] CSRF validation failure when trying to turn on maintenance mode after upgrade from 0.9.8 to 0.9.9.

[cklabautermann]

Hey there! 👋 Thanks for taking the time to report this bug — we appreciate it!

Please keep in mind: PegaProx is developed and maintained entirely by volunteers in our free time. We do our best, but we can't work magic 🪄 — please be patient, we'll get to your issue as soon as we can.

Want to help keep PegaProx alive?

• ⭐ Star the project — it's free and helps a lot!
• 💖 Become a Sponsor — helps us dedicate more time to development
• 🤝 Contributing code or docs is always welcome too!

---

Describe the bug

Since upgrading to 0.9.9 turning a PVE host into maintenance mode fails with a CSRF validation failure. This worked until 0.9.8.
Apache reverse proxy on same host fro

Steps to Reproduce

1. right click on PVE node
2. choose "Wartungsmodus aktivieren"
3. bottom right appears window saying "CSRF validation failed"
4. Host does not go into maintenance mode.

Expected behavior

the host should begin to evacuate vms and after that showing up as in maintenance mode

Environment

• PegaProx Version: 0.9.9
• Installation Method: deploy script
• OS: Ubuntu 24.04
• Browser: Edge 147.0.3912.98, Chrome 147.0.7727.138
• Behind Reverse Proxy? Yes, Apache2
• UI?

Logs

pegaprox_support_20260507_092615.zip

Screenshots

Checklist

• I have searched existing issues to make sure this is not a duplicate
• I am using the latest version of PegaProx

[cklabautermann]

OK, as only Pegaprox changed, I assumed the change there.
However I managed to fix this by changing some things in Apache2 vhost configuration.
Not sure what made the trick, but I added the following lines to it:

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-XSS-Protection "1; mode=block"
RequestHeader set X-Forwarded-Proto "https"

I will leave this open for review by the maintainers. Please close if you are satisfied with the solution.

And not to forget: Thanks for this great piece of software 💖

[mkellermann97]

@cklabautermann thanks for digging in and posting the workaround — it'll save the next person.

Quick post-mortem on which of those four lines actually moved the needle: the one that does it is RequestHeader set X-Forwarded-Proto "https". The other three (X-Content-Type-Options, X-Frame-Options, X-XSS-Protection) are defence-in-depth response headers that PegaProx already sets — duplicating them in Apache is harmless but doesn't change behaviour.

Underlying cause is on our side. v0.9.9 tightened the CSRF check from "JSON gets a free pass because of CORS preflight" (which was actually a wrong assumption — CORS doesn't help once the attacker already has a session cookie) to "every state-changing /api/ request must come with an Origin/Referer that matches the request host"*. Behind your Apache, the browser sends Origin: https://your.host, but Apache forwards as plain HTTP to PegaProx — without X-Forwarded-Proto: https, the server sees scheme=http and the strict origin comparison fails because https://… doesn't match http://….

Fix is in flight on our side: the matcher will go scheme-agnostic (host-only comparison, which is what RFC 6454 actually cares about for CSRF, and incidentally closes a separate suffix-confusion bug we found while in the area). That removes the need for the X-Forwarded-Proto workaround entirely. No date promises — project is volunteer-run and we don't ship on a calendar.

Leaving open until the fix lands, then I'll close this with a release reference.

If the project keeps things flowing for you, https://opencollective.com/pegaprox is where backers go.

— Marcus

[mkellermann97]

Fix shipped in v0.9.9.1, with a follow-up hotfix in v0.9.9.2 that's the actual one to grab (a separate OIDC re-auth regression got caught in 0.9.9.1 review and is fixed in 0.9.9.2).

Origin matcher is now host-only (RFC 6454-shaped), so the RequestHeader set X-Forwarded-Proto "https" line you added in your Apache vhost is no longer required for PegaProx to accept the request. Leaving it in place is harmless — and good practice for any reverse-proxy setup regardless — but the upgrade alone unblocks maintenance-mode.

Pentest follow-up while we were in the area also closed a separate suffix-confusion bug we found, plus tightened against urlparse normalising tabs in scheme, non-http(s) origins, userinfo confusion, and explicit port mismatches. So the matcher is overall stricter than 0.9.9 was, just no longer brittle on scheme.

Release notes: https://github.com/PegaProx/project-pegaprox/releases/tag/v0.9.9.2

Closing. Thanks again for the bug report — clear repro, supplied logs, posted the workaround for others. That's the kind of issue we wish all bugs landed as.

https://opencollective.com/pegaprox if the project keeps things flowing for you.

— Marcus