🇺🇸United States @greggles

Sounds good to me.

What do you think about changing the version string as affected from 7.x-1.0 to <= 7.x-1.6? That way the shipped versions from the 3rd party vendors can be seen as fixed.

The page: https://d7es.tag1.com/node/86

OK, thanks.

I found this page for tag1 which I can add as a related article at the time of publishing.

> (btw, we aligned on using the D7 version number style after this was submitted.)

I wondered about that. Thanks for pointing it out.

greggles → made their first commit to this issue’s fork.

Still working on this? We should either publish the details or somehow stop using this CVE (e.g. reject it)

These are now all posted. Any suggestions for improvements can be commented here or as a new issue in this queue.

All of this sounds great to me. Thanks!

There were some changes to the orgId in the json you provided that I didn't expect. So, I tried to manually make the changes you proposed rather than using the file as attached here.

I also used 1.0 and 1.2 for the 8.x version since I think that's how they are interpreted.

Now published and I'd appreciate your review, but consider this fixed.

OK, I published this one. Thanks for your help.

Thanks for the explanations in #4.

I made a few tweaks and published this.

* adjusting versions to 7.x style custom
* adding www on the package collection URL
* To be consistent with prior CVEs, the vendor should be "Drupal" not "Drupal community"
* Following previous examples - using the auto-generated description.

Those will be good things to double check for future CVEs.

I reserved CVE-2026-1556.

This generally LGTM. Thanks for the explanations.

greggles → credited greggles → .

Feedback welcome. I may post these tomorrow as we can always fix them if there is feedback in the future and I don't anticipate much feedback (though really, it's always welcome!).

This LGTM.

Hi aangel - As a project maintainer for this project I can add credit to people. Then you as the individual manage credit to volunteering or the right company for each issue. At least...I think that's how it works. If you can't figure it out I'm happy to keep digging and try to find where/ how that attribution is controlled.

Good call - I think it's fixed now (caching can vary depending on your source).

I notice this has some semver style versions in it that we'll need to fix. But that's not a big deal.

Adjusting status.

Assuming reviews go well the step is Jan 21 we should reserve a CVE for it.

I made those changes and published this as well. Thanks for the help, everyone.

I made those changes manually and published it. I think there's no need to submit a new json just for small things like this. Thanks for your help!

mcdruid → credited greggles → .

greggles → credited greggles → .

mcdruid → credited greggles → .

poker10 → credited greggles → .

poker10 → credited greggles → .

greggles → credited greggles → .

This has the same questions/issues with collection URL and version strings as the Flag CVE.

Do my proposed fixes on 📌 CVE Request for Flag Module Needs work make sense?

I just noticed some items and wanted to discuss before posting.

I think the package collection URL should be https://www.drupal.org/project/flag → which follows the pattern in other CVEs.
For the version of 7.0.0 as minimum, do you mean for that to be 7.x-3.0? I think we should call the version scheme "custom" and use 7.x-3.x as the version string.

I see that herodevs release is being called 7.3.10 and then the tag1 is called 7.x-3.10

And then for the <= version, I'm thinking it should be 7.x-3.9.

Forgot to mark needs work for publishing the page and updating the json to include the CVE id and the link.

OK, I reserved CVE-2026-0750 for this.

OK, I reserved CVE-2026-0749 for this.

OK, I reserved CVE-2026-0748 for this.

whoops, meant to set this in #17

On reconsidering this, I think my concern and proposed solution from #2 is not quite right. I'd been thinking of the script that generates the CVE json as the source of truth. However, the vulnrichment program makes its own adjustments so...the only source of truth is the MITRE CVE database.

I've now made the change proposed here - please double check if you can and let me know any oversights.

Great, thanks. I'll try to get to these this week.

Great, thanks. I'll try to get to these this week.

There appear to be 12 CVEs for December that need to be categorized with CWE and CAPEC.

Plan sounds good to me so far. Thanks for thinking this through and sharing your plans.

small adjustments to tone, some recommended by grammarly

Yeah, I was just thinking we could probably consider this properly fixed now.

Thanks to everyone for their work on this!

greggles → credited greggles → .

Thanks aangel.

I'll adjust the status since there is a file to review.

Yep, now reserved as CVE-2025-14557

Needs work for publishing an article and updating the json.

Needs work to publish your article and then update the json to cite it and then I can publish it.

Sure, it's been long enough for review.

I registered CVE-2025-14556 for this.

greggles → created an issue.

xjm → credited greggles → .

Thanks. Acknowledging I've seen this and adjusting status to needs review so others know its time for that.

greggles → created an issue.

xjm → credited greggles → .

xjm → credited greggles → .

xjm → credited greggles → .

xjm → credited greggles → .

xjm → credited greggles → .

xjm → credited greggles → .

xjm → credited greggles → .

xjm → credited greggles → .

I think this is still needs work for this part:

Currently we take the version info from the advisory and pass that along. If we need to add more versions to it then I guess we could add that info to the json and merge it on the end of the version we get from the advisory? I'm not sure I love that solution, but we should sort it out.

Here's what I think will work given the needs of the herodevs system:

* Propose CVE text in an issue
* Wait some time (a week?) for reviews, especially suggestions of URLs to reference
* I can reserve a CVE ID and post it here
* HeroDevs can post in the HeroDevs system and comment on the issue with updated json
* I will publish that CVE data

Thanks for sharing that URL. If there are multiple URLs the standard of CVEs that is consistent with a community project is we should cite all relevant URLs.

In general I don't think we should expect to have a reference URL on d.o about the D7ES issues (aside from coordination on CVEs).

