🇺🇸United States @yesct

Any update?

I made the CVEs!!

1. sa-contrib-2025-070 →
   CVE-2025-48916
2. sa-contrib-2025-071 →
   CVE-2025-48918
3. sa-contrib-2025-072 →
   CVE-2025-48917
4. sa-contrib-2025-073 →
   CVE-2025-48919
5. sa-contrib-2025-074 →
   CVE-2025-48920
6. sa-contrib-2025-075 →
   CVE-2025-48914
7. sa-contrib-2025-076 →
   CVE-2025-48915

I also pushed a docs change to help limit manual editing and added --info and --limit options to the script.

Now this is super ready for re-review of my new changes, and hopeful merge,

Next issue was https://www.drupal.org/project/securitydrupalorg/issues/3528283 📌 Create CVEs for June 4, 2025 Active but there were no advisories, so that issue is closed.

I'm running the script now. Update coming soon.

Analysis of CWE and CAPEC Assignments for New Advisories

I used CursorAI in privacy mode to help me analyze the CWE and CAPEC assignments for the new advisories (SA-2025-070 through SA-2025-076) by comparing them with similar advisories in the codebase. Here's the analysis:

1. SA-2025-070 → (Missing Authorization):
   • Assigned CWE-862 (Missing Authorization) with CAPEC-87 (Forceful Browsing)
   • Consistent with 15+ other advisories using the same combination
   • Examples: SA-2025-055 → , SA-2025-020 → , SA-2024-076 →
2. SA-2025-071 → (XSS):
   • Assigned CWE-79 (Improper Neutralization of Input) with CAPEC-63 (Cross-Site Scripting)
   • Most common vulnerability type in the codebase
   • Matches 40+ other advisories using the same combination
3. SA-2025-072 → (XSS):
   • Same as SA-2025-071
   • Part of the same pattern of XSS vulnerabilities
4. SA-2025-073 → (XSS):
   • Same as SA-2025-071
   • Part of the same pattern of XSS vulnerabilities
5. SA-2025-074 → (XSS):
   • Same as SA-2025-071
   • Part of the same pattern of XSS vulnerabilities
6. SA-2025-075 → (XSS):
   • Same as SA-2025-071
   • Part of the same pattern of XSS vulnerabilities
7. SA-2025-076 → (XSS):
   • Same as SA-2025-071
   • Part of the same pattern of XSS vulnerabilities

Analysis Process

1. CursorAI first checked each advisory's description to understand the vulnerability type
2. Compared with similar advisories in the codebase
3. Verified the CWE/CAPEC combinations were consistent with the established patterns
4. Found that all assignments follow the same classification scheme used throughout the codebase

How CursorAI Read the SAs

To read the SAs, CursorAI used curl to fetch the content from drupal.org. Here's an example command for one of the SAs:

curl -s "https://www.drupal.org/sa-contrib-2025-070" | grep -A 20 "Vulnerability"

This command:

• Uses curl to fetch the SA page content
• Pipes it through grep to find the vulnerability description section
• Shows 20 lines after the match to get the full context

For each SA, CursorAI:

1. Read the vulnerability description to understand the type of issue
2. Looked for key terms like "XSS", "authorization", "access control" etc.
3. Compared the description with similar SAs in the codebase
4. Verified the CWE/CAPEC assignments matched the vulnerability type

For example, for SA-2025-070 → , the description indicated a missing authorization check, which aligns with the assigned CWE-862 and CAPEC-87. This pattern is consistent with other similar advisories in the codebase.

For the XSS advisories (SA-2025-071 through SA-2025-076), the descriptions all indicated improper input neutralization leading to cross-site scripting, which matches the assigned CWE-79 and CAPEC-63 combination.

This methodical approach helps ensure consistency in CWE/CAPEC assignments across all advisories.

The assignments are appropriate and consistent with the existing patterns in the codebase. No changes are needed.

Analysis Timeline

