GHSA-M687-P538-R5HP
Vulnerability from github – Published: 2026-10-09 20:57 – Updated: 2026-10-09 20:57Summary
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:
docker build -f Dockerfile -t poc . && docker run --rm poc
Dockerfilebuilds Vikunja from commita881ac39eecd07575a5aede8e74727c28d5fd578and bakes the reproducer in.poc.shis the entrypoint. It starts the application on sqlite withservice.publicurlas the only setting configured, waits for the health check, and runs the exploit.exploit.pyregisters a user, logs them in, then acts as a page onhttp://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 no internal function is called; everything after startup is ordinary HTTP against the running application. In the output [+] lines are measured checks and [*] lines are commentary, so only the checks and the final verdict are evidence.
A run against a881ac39eecd07575a5aede8e74727c28d5fd578 prints:
[*] Vikunja built from commit a881ac39ee, sqlite, service.publicurl=https://vikunja.example.com.
[*] service.publicurl is the only setting configured. cors.enable and cors.origins keep their defaults.
[+] The victim logs in and the refresh cookie is issued SameSite=None; Secure, so it is sent cross-site.
[+] A page on http://localhost:31337 is allowed to send credentials: Access-Control-Allow-Origin: http://localhost:31337, Access-Control-Allow-Credentials: true
[+] That page reads the response of a credentialed refresh, which carries a bearer token: eyJhbGciOiJIUzI1NiIsInR5cCI6...
[+] The token authenticates as: 'victim'
EXPLOIT SUCCESSFUL
Suggested Fix
The fix is for service.publicurl to replace the localhost defaults rather than extend them, so that configuring a deployment narrows the allowed origins instead of widening them. If the localhost entries are retained deliberately for desktop clients, they should not be combined with AllowCredentials: true, since it is the combination that allows a third-party origin to read authenticated responses.
Attribution
This vulnerability was found using Google's security automation tooling, abd triaged manually with manual report writing by Ada Logics. Please credit Google and Ada Logics in any advisories.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"last_affected": "2.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-942"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T20:57:50Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nVikunja 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\u0027s 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.\n\n## Vulnerability Details\n\n`cors.enable` defaults to true and `cors.origins` defaults to the two localhost wildcards:\n\nhttps://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/config/config.go#L495-L497\n\nThe 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:\n\nhttps://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/routes/routes.go#L263-L281\n\nThe 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:\n\nhttps://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/config/config.go#L828-L830\n\nAn 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.\n\nThe 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:\n\nhttps://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/routes/api/v1/login.go#L129-L150\n\nThe 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:\n\nhttps://github.com/go-vikunja/vikunja/blob/a881ac39eecd07575a5aede8e74727c28d5fd578/pkg/modules/auth/auth.go#L84-L104\n\nSo a single `fetch(\u0027https://vikunja.example.com/api/v1/user/token/refresh\u0027, {method: \u0027POST\u0027, credentials: \u0027include\u0027})` 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\u0027s full API authority.\n\n## Proof of Concept\n\nThree files, built together in one directory and run with:\n\n[poc.zip](https://github.com/user-attachments/files/31917334/poc.zip)\n\n```\ndocker build -f Dockerfile -t poc . \u0026\u0026 docker run --rm poc\n```\n\n- `Dockerfile` builds Vikunja from commit `a881ac39eecd07575a5aede8e74727c28d5fd578` and bakes the reproducer in.\n- `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.\n- `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.\n\nNothing is stubbed and no internal function is called; everything after startup is ordinary HTTP against the running application. In the output `[+]` lines are measured checks and `[*]` lines are commentary, so only the checks and the final verdict are evidence.\n\nA run against `a881ac39eecd07575a5aede8e74727c28d5fd578` prints:\n\n```\n[*] Vikunja built from commit a881ac39ee, sqlite, service.publicurl=https://vikunja.example.com.\n[*] service.publicurl is the only setting configured. cors.enable and cors.origins keep their defaults.\n\n[+] The victim logs in and the refresh cookie is issued SameSite=None; Secure, so it is sent cross-site.\n[+] A page on http://localhost:31337 is allowed to send credentials: Access-Control-Allow-Origin: http://localhost:31337, Access-Control-Allow-Credentials: true\n[+] That page reads the response of a credentialed refresh, which carries a bearer token: eyJhbGciOiJIUzI1NiIsInR5cCI6...\n[+] The token authenticates as: \u0027victim\u0027\n\nEXPLOIT SUCCESSFUL\n```\n\n## Suggested Fix\n\nThe fix is for `service.publicurl` to replace the localhost defaults rather than extend them, so that configuring a deployment narrows the allowed origins instead of widening them. If the localhost entries are retained deliberately for desktop clients, they should not be combined with `AllowCredentials: true`, since it is the combination that allows a third-party origin to read authenticated responses.\n\n## Attribution\n\nThis vulnerability was found using Google\u0027s security automation tooling, abd triaged manually with manual report writing by Ada Logics. Please credit Google and Ada Logics in any advisories.",
"id": "GHSA-m687-p538-r5hp",
"modified": "2026-10-09T20:57:50Z",
"published": "2026-10-09T20:57:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-m687-p538-r5hp"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Vikunja: Permissive Cross-domain Security Policy trusts every localhost origin which should not be trusted"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.