https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 23:45:59 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-275046 EUVD-2026-275046 https://cve.radiocsirt.org/vuln/euvd-2026-275046 https://cve.radiocsirt.org/vuln/fkie_cve-2026-28787 <p>OneUptime is a solution for monitoring and managing online services. In version 10.0.11 and prior, the WebAuthn authentication implementation does not store the challenge on the server side. Instead, the challenge is returned to the client and accepted back from the client request body during verification. This violates the WebAuthn specification (W3C Web Authentication Level 2, §13.4.3) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication. No known patches are available.</p> <p>OneUptime is a solution for monitoring and managing online services. In version 10.0.11 and prior, the WebAuthn authentication implementation does not store the challenge on the server side. Instead, the challenge is returned to the client and accepted back from the client request body during verification. This violates the WebAuthn specification (W3C Web Authentication Level 2, §13.4.3) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication. No known patches are available.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-28787 https://cve.radiocsirt.org/vuln/ghsa-gjjc-pcwp-c74m <p><strong>Affected:</strong> npm: @oneuptime/common</p> <p>### Summary</p> <p>The WebAuthn authentication implementation does not store the challenge on the server side. Instead, the challenge is returned to the client and accepted back from the client request body during verification. This violates the WebAuthn specification ([W3C Web Authentication Level 2, §13.4.3](https://www.w3.org/TR/webauthn-2/#sctn-cryptographic-challenges)) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication.</p> <p>### Details</p> <p>During WebAuthn authentication, the server generates a random challenge via `generateAuthenticationOptions()` in `Common/Server/Services/UserWebAuthnService.ts` (line 164-221). However, the challenge is **only returned to the client** and **never stored in a session or database** on the server side.</p> <p>When the client submits the authentication response, the server reads the `expectedChallenge` directly from the untrusted request body (`Authentication.ts:1042`):</p> <p>```typescript // App/FeatureSet/Identity/API/Authentication.ts:1041-1049 } else if (verifyWebAuthn) { const expectedChallenge: string = data[&#34;challenge&#34;] as string; // ← client-controlled const credential: any = data[&#34;credential&#34;];</p> <p>await UserWebAuthnService.verifyAuthentication({ userId: alreadySavedUser.id!.toString(), challenge: expectedChallenge, // ← NOT a server-stored value credential: credential, }); } ```</p> <p>The `verifyAuthent…</p> <p><strong>Affected:</strong> npm: @oneuptime/common</p> <p>### Summary</p> <p>The WebAuthn authentication implementation does not store the challenge on the server side. Instead, the challenge is returned to the client and accepted back from the client request body during verification. This violates the WebAuthn specification ([W3C Web Authentication Level 2, §13.4.3](https://www.w3.org/TR/webauthn-2/#sctn-cryptographic-challenges)) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication.</p> <p>### Details</p> <p>During WebAuthn authentication, the server generates a random challenge via `generateAuthenticationOptions()` in `Common/Server/Services/UserWebAuthnService.ts` (line 164-221). However, the challenge is **only returned to the client** and **never stored in a session or database** on the server side.</p> <p>When the client submits the authentication response, the server reads the `expectedChallenge` directly from the untrusted request body (`Authentication.ts:1042`):</p> <p>```typescript // App/FeatureSet/Identity/API/Authentication.ts:1041-1049 } else if (verifyWebAuthn) { const expectedChallenge: string = data[&#34;challenge&#34;] as string; // ← client-controlled const credential: any = data[&#34;credential&#34;];</p> <p>await UserWebAuthnService.verifyAuthentication({ userId: alreadySavedUser.id!.toString(), challenge: expectedChallenge, // ← NOT a server-stored value credential: credential, }); } ```</p> <p>The `verifyAuthent…</p> https://cve.radiocsirt.org/vuln/ghsa-gjjc-pcwp-c74m