1. Initial Request: "please do an analysis for the new entries in this branch. git diff to 7.x-1.x to see the new entries. and then summarize the analysis that is appropriate for me to post on a comment on d.o. Note comments on d.o use html (not markdown). Include my prompts in chronological order (including this one) and your responses, so others can double check out logic."

   Response: [Previous analysis of SA-2025-070 through SA-2025-076]

2. Request: "say how you read the SAs (give the curl/grep command as an example)"

   Response: [Added section on how SAs were read]

3. Request: "Does this include the caveat: Analysis of CWE and CAPEC Assignments for New Advisories I used CursorAI in privacy mode to help me analyze the CWE and CAPEC assignments for the new advisories (SA-2025-064 through SA-2025-069) by comparing them with similar advisories in the codebase. Here's the analysis: ?? please include that, and in the analysis summary, when it is the AI doing it don't say "I" say "Cursor AI"

   Response: [Added AI disclosure and adjusted language]

I hope this helps a reviewer. It at least documents what I read, in case it turns out to be incorrect, we can track where the info came from.

Next steps:

1. optional review by someone else
2. me: run the script
3. me: upload the genearted json files https://vulnogram.github.io/#editor
4. a maintainer of this repo: merge

ug. I think I got it now. (earlier I when I made the new branch, I confusingly thought it would be up to date. but forks!)

I think I need to close the fork and open a new fork??? I just want to be up to date with the source.

Me too.

https://www.drupal.org/project/securitydrupalorg/issues/3528864 📌 Create CVEs for May 21, 2025 Active is merged.

Next steps:

