... and any other link to a checkin / commit returns the following:

i strongly suspect that you are a victim of over-aggressive browser caching (they are often overzealous about caching localhost pages, a problem i frequently run into). That message will only show up if certain URL parameters contain what appears to be SQL, and the URL you have shown us does not have any such parameters.

This did not happen with 2.22. What to do? Is this known?

My first suggestion is to enable your browser's dev tools (F12 on most browsers), switch to the Network tab, and click the "disable cache" checkbox. With the dev tools still open, visit that URL, and my suspicion is that the error will magically disappear.

Alternately, with the error page on the screen, tap Ctrl-Reload (or whatever button combination in your browser bypasses the cache) and see if it goes away. If it does not go away, please make a copy of the repository in question available to us for debugging, and with one or two of the URLs which are giving you problems (including any arguments you may be passing to them, as those are what will trigger the error you reported).

Found the culprit, not sure why fossil checks cookies (these are not relevant for SQLi):

possible hack attempt - 418 response on "optanonconsent" ... optanonconsent = isGpcEnabled=0&datestamp=Thu Aug 24 2023 09:16:08 GMT+0200 (Mitteleuropäische Sommerzeit)&version=2...

cookies ... are not relevant for SQLi

I beg to differ. You can have SQL injection on a cookie just as easily as you can on a query parameter.

I also see SQLi attempts on the "Referer" and the "User-Agent" strings in the HTTP header.

Referer and Useragent are used for that, because logging solutions log the content of these fields in most cases (think about page visitor statistics per browser and referer).

Still, cookies are normally not passed as input to SQL queries. I've never seen that in over 13 years of webdevelopment. Sure, it's userinput, but in this case, does fossil really store cookie values (they can be a maximum of 4093 bytes big) in the database or use them as input? If so, that should not be a risk when prepared statements are used.

Sure, it's userinput, but in this case, does fossil really store cookie values (they can be a maximum of 4093 bytes big) in the database or use them as input?

A malicious user could stuff data into their cookies in an attempt to get fossil to interpret that a GET/POST state for specific pages, and that would harmlessly work in many contexts, but...

If so, that should not be a risk when prepared statements are used.

Most definitely not. Raw user inputs are never used in SQL statements in fossil, with the exception of a couple of admin-only features such as ticket configuration. Any user-provided inputs for queries are of course handled as bound parameters, not SQL text.

Found the culprit

Aha, sneaky.

not sure why fossil checks cookies

Internally Fossil consolidates GET, POST, and cookie arguments and does not distinguish between them after their initial parsing.

Ah, good to know. I would have expect, that cookies are not handled like get and post requests (because for that cookies are not used, only for storing data or information states).