I encountered a very similar issue and wanted to share what worked for me, as it might help in your case as well.
In my setup, I had previously pinned the pg-gvm container to version 22.6.10. This was originally done as a workaround when newer pg-gvm versions (22.6.11 and later) introduced PostgreSQL major version changes that required database migration.
I believe many users (including myself) applied this workaround at the time.
However, after recent updates (around April 8, 2026), I started experiencing a new issue:
The web interface loads normally
But when attempting to log in, the request fails
At the same time, the gsa container crashes
After investigation, I found that this was caused by a version mismatch between pg-gvm (pinned to 22.6.10) and the latest gsa:stable image, which had been updated recently.
Instead of using gsa:stable, I pinned the gsa container to a compatible version:
Hi, both issues are not related. If you get such errors during login, you should create a new topic here or report a bug at github. I am really sure your issue is fixed already with the latest images (please ensure you are also using the latest docker compose file).
I’m aware that the two issues are not identical. However, in both cases the underlying problem is related to the pg-gvm container, which is why I wanted to highlight two specific points that may help others troubleshoot similar situations.
There is a known compatibility issue between pg-gvm versions 22.6.11 and later and certain PostgreSQL major versions. This can be tested by temporarily pinning pg-gvm to 22.6.10.
At the same time, pg-gvm:22.6.10 may not be compatible with newer versions of other containers (especially when using stable for other containers). In my case, this led to gsa crashing during login.
I would also like to clarify that before pinning gsa, I did try:
switching pg-gvm back to stable
and running the latest images with the current docker compose file
Neither approach worked in my environment.
The only stable solution for me was to pin both pg-gvm and gsa to compatible versions. After doing so, the issue was resolved completely.
So while the symptoms may differ, there can still be a shared root cause in terms of version compatibility within the stack.
No component depends on a specific postgres version and that means you can still use an older pg-gvm container with current gvmd for example. gsad and gsa are completely independent of a database. gsa depends on gsad for the HTTP API only. gsad depends on gvmd for the GMP API. gvmd depends on a PostgreSQL database for storing all it’s data therefore it depends on the pg-gvm container. But gvmd does not depend on a specific version of the pg-gvm container.
The problem with the pg-gvm container was that the underlying Debian version did change, which introduced a new PostgreSQL version and a migration between major PostgreSQL versions was missing. This did broke existing installations and got fixed since a while already.
BUT I am currently working on refactoring of gsad parts and introduced some issues with the container. These could have caused your login problems and are already fixed in the latest release of the gsad container image.
I am aware that the two issues are different, and I did not intend to suggest they are identical.
However, I would like to point out the following:
If a user experiences such issues without making any changes on their side, I would reasonably suspect that the root cause is related to recent updates or version changes. In my case, I also encountered problems outside of my control, and after investigating, I identified that the issue was related to the pg-gvm component.
For this reason, I suggested the following approach as an initial troubleshooting step:
Pin pg-gvm to version 22.6.10
Then, to avoid follow-up compatibility issues, pin gsa to version 26.16.0 and test the setup
Unfortunately, as of yesterday, it was still possible to pull these versions from the registry, but today I observed that pg-gvm:22.6.10 is no longer available.
As a result, users encountering similar issues can no longer reliably test this known working combination, which makes troubleshooting significantly more difficult.
If you happen to have a local copy of the image, you are in a better position to test this scenario.