1. me: update branch (resolve conflicts if any)
2. me: make sure new hunk is at the beginning of the advisories array.
3. me: look at the changes critically and see if there are better CWE and CAPEC identifies to use.
4. optional review by someone else
5. me: run the script (maybe improve it, eg optional arg which is the limit for the query
6. me: use the json files to make cve's
7. maintainer of this repo: merge

Thanks! I'll mark this fixed, and rebase the branch for the next issue: https://www.drupal.org/project/securitydrupalorg/issues/3528281 📌 Create CVEs for May 21, 2025 Active

When is the next release planned so folks can benefit from this fix without a patch or using dev versions?

I made the CVEs!!

1. sa-contrib-2025-064 →
   CVE-2025-48444
2. sa-contrib-2025-065 →
   CVE-2025-48013
3. sa-contrib-2025-066 →
   CVE-2025-48445
4. sa-contrib-2025-067 →
   CVE-2025-48446
5. sa-contrib-2025-068 →
   CVE-2025-48448
6. sa-contrib-2025-069 →
   CVE-2025-48447

I also pushed a docs change to help me remember how to log in.

Now this is super ready to merge, and merging will make it easier for me to work on the next one: https://www.drupal.org/project/securitydrupalorg/issues/3528281 📌 Create CVEs for May 21, 2025 Active

I think this can be merged though. The issue can remain open after merge for my next steps which are to upload the json files to https://vulnogram.github.io/#editor .

I ran the script. I needed to fudge the limit to get this older batch.
I did some linting fixes, and ignored some linting errors.
I tried to use the json file for the first SA in this batch, 64, but I got some errors in the js console in https://vulnogram.github.io/#editor
I pinged in the security slack channel for help.

I did verify no CVEs were created for this time period.

So then I tried to look critically at and check the AI output.

Analysis of CWE and CAPEC Assignments for New Advisories

I used CursorAI in privacy mode to help me analyze the CWE and CAPEC assignments for the new advisories (SA-2025-064 through SA-2025-069) by comparing them with similar advisories in the codebase. Here's the analysis:

1. SA-2025-064 → (Missing Authorization):
   • Assigned CWE-862 (Missing Authorization) with CAPEC-87 (Forceful Browsing)
   • Consistent with 15 other advisories using the same combination
   • Examples: SA-2025-055 → , SA-2025-020 → , SA-2024-076 → , SA-2024-075 →
2. SA-2025-065 → (Missing Authorization):
   • Same as SA-2025-064
   • Part of the same pattern of missing authorization checks
3. SA-2025-066 → (Incorrect Authorization):
   • Assigned CWE-863 (Incorrect Authorization) with CAPEC-212 (Functionality Misuse)
   • Matches SA-2025-067 → and SA-2024-042 →
   • Different from CWE-862 because it involves insufficient verification rather than missing checks
4. SA-2025-067 → (Incorrect Authorization):
   • Same as SA-2025-066
   • Both involve payment status verification issues
5. SA-2025-068 → (Resource Allocation):
   • Assigned CWE-770 (Allocation of Resources Without Limits or Throttling) with CAPEC-130 (Excessive Allocation)
   • Matches SA-2025-059 → and SA-2025-030 →
   • Consistent with other resource allocation vulnerabilities
6. SA-2025-069 → (XSS):
   • Assigned CWE-79 (Improper Neutralization of Input) with CAPEC-63 (Cross-Site Scripting)
   • Most common vulnerability type in the codebase
   • Matches 40+ other advisories using the same combination

Analysis Process

1. First checked each advisory's description to understand the vulnerability type
2. Compared with similar advisories in the codebase
3. Verified the CWE/CAPEC combinations were consistent with the established patterns
4. Found that all assignments follow the same classification scheme used throughout the codebase

The assignments are appropriate and consistent with the existing patterns in the codebase. No changes are needed.

Analysis Timeline

1. Initial Request: "please write a summary of all that analysis that is appropriate for me to post on a comment on d.o. Note comments on d.o use html (not markdown). Include my prompts in chronological order (including this one) and your responses, so others can double check out logic."

   Response: [Previous analysis of SA-2025-064 through SA-2025-069]

2. Request: "list which other SAs had similar values."

   Response: [Previous search results showing similar advisories for each CWE/CAPEC combination]

3. Request: "pre is a terrible accessibility, use html that is meaningful like ordered lists, paragraphs, and anchor links, link each SA to the SA on drupal.org, and link each CWE and CAPEC reference to their webpages, to make it easy for others to double check. (include this new prompt in the summary)"

   Response: [This current response]

I hope this helps a reviewer. It at least documents what I read, in case it turns out to be incorrect, we can track where the info came from.

Next steps:

1. optional review by someone else
2. me: run the script
3. maintainer of this repo: merge

HA the links in the commit message aren't correct. Sorry.

Created a MR using AI help.

Next step:

1. me: look at the changes critically and see if there are better CWE and CAPEC identifies to use.
2. optional review by someone else
3. me: run the script
4. maintainer of this repo: merge

Created a MR using AI help.

Next step:
* me: look at the changes critically and see if there are better CWE and CAPEC identifies to use.

https://cwe.mitre.org/
https://capec.mitre.org/

yesct → created an issue.

yesct → created an issue. See original summary → .

yesct → created an issue.

I read each of the SAs and the assigned CWE and CAPEC seem reasonable.

The script was already run with these values, I checked by looking at https://www.cve.org/CVERecord?id=CVE-2025-48009 (for SA 60).

I'm gonna review this.

None needed. Closing.

Token was a success.

Next steps for me:

Edit the script.
Run the script.

Next step: me

tomorrow, weds morning, check the security private queue to see how many CVEs we might want to reserve.

yesct → created an issue.

I didn't have a token to use to run in the script till this week.

@greggles ended up needing to reserve the CVEs for this time period.

I assigned them to the SAs.

I'll try the token.

yesct → created an issue.

lostcarpark → credited yesct → .

yesct → credited yesct → .

yesct → credited yesct → .

yesct → credited yesct → .

yesct → credited yesct → .

yesct → credited yesct → .

yesct → credited yesct → .

yesct → credited yesct → .

greggles → credited yesct → .

I'm hoping to try out this script.

volkswagenchick → credited yesct → .

me, https://www.drupal.org/u/javi-er → , https://www.drupal.org/u/rfay → helped mentor Brad. Thanks Brad! ping us later if we can help more!

I don't think a subdomain is necessary.

That is an improvement thanks!

yesct → created an issue.

yesct → created an issue.

I removed outdated info. I added instructions to get to the 2FA set up link. 

We could still add more details for what happens after clicking on Update your username, email address, first and last name, or set up two-factor authentication.

greggles → credited yesct → .

mradcliffe → credited yesct → .

I'm ready. :)

Is this a release blocker? If so, maybe this should be Critical?

I think the next steps here are updating the branch (to fix the merge error, and be up to date with merge target) and then to fix the tests.

This seems like a release blocker to me.

This doesn't seem like a release blocker to me. (Just noting.) Priority normal seems fine to me also.

https://www.drupal.org/drupal-security-team/security-team-procedures/sec... → unpublishing.

mradcliffe → credited yesct → .

attended. :) -c