@heddn please also see https://www.drupal.org/project/securitydrupalorg/issues/3559893 📌 CVE Request for Flag Module Needs work for a similar issue. You might want to subscribe to issues in this queue so you can help review CVE text.

Still relevant for 8.x-3.x.

Thanks for that explanation. I see why the CVE ID is useful now.

Let's wait for review on this then (especially given the holiday this week) and if there's no feedback in ~a week we can move forward with cve id reservation, herodevs publishes, update json to include that link and wait a shorter time for review of the json and then publishing the cve.

This could be needs review since there's json here or needs work to resolve the issue where we need a public URL. Marking needs work for the public URL, but I encourage interested folks to review the proposed json.

I think it's fine that the json posted here does not (yet) have a CVE-ID in it as that can be added last minute as it gets published, so I'll remove that from the issue summary.

Thanks for noticing and commenting here, damienmckenna. I'm not sure what went wrong, but I tried again and it seems to have gone through this time.

Thanks for filing this issue and posting the proposed json.

Could you share an "interdiff" from the original file compared to this one? I've found that formatting issues and the vulnrichment data can make it hard to compare the data.

Currently we take the version info from the advisory and pass that along. If we need to add more versions to it then I guess we could add that info to the json and merge it on the end of the version we get from the advisory? I'm not sure I love that solution, but we should sort it out.

I see this as similar to the risky content check (not sure if that feature is still present, but it was looking for stuff like iframes and script tags). On some sites that's totally normal and appropriate, so the module has a few ways to disable that check. But on other sites that represents an attack (or more likely an attempted attack).

Is there a concept of optional checks? This doesn't feel like a required security setting, but is optional, from my perspective.

It is valid to say that the .htaccess should not be writable by the webserver.

I updated https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... → the issue is still relevant.

I've asked others to review the other page.

I think yes, they can have their weights reset.

removing outdated parts so it doesn't need to be depreacted

mcdruid provided some advice on 008, so updating that and also gave credit in the new system.

I updated some old core values that were missing and have added the 2 contribs and 4 core.

Thanks!

Now that 📌 Refactor SA data so it's a single data file Active is done I think this issue can be closed since the same goal was achieved there. What do you think?

This looks good to me. I reviewed a few items in the transition and also the updated logic.

Thanks for your help to make this easier to maintain and more generally useful.

xjm → credited greggles → .

poker10 → credited greggles → .

greggles → credited greggles → .

greggles → created an issue.

Needs work - can you create this as a patch?

Great news, thanks @g-rath!

I registered CVE-2025-12848 for this and published what we had.

It would be ideal to add a "public at" and update the version range and the credit values, but those are all optional, so I'll mark this fixed.

If someone updates the json I'm happy to review/post again. Thanks!

greggles → credited greggles → .

greggles → credited greggles → .

poker10 → credited greggles → .

> Do we want to warn when this happens, or not allow this type of version constraint?

Agreed with #5 this could be a not allow situation. I guess if a > is present it has to be followed by =.

The CVE-2025-____.txt file is still valid and loads into vulnogram.

There was lots of good discussion here about process and we've done some outreach to try to follow that process.

There wasn't much discussion about the content of the proposed CVE. I've just read it and I think its fine.

At this point, especially since there was no disagreement with my comment in #14, I think we are within our responsibility to publish this.

Moving to RTBC to indicate what I believe to be the appropriate status. I can help move this forward next time I file CVEs.

If anyone feels we should not create this, please do comment.

These are now posted. I had to make the version a string to get vulnogram to parse it (that was a fun side quest to track down).

If any need adjustments, please open an issue and we can address them.

Adjusting title since I think the goal is to provide all advisories in OpenSSF Vulnerability format.

Here's where I think this stands:

There's growing agreement that we would like the Drupal Security Team to officially provide OSV files.

We hope this would be beneficial for the Drupal project to support OSV and to promote site owners using osv-scanner to scan their sites. osv-scanner will alert about vulnerabilities in all kinds of code, while most tools are either focused on one technology (e.g. composer's focus on PHP) or are paid (e.g. snyk) or are platform dependent (e.g. Github alerts).

Some key points about moving forward:

1. The code and the published osv files will be in a place managed by the Security Team with help from Gareth and Gold.
2. Gareth and Gold have built out the automation in Github. We will move the code and automation to a space managed by the Drupal Security Team before it is added to the OSV aggregator. I propose DrupalSecurityTeamOps as a spot for this that is segmented from our other uses of Github.
3. We can optimize the process and code in the future (e.g. moving to CVSS, having drupal.org generate the osv file directly and then the github repo would just pull that down, maybe moving some automation to Drupal.org owned Gitlab). But this is a good solution for now.
4. There is limited capacity among the Drupal Security Team to support this. Luckily, Gareth and Gold from Ackama are willing to help. Given that, we'll consider this a pilot for now, and we are interested in improving the sustainability of the effort by getting more support. Once it's set up, Gareth and Gold believe the ongoing effort will be limited.

greggles → credited greggles → .

+1 from me. There's some history of discussion along these lines in 📌 Deprecate in favor of drupalorg maintainer:release-notes Fixed .

(publishing this issue)

greggles → credited greggles → .

mcdruid → credited greggles → .

Ah, yeah! I think that image is helpful to explain the idea.

Given the details of #8, I think this should be won't fixed for now. We can revisit in the future if appropriate.

Looks like great progress to me. Thanks for the work. I think you could call this "fixed" but if you want to leave it open for any reason, feel free to. Thanks.