https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 12 Oct 2026 08:44:29 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-91982 <p>Vikunja before 2.6.0 continues to expose the raw TOTP shared secret after enrollment through the GET /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode endpoints without re-authentication. Attackers with a valid access token can read the secret, import it into their own authenticator, and generate valid codes indefinitely to defeat the second factor and enable account takeover.</p> <p>Vikunja before 2.6.0 continues to expose the raw TOTP shared secret after enrollment through the GET /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode endpoints without re-authentication. Attackers with a valid access token can read the secret, import it into their own authenticator, and generate valid codes indefinitely to defeat the second factor and enable account takeover.</p> https://db.gcve.eu/vuln/fkie_cve-2026-91982 https://db.gcve.eu/vuln/ghsa-88f6-4rjv-x774 <p><strong>Affected:</strong> Go: code.vikunja.io/api</p> <p>### Summary Once a user has TOTP enabled, the API still hands back the raw shared secret to anyone holding that account&#39;s access token. Reading it doesn&#39;t ask for the password, even though disabling TOTP does. So a stolen token, an XSS, or a browser left open is enough to copy the second factor into your own authenticator and keep generating valid codes indefinitely.</p> <p>### Details `GET /api/v1/user/settings/totp` returns the full TOTP object, including the secret field and the otpauth:// provisioning URL. `GET /api/v1/user/settings/totp/qrcode` renders the same secret as a QR image. Neither requires re-authentication, the access token alone is enough.</p> <p>This is inconsistent with the rest of the flow: `POST /api/v1/user/settings/totp/disable` calls CheckUserPassword before it will turn TOTP off. So the destructive action is gated behind the password, but reading out the secret that backs the second factor isn&#39;t. There&#39;s also no reason for the secret to be readable at all once enrollment is finished, the client only needs it during setup.</p> <p>The fix is to stop returning secret/url/the QR code once enabled is true (only expose them during the enrollment window). Requiring the password on the read, like disable already does, would also be reasonable.</p> <p>### PoC The attacker needs the victim&#39;s access token, from an XSS, a leaked/stolen token, or an unlocked session. TOTP must already be enabled on the account.</p> <p>1. With the victim&#39;s bearer token, call: ``` GET /api/v1/user/settings/totp…</p> <p><strong>Affected:</strong> Go: code.vikunja.io/api</p> <p>### Summary Once a user has TOTP enabled, the API still hands back the raw shared secret to anyone holding that account&#39;s access token. Reading it doesn&#39;t ask for the password, even though disabling TOTP does. So a stolen token, an XSS, or a browser left open is enough to copy the second factor into your own authenticator and keep generating valid codes indefinitely.</p> <p>### Details `GET /api/v1/user/settings/totp` returns the full TOTP object, including the secret field and the otpauth:// provisioning URL. `GET /api/v1/user/settings/totp/qrcode` renders the same secret as a QR image. Neither requires re-authentication, the access token alone is enough.</p> <p>This is inconsistent with the rest of the flow: `POST /api/v1/user/settings/totp/disable` calls CheckUserPassword before it will turn TOTP off. So the destructive action is gated behind the password, but reading out the secret that backs the second factor isn&#39;t. There&#39;s also no reason for the secret to be readable at all once enrollment is finished, the client only needs it during setup.</p> <p>The fix is to stop returning secret/url/the QR code once enabled is true (only expose them during the enrollment window). Requiring the password on the read, like disable already does, would also be reasonable.</p> <p>### PoC The attacker needs the victim&#39;s access token, from an XSS, a leaked/stolen token, or an unlocked session. TOTP must already be enabled on the account.</p> <p>1. With the victim&#39;s bearer token, call: ``` GET /api/v1/user/settings/totp…</p> https://db.gcve.eu/vuln/ghsa-88f6-4rjv-x774