Summary Cross-site request forgery allows an unauthenticated attacker to hijack the authentication of a logged in user, and use the web API with the same permissions.

Details Security attributes like HttpOnly and SameSite are missing from the session cookie, allowing its use from XHR requests and form submissions. The CodeChecker API endpoints only require the session cookie, they do not require a CSRF token, and missing HTTP headers allow the form submission to succeed (but not XHR). This means that the attacker needs to know the ID of products to edit or delete them, but it does not need knowledge to create new products with the SQLite backend.

PoC With a superuser logged into CodeChecker.

html <html><body> <form action="https://codechecker.example.com/v6.58/Products" method="POST" enctype="text/plain"> <input type="text" name='[1,"getProducts",1,1,{}]' value=''> </form> <script>document.forms[0].submit()</script> </body></html> Or the same form attack on any of the applicable endpoints.

Impact The vulnerability allows an attacker to make requests to CodeChecker as the currently logged in user, including but not limited to adding, removing or editing products. The attacker needs to know the ID of the available products to modify or delete them. The attacker cannot directly exfiltrate data from CodeChecker, due to being limited to form-based CSRF.

CodeChecker is an analyzer tooling, defect database and viewer extension for the Clang Static Analyzer and Clang Tidy.

The CodeChecker web server contains an open redirect vulnerability due to missing protections against multiple slashes after the product name in the URL. This results in bypassing the protections against CVE-2021-28861, leading to the same open redirect pathway.

This issue affects CodeChecker: through 6.24.5.

CodeChecker's web server fails to fully invalidate a session token on logout when the server runs with more than one API worker process (the default). Each worker process maintains its own in-memory session cache; logout only clears the cache of the single worker that handles the request (plus the shared database record). Other workers continue to honor the destroyed token from their stale in-memory copies until the session's lifetime expires. An attacker who has captured a valid token can therefore keep impersonating the user after the user has logged out.

When an operator enables store.analysisstatisticsdir, a network client with PRODUCTSTORE permission for a product can call that product's storeAnalysisStatistics Thrift-over-HTTP method. CodeChecker 6.29.0 decodes the attacker-controlled Base64 string and passes the complete compressed input to one-shot zlib.decompress(). No maximum decompressed size is enforced.

This gives a correctly authorized, non-superuser store account a high-ratio memory and persistent-disk amplification primitive. The complete output is first materialized as a Python bytes object and is then written to the configured statistics directory. A sufficiently scaled payload can exhaust the API worker or host memory and impair CodeChecker availability.

The shipped value of store.analysisstatisticsdir is null, so the affected feature is disabled by default. The primary assessment does not rely on authentication being disabled. There is no authorization bypass and no path traversal in this report.

When an operator enables store.analysisstatisticsdir, a network client with PRODUCTSTORE permission for a product can call that product's storeAnalysisStatistics Thrift-over-HTTP method. CodeChecker 6.29.0 decodes the attacker-controlled Base64 string and passes the complete compressed input to one-shot zlib.decompress(). No maximum decompressed size is enforced.

This gives a correctly authorized, non-superuser store account a high-ratio memory and persistent-disk amplification primitive. The complete output is first materialized as a Python bytes object and is then written to the configured statistics directory. A sufficiently scaled payload can exhaust the API worker or host memory and impair CodeChecker availability.

The shipped value of store.analysisstatisticsdir is null, so the affected feature is disabled by default. The primary assessment does not rely on authentication being disabled. There is no authorization bypass and no path traversal in this report.

The HTML report that plist-to-html, CodeChecker parse --export html and CodeChecker cmd diff --output html generate puts the report message, the checker name and the source file path into a script block through json.dumps. json.dumps does not escape the less-than character, so a closing script tag in any of those three fields ends the script element and what follows is parsed as HTML.

The input author is whoever controls the analysed tree or a third-party result file that report-converter ingests, or who holds PRODUCTSTORE in the cmd diff flow. The viewer is somebody else: docs/jenkinsgerritintegration.md documents writing the report into Jenkins userContent and posting its URL into a Gerrit review. One caveat worth stating up front is that Jenkins serves userContent under a restrictive CSP that would block an inline handler, so that destination is probably safe as configured. The generated report sets no CSP of its own, so the impact lands wherever it is published without one.

The HTML report that plist-to-html, CodeChecker parse --export html and CodeChecker cmd diff --output html generate puts the report message, the checker name and the source file path into a script block through json.dumps. json.dumps does not escape the less-than character, so a closing script tag in any of those three fields ends the script element and what follows is parsed as HTML.

The input author is whoever controls the analysed tree or a third-party result file that report-converter ingests, or who holds PRODUCTSTORE in the cmd diff flow. The viewer is somebody else: docs/jenkinsgerritintegration.md documents writing the report into Jenkins userContent and posting its URL into a Gerrit review. One caveat worth stating up front is that Jenkins serves userContent under a restrictive CSP that would block an inline handler, so that destination is probably safe as configured. The generated report sets no CSP of its own, so the impact lands wherever it is published without one.