Publish a new CVE for TFA Basic Plugins - CVE-2026-6816

That already has a CVE, though, so I think this should be a request to update the CVE to point to the herodevs and tag1 pages about it.

The CVE is CVE-2025-7030.

Short Version:
I would contend under CNA Operational Rules V4.1 section 4.2.13 that these are non-shared code and should receive different CVE ID's.

Based on statements given to maintainers on the TFA issue by the DST team this flaw in TFA Basic would likely not be eligible for an advisory. I would however encourage the DST team to accept section 4.1.1 (supplier determination) and override this decision.

No other review done on proposed changes to the existing CVE on the opinion that they should not share the same ID.

Background:
Parts of TFA 8.x (specifically some of the plugins and some internal logic) were sourced from the ga_login project that forked code from the TFA Basic project to create compatibility with the TFA 8.x branches. This is the share lineage between the two projects.

While the two projects share a lineage the code in TFA has become a derivative work, TFA Basic is/was not a regular upstream source. The two projects do not share a fully unified development team (though may have some developer team cross over). Large portions of the two projects (even when ignoring paths changes and whitespace changes) can not be directly patched onto each other.

CNA Operational Rules v4.1 section 4.2.13 should be evaluated
4.2.13 If multiple Products are affected by the same Independently Fixable Vulnerability, then the CNA:
Multiple products are involved. Independently fixable means a vulnerability that can be fixed without fixing a separate vulnerability. For TFA there was no other flaw that required to be fixed making it an independent vulnerability.

    MUST NOT assign more than one CVE ID if the Products are vulnerable because they share the vulnerable code. The assigned CVE ID will be shared by the vulnerable Products.
    SHOULD assign different CVE IDs if the Products do not share vulnerable code.
    SHOULD assign different CVE IDs if the CNA is uncertain whether the Products share vulnerable code.

The ga_login project significantly restructured the code however large portions were retained.
In this case patches between the two solutions are drastically different due to design changes in TFA between 7.x and 8.x. The concept is the same however the code between the two was not in shared portions of the code base. If the code was more similar I could see arguments for them possibly sharing a CVE ID, however the fork factor would still raise some questions. If there is uncertainty the preference is to assign different CVE ID's.

The Drupal Security Team deciding factor for approving CVE-2025-7030 was that the code had the following comment: // Only allow user setup access to the 'show codes' if user is self. otherwise they indicated this would have refused under the policy that any exploit requiring restrict access set to TRUE is not entitled to an advisory. This comment in code to my knowledge did not exist in TFA Basic 7.x branches. The DST would need to evaluate this policy in relation to this request and determine if they are changing their stance on supplier determination (section 4.1.1).

TFA Basic did come up during the evaluation of CVE-2025-7030 I did mention that perhaps https://www.drupal.org/project/tfa/issues/3075304 should have been raised as a security issue to TFA Basic at the time it was created. D.O. public disclosure policy certainly didn't help TFA basic to know they were at risk.

Ultimately I pushed for TFA Basic not to be considered at the time (under the DST Policy against unsupported versions) largely to avoid being bogged down in unrelated unmaintained code, the fact that its maintainer was/is a security team member, and (IIRC, however not explicitly stated in the issue itself) to avoid giving D7ES providers special treatment of disclosure of a vulnerability when no data sharing agreement with NDA's existed between them and the TFA project.

It seems like this is the right path to publish a new CVE. I'll leave this in this status for a minute in case any disagrees with the current title and then I'll reserve a CVE for this.

> So I'm happy to resubmit the json to be used for a unique CVE

Sounds great, please do go ahead with this.

Ah, right. Reserved CVE-2026-6816.

I looked at the file from #5 but I feel like it needs some significant changes before it can be posted so I held off on doing that myself.

@aangel hoping you can take care of that.

Thanks, aangel - now published.