Certainly could prove that it's not related to the input vars thing, then. Though the test isn't totally scientific. Some of the inputs might not be sent to the server, for example if they're disabled, and this won't account for that. Still, there's likely a huge difference there so seems unlikely after all.
I still think there's something server side blocking it. For reference, the security error generally means that the _xfToken value was either invalid, missing or it has expired. It could certainly be missing if something was stripping it out (such as when the input limit was reached).
There's similar variables that could impact it, depending on the web server. Nginx has client_max_size_body and LiteSpeed has a way to limit the request body, IIRC. If there are any options that can contain a lot of data, such as textarea elements (actually they won't be counted in the input check I mentioned earlier, though I guess you haven't got 150+ of them
) or similar then it's possible the total request size could be too high and it is therefore getting truncated (which would strip off the _xfToken value).
I am certainly intrigued. We really ought to see what the host says, I guess...
One thing that might shed some light though (and just discount it being some weird invalid value for some reason) is if you are happy editing a PHP file, you could edit library/XenForo/Controller.php and find:
PHP:
new XenForo_Phrase($isAjax ? 'security_error_occurred_ajax' : 'security_error_occurred')
And replace it with:
PHP:
new XenForo_Phrase($isAjax ? 'security_error_occurred_ajax' : 'security_error_occurred') . ' (' . $csrfAttempt . ')'
The $csrfAttempt variable here should have the actual reason we detected to fail the verification.
So the error you will receive when you try again is something like:
Code:
Error:
Security error occurred. Please press back, refresh the page, and try again. (missing)