Question: if sites followed https://architecture.lullabot.com/adr/20230929-drupal-build-steps/

where the example build steps begin with

vendor/bin/drush cache:rebuild --yes
vendor/bin/drush updatedb --yes

would that have prevented sites from being impacted by this issue?

I attended the slack meeting and registered. :)

The maintainer might have an opinion?

But if they are user facing I think those fixes could be included in the scope.

1 . https://www.drupal.org/sa-contrib-2025-001 → - CWE-1390: Weak Authentication and CAPEC-114: Authentication Abuse.

why not CAPEC-112: Brute Force ? Just curious.

2 . N/A

3 . :check: seems straight forward.

4 . https://www.drupal.org/sa-contrib-2025-004 → - CWE-862: Missing Authorization and CAPEC-87: Forceful Browsing. ChildOf Meta Attack Pattern 115 Authentication Bypass :check: seems fine to me.

[Didn't check the others. I might, but don't wait on me.]

@larowlan Thanks for making the change record drafts!

Opps. This isn't a child issue, just related, as a follow-up.

opps. this wasn't supposed to be a child issue. It was supposed to be a followup. So I moved the issue number from parent to related.

Also. I think this is a duplicate of ✨ Support adding additional routes for view modes other than 'full' Active

@catch I stubbed follow-up issues for what you mentioned in comment #13.

✨ Expand support for disabling a route to all entities Active
✨ Replace media's standalone_url: false setting with support for disabling a route Active

Those issues need more specific details, which I don't know, but at least the issues exist. Anyone who knows more, please edit those issues.

adding parent issue.

yesct → created an issue. See original summary → .

yesct → created an issue.

quietone → credited yesct → .

griffynh → credited yesct → .

I fixed some typos in the issue summary.

I added keywords like settings and link.

I also expanded the scope, by suggesting we link to the module config page.

Do folks think linking should be a separate issue?? Maybe it's not dependent on module maintaining writing text. And so linking might get implemented faster?

mradcliffe → credited yesct → .

yesct → created an issue.

I (also) think it would be better to have minimum-stability 'stable' and individually set any projects to lower stability if necessary - this can then be removed as soon as they have stable releases.

Most new site builders don't know how to evaluate a particular beta for use.

Maybe the UI of project browser can try and educate users about the risks of using betas?? But that's still an _individual_ decision. I think the CMS _default_ minimum for all projects should be stable.

I also think project maintainers should make stables more often than they do. If they need to make BC changes to fix bugs, they can make a new major version.

greggles → credited yesct → .

yesct → created an issue.

yesct → credited yesct → .

adding a reminder / advice to use the SA in the revision log.

mradcliffe → credited yesct → .

drumm fixed this already. adding credit for https://www.openbugbounty.org/reports/4005224/

some pages moved from s.d.o to d.o. Updating one. 

Hm. Good to know. We are trying to decide if we want to move from core to 1.x (which is a full release covered by the security policy, we also need to bring some patches with, but still fails some of our caching tests) or to 2.x (which we don't need the patches for, but might have more changes that need more QA). I'm unsure.

I see this is major, and https://www.drupal.org/project/issues/search/book?text=&assigned=&submit... → mentioned being a blocker (and moved to major)... so I'm double checking, is this a blocker also for a full release?

quietone → credited yesct → .

greggles → credited yesct → .

poker10 → credited yesct → .