CVE-2026-111922

Vikunja from 2.2.0 before 2.7.0 contains a permissive CORS configuration that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set. Attackers controlling a page on any localhost port can send a credentialed request to the token refresh endpoint and read the returned bearer JWT to take over the logged-in user's account.

Vikunja from 2.2.0 before 2.7.0 contains a permissive CORS configuration that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set. Attackers controlling a page on any localhost port can send a credentialed request to the token refresh endpoint and read the returned bearer JWT to take over the logged-in user's account.

Summary

Vikunja ships with cors.origins defaulting to http://127.0.0.1:* and http://localhost:*, and sends Access-Control-Allow-Credentials: true, so a page served from any port on the user's own machine may make credentialed cross-origin requests to the API and read the responses. The mandatory service.publicurl is appended to that default list rather than replacing it, so a fully configured production deployment still trusts every localhost origin. Combined with the token refresh endpoint, which authenticates with the vikunja_refresh_token cookie and returns a bearer JWT in the response body, one fetch() from such a page yields a working access token for whoever is logged in, and from there the whole account.

Vulnerability Details

cors.enable defaults to true and cors.origins defaults to the two localhost wildcards:

https://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/config/config.go#L495-L497

The middleware is registered with AllowCredentials: true and an UnsafeAllowOriginFunc that implements the port wildcard through matchCORSOrigin, since Echo v5 will not accept a wildcard port itself:

https://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/routes/routes.go#L263-L281

The detail that turns a development convenience into a production exposure is the last line of configuration handling. Enabling CORS without a public URL is a fatal error, so every deployment sets one, and that value is appended to the origin list rather than substituted for it:

https://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/config/config.go#L828-L830

An operator who configures nothing but their own hostname therefore ends up allowing three origins with credentials: their site, and any port on localhost and 127.0.0.1. There is no supported configuration in which the localhost entries are quietly dropped, and nothing in the logs distinguishes the intended origin from the inherited ones.

The escalation path is the refresh endpoint. It is deliberately unauthenticated because it authenticates with the refresh cookie instead of a bearer token, and it returns the new access token in the JSON body:

https://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/routes/api/v1/login.go#L129-L150

The cookie is HttpOnly, but that offers no protection here, because the attacking page never reads the cookie. It issues a credentialed request and the browser attaches the cookie itself. SetRefreshTokenCookie marks the cookie SameSite=None whenever the public URL is https, precisely so the cookie survives split-origin deployments, which is also what allows a cross-site send from a localhost page:

https://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/modules/auth/auth.go#L84-L104

So a single fetch('https://vikunja.example.com/api/v1/user/token/refresh', {method: 'POST', credentials: 'include'}) from any page on any localhost port returns a bearer token for the logged-in user, and the CORS response headers permit the page to read it. The token carries the user's full API authority.

Proof of Concept

Three files, built together in one directory and run with:

poc.zip

docker build -f Dockerfile -t poc . && docker run --rm poc

• Dockerfile builds Vikunja from commit a881ac39eecd07575a5aede8e74727c28d5fd578 and bakes the reproducer in.
• poc.sh is the entrypoint. It starts the application on sqlite with service.publicurl as the only setting configured, waits for the health check, and runs the exploit.
• exploit.py registers a user, logs them in, then acts as a page on http://localhost:31337: it reads the refresh cookie attributes, sends the CORS preflight, makes the credentialed refresh request, and asks the API who the returned token belongs to.

Nothing is stubbed and…

Vikunja from 2.2.0 before 2.7.0 contains a permissive CORS configuration that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set. Attackers controlling a page on any localhost port can send a credentialed request to the token refresh endpoint and read the returned bearer JWT to take over the logged-in user's account.

Vikunja from 2.2.0 before 2.7.0 contains a permissive CORS configuration that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set. Attackers controlling a page on any localhost port can send a credentialed request to the token refresh endpoint and read the returned bearer JWT to take over the logged-in user's account.

Vikunja from 2.2.0 before 2.7.0 contains a permissive CORS configuration that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set. Attackers controlling a page on any localhost port can send a credentialed request to the token refresh endpoint and read the returned bearer JWT to take over the logged-in user's account.

Summary

Vikunja ships with cors.origins defaulting to http://127.0.0.1:* and http://localhost:*, and sends Access-Control-Allow-Credentials: true, so a page served from any port on the user's own machine may make credentialed cross-origin requests to the API and read the responses. The mandatory service.publicurl is appended to that default list rather than replacing it, so a fully configured production deployment still trusts every localhost origin. Combined with the token refresh endpoint, which authenticates with the vikunja_refresh_token cookie and returns a bearer JWT in the response body, one fetch() from such a page yields a working access token for whoever is logged in, and from there the whole account.

Vulnerability Details

cors.enable defaults to true and cors.origins defaults to the two localhost wildcards:

https://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/config/config.go#L495-L497

The middleware is registered with AllowCredentials: true and an UnsafeAllowOriginFunc that implements the port wildcard through matchCORSOrigin, since Echo v5 will not accept a wildcard port itself:

https://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/routes/routes.go#L263-L281

The detail that turns a development convenience into a production exposure is the last line of configuration handling. Enabling CORS without a public URL is a fatal error, so every deployment sets one, and that value is appended to the origin list rather than substituted for it:

https://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/config/config.go#L828-L830

An operator who configures nothing but their own hostname therefore ends up allowing three origins with credentials: their site, and any port on localhost and 127.0.0.1. There is no supported configuration in which the localhost entries are quietly dropped, and nothing in the logs distinguishes the intended origin from the inherited ones.

The escalation path is the refresh endpoint. It is deliberately unauthenticated because it authenticates with the refresh cookie instead of a bearer token, and it returns the new access token in the JSON body:

https://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/routes/api/v1/login.go#L129-L150

The cookie is HttpOnly, but that offers no protection here, because the attacking page never reads the cookie. It issues a credentialed request and the browser attaches the cookie itself. SetRefreshTokenCookie marks the cookie SameSite=None whenever the public URL is https, precisely so the cookie survives split-origin deployments, which is also what allows a cross-site send from a localhost page:

https://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/modules/auth/auth.go#L84-L104

So a single fetch('https://vikunja.example.com/api/v1/user/token/refresh', {method: 'POST', credentials: 'include'}) from any page on any localhost port returns a bearer token for the logged-in user, and the CORS response headers permit the page to read it. The token carries the user's full API authority.

Proof of Concept

Three files, built together in one directory and run with:

poc.zip

docker build -f Dockerfile -t poc . && docker run --rm poc

• Dockerfile builds Vikunja from commit a881ac39eecd07575a5aede8e74727c28d5fd578 and bakes the reproducer in.
• poc.sh is the entrypoint. It starts the application on sqlite with service.publicurl as the only setting configured, waits for the health check, and runs the exploit.
• exploit.py registers a user, logs them in, then acts as a page on http://localhost:31337: it reads the refresh cookie attributes, sends the CORS preflight, makes the credentialed refresh request, and asks the API who the returned token belongs to.

Nothing is stubbed and…

Vikunja: Permissive Cross-domain Security Policy trusts every localhost origin which should not be trusted in code.vikunja.io/api.

NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.

(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)

The additional affected modules and versions are: .