<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-06T13:11:06.599713+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-274129</id>
    <title>EUVD-2026-274129</title>
    <updated>2026-10-06T13:11:06.654933+00:00</updated>
    <content>EUVD-2026-274129</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-274129"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-28268</id>
    <title>fkie_cve-2026-28268</title>
    <updated>2026-10-06T13:11:06.654976+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Vikunja is an open-source self-hosted task management platform. Versions prior to 2.1.0 have a business logic vulnerability exists in the password reset mechanism of vikunja/api that allows password reset tokens to be reused indefinitely. Due to a failure to invalidate tokens upon use and a critical logic bug in the token cleanup cron job, reset tokens remain valid forever. This allows an attacker who intercepts a single reset token (via logs, browser history, or phishing) to perform a complete, persistent account takeover at any point in the future, bypassing standard authentication controls. Version 2.1.0 contains a patch for the issue.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-28268"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-rfjg-6m84-crj2</id>
    <title>GHSA-rfjg-6m84-crj2 — Vikunja Vulnerable to Account Takeover via Password Reset Token Reuse</title>
    <updated>2026-10-06T13:11:06.655029+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: code.vikunja.io/api</p>
<p>**Summary**
A critical business logic vulnerability exists in the password reset mechanism of vikunja/api that allows password reset tokens to be reused indefinitely. Due to a failure to invalidate tokens upon use and a critical logic bug in the token cleanup cron job, reset tokens remain valid forever.</p>
<p>This allows an attacker who intercepts a single reset token (via logs, browser history, or phishing) to perform a complete, persistent account takeover at any point in the future, bypassing standard authentication controls.</p>
<p>**Technical Analysis**
The vulnerability stems from two distinct logic errors in the pkg/user/ package that confirm the tokens are never removed.</p>
<p>1. Logic Error in Password Reset (No Invalidation)
In pkg/user/user_password_reset.go, the ResetPassword function successfully updates the user's password but fails to delete the reset token used to authorize the request. Instead, it attempts to delete a TokenEmailConfirm token, leaving the TokenPasswordReset active.</p>
<p>Vulnerable Code: pkg/user/user_password_reset.go (Lines 36-94)
```
func ResetPassword(s *xorm.Session, reset *PasswordReset) (userID int64, err error) {
    // ... [Validation and User Lookup] ...</p>
<p>// Hash the password
    user.Password, err = HashPassword(reset.NewPassword)
    if err != nil {
        return
    }</p>
<p>// FLAW: Deletes 'TokenEmailConfirm' instead of the current 'TokenPasswordReset'
    err = removeTokens(s, user, TokenEmailConfirm)
    if err != nil {
        return
    }…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-rfjg-6m84-crj2"/>
  </entry>
</feed>
