CVE CyberSecurity Database News

CVE-2025-26491 - Duplicate of CVE-2025-26494 – Understanding CVE Duplication in Cybersecurity Reporting

Poster -

---

If you’ve recently come across CVE-2025-26491, you might have wondered what’s going on. On searching through security feeds and vulnerability reports, you’ll find that this CVE ID has a special status: rejected as a duplicate. In this post, we’ll break down what that means, why CVE-2025-26491 is not a unique vulnerability, show what such cases typically look like, and clarify how you can find the real issue (CVE-2025-26494).

What is CVE-2025-26491?

CVE-2025-26491 was assigned in the Common Vulnerabilities and Exposures (CVE) list, but it was later rejected. The reason? The same issue had already been tracked and documented under a different CVE - specifically, CVE-2025-26494.

Here’s how the entry usually appears in the CVE system

 REJECT   
DO NOT USE THIS CANDIDATE NUMBER. Consult IDs: CVE-2025-26494. Reason: This candidate is a duplicate of CVE-2025-26494. Notes: All CVE users should reference CVE-2025-26494 instead of this candidate. All references and descriptions in this candidate have been withdrawn to avoid confusion.

You can verify this and see the official status on MITRE’s CVE site:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-26491

Why Do CVE IDs Get Rejected as Duplicates?

The process of assigning CVEs is very collaborative. Sometimes, multiple researchers might report the same underlying problem to different coordinators, or during the rush to disclose a security flaw, team members might request two different CVEs for the same bug.

A CVE Numbering Authority (CNA) assigns a CVE for tracking.

3. If review shows the bug already has a CVE, the new one is marked as a duplicate/rejected.

This preserves the integrity of vulnerability tracking and avoids confusion in patching and communication.

Let’s imagine a simple application with a vulnerable API endpoint

@app.route('/delete_user', methods=['POST'])
def delete_user():
    user_id = request.form['user_id']
    if not is_admin(request.user):
        return "Not authorized", 403
    # Vulnerable: No CSRF protection
    db.delete_user(user_id)
    return "Deleted"

Suppose two bug bounty hunters find this Cross-Site Request Forgery (CSRF) bug independently. Each one reports it, and in a rush, two different coordinators assign two different CVEs before realizing it’s the same bug. When the duplication is caught, one CVE is kept (becomes "living" for patches and references), the other is rejected as a duplicate (like CVE-2025-26491 in our case).

If you’re a user or IT administrator and come across a rejected CVE like CVE-2025-26491

- Ignore the duplicate. Use the recommended CVE (here, CVE-2025-26494) for patching, tracking, and assessing risk.
- Update your incident references: If you posted advisories or logs mentioning the duplicate, amend them to point to the real, active CVE.

Where to Find the Real Details

The reference for the actual security issue is:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-26494

This entry contains the technical details, affected software versions, patch information, and links to further exploits and advisories (if public).

Final Thoughts: What This Means for Security Teams

While duplicate CVEs might seem confusing, they’re a sign of a healthy, busy security community. The key is to always look for the official, active CVE reference.

Staying alert to rejected or merged CVEs ensures you protect the right assets without getting tripped up by paperwork. As always, cross-check all your patches and incident files to make sure you’re referencing the correct vulnerabilities.

References

- MITRE CVE List
- CVE-2025-26491 Listing (Rejected)
- CVE-2025-26494 Listing
- How Does the CVE Program Work?


Remember: If you see a CVE marked as "REJECT", always follow the trail to the referenced ID.

Timeline

Published on: 02/11/2025 11:15:17 UTC
Last modified on: 02/14/2025 20:15:37 UTC