Denver, Colorado, USA
Account created on 21 October 2005, over 19 years ago
#

Merge Requests

Recent comments

🇺🇸United States greggles Denver, Colorado, USA

It took me a second to understand the idea, but I think this will be a good improvement. Thanks for your effort on it.

🇺🇸United States greggles Denver, Colorado, USA
🇺🇸United States greggles Denver, Colorado, USA
🇺🇸United States greggles Denver, Colorado, USA

Ping me if you need access to this.

🇺🇸United States greggles Denver, Colorado, USA

The title is SSRF (server side request forgery) which I understand to mean a request from the server to other machines on the server's network as described in portswigger and owasp.

The description includes:

The vulnerability allows one Drupal user with administrative permissions to create a page which can force another Drupal user to make a call to a server under the control of an attacker.

and

The browser will make a call to the malicious server

That is not a server-side request.

I can see how this would let an admin gain data about the site visitors, which is not ideal, but on most sites an admin who can enter translations can probably already make other changes to a site that would also gain information about a visitor.

I'm surprised if this is the only place where a user with only the ability to translate could insert an image. I think other strings are similarly not filtered.

🇺🇸United States greggles Denver, Colorado, USA

I'm not sure if project maintainers can do that, but I've now done it.

Thanks to you both for the collaboration and coordination on ensuring active and accurate maintainers.

🇺🇸United States greggles Denver, Colorado, USA

Adding what I believe is the audit ignore syntax to the issue summary to help folks as a workaround until this gets packaged.

🇺🇸United States greggles Denver, Colorado, USA
🇺🇸United States greggles Denver, Colorado, USA
🇺🇸United States greggles Denver, Colorado, USA
🇺🇸United States greggles Denver, Colorado, USA

I noticed there's a lot of "warning" text near the top of project page that could probably be swapped for more inviting formatting. The webform page has a few examples that seem to leverage d.o styles in different ways without being as offputting/warning.

🇺🇸United States greggles Denver, Colorado, USA

I found this issue while looking for a duplicate before creating one.

I agree with the issue summary.

Yes, I would say it's important for there to be a way for a site developer, with access to settings.php, to disable the ability to update modules or install new modules from remote locations. It's either very similar to allow_authorize_operations and should be documented/placed in a similar location, or should rely on allow_authorize_operations directly.

Updating the IS to remove some ambiguity about whether this is a good idea.

🇺🇸United States greggles Denver, Colorado, USA

removing duplicate Gerhard

🇺🇸United States greggles Denver, Colorado, USA

@klemendev can you review those as well and add your comments on them if they seem RTBC to you?

🇺🇸United States greggles Denver, Colorado, USA
🇺🇸United States greggles Denver, Colorado, USA

Explain a bit more about what CVEs are and how to help write them.

🇺🇸United States greggles Denver, Colorado, USA

explaining to use a predefined risk score

🇺🇸United States greggles Denver, Colorado, USA
🇺🇸United States greggles Denver, Colorado, USA
🇺🇸United States greggles Denver, Colorado, USA

Thanks, everyone. This is now done.

🇺🇸United States greggles Denver, Colorado, USA

Can you update the IS with the permissions for the user that makes this a bug? And maybe what happens if that user goes to user/1

It seems like an uncommon configuration to be able to set privileged fields like author of a node and not see usernames, but the behavior should be consistent if that configuration does happen.

🇺🇸United States greggles Denver, Colorado, USA

Ah, that makes sense. +1 to that as a base level.

Personally I've generally asked applicants to go through the queue and post patches to the things they are likely to fix first, to provide feedback on proposed feature issues of whether an idea fits with the philosophy of the module or not, to do reviews of patches other people have provided, to create a "next release" plan issue and highlight what they would commit in that next release. Those create more material for the current maintainer to at least skim over before granting access. They would also get the person past being "new" without using that specifically as the barrier.

🇺🇸United States greggles Denver, Colorado, USA

There are docs pages already, we could definitely add some suggested items to the template. I'd be more +1 to the idea of using "git verified" as a hurdle if that process were more efficient and transparent to end users (e.g. a quiz, being able to apply with significant MRs to core/contrib).

🇺🇸United States greggles Denver, Colorado, USA

Re-titling. It seems important to focus on the goal (safer additions) than a potential solution (harder additions). It's possible a solution will be that it is somewhat harder to be added as co-maintainer, but just making it harder alone doesn't make it safer.

🇺🇸United States greggles Denver, Colorado, USA

OK. Thanks for that update. I'll close this, then.

🇺🇸United States greggles Denver, Colorado, USA

We now have a field for composer version strings. These are not always completed, but maybe they are good enough?

The script in 📌 Create CVEs for contributed projects in 2024 Active uses that field to populate the version string on CVEs so I think this could now be closed as fixed.

I recognize "things are changing" with the Gitlab migration so we might need to revisit this in the future.

🇺🇸United States greggles Denver, Colorado, USA
🇺🇸United States greggles Denver, Colorado, USA

Analysis to date in the private issue is that this cannot be exploited, but we should ensure this code is resilient and won't be weakened in the future.

🇺🇸United States greggles Denver, Colorado, USA

Maybe this should be won't fix after Tour is deprecated? https://www.drupal.org/node/3421972

🇺🇸United States greggles Denver, Colorado, USA

@emjayess that error message comes from core's system.install.

Here's an issue that I think is relevant to your goal of making it more appropriate for nginx users 🐛 Remove error “Public files directory Not fully protected” in non apache servers Needs review

🇺🇸United States greggles Denver, Colorado, USA

I discarded the email already in mailman moderation queue, but if/when it crops up again I will preserve the full email so we can do more investigation.

🇺🇸United States greggles Denver, Colorado, USA

@emjayess thanks for the followup. Can you post a screenshot of the message in the status report?

🇺🇸United States greggles Denver, Colorado, USA
🇺🇸United States greggles Denver, Colorado, USA

greggles created an issue.

🇺🇸United States greggles Denver, Colorado, USA

I think this should be "postponed" until after 🌱 Drop support of 8.x-1.x version Active is completed and after a fair number of folks are on 2.1.0. I won't flip the status myself in case there's another way to run it that seems good to you.

🇺🇸United States greggles Denver, Colorado, USA

This seems like a very thorough plan.

There are no bugs reported against the 2.0.x branch, so that's a good sign.

Currently, the usage of the module is:

Week	7.x-1.x	8.x-1.x	2.0.x	Total
December 28, 2024	362	673	789	1,824

As long as the upgrade path works well I think this is a great idea.

🇺🇸United States greggles Denver, Colorado, USA

adding bramdriesen

🇺🇸United States greggles Denver, Colorado, USA

I updated the advisory for 2025-005 to point to that CVE.

2024-001 is CVE-2024-11941 and now points to it.

@cmlara are you willing to research the CWE and CAPEC for these?

🇺🇸United States greggles Denver, Colorado, USA

Don't think I'll need this for a bit. Might reopen it if I do. Thanks.

🇺🇸United States greggles Denver, Colorado, USA

Oh, and here are the links:

https://www.cve.org/CVERecord?id=CVE-2024-13312
https://www.cve.org/CVERecord?id=CVE-2024-13311
https://www.cve.org/CVERecord?id=CVE-2024-13310
https://www.cve.org/CVERecord?id=CVE-2024-13309
https://www.cve.org/CVERecord?id=CVE-2024-13308
https://www.cve.org/CVERecord?id=CVE-2024-13305
https://www.cve.org/CVERecord?id=CVE-2024-13304
https://www.cve.org/CVERecord?id=CVE-2024-13303
https://www.cve.org/CVERecord?id=CVE-2024-13302
https://www.cve.org/CVERecord?id=CVE-2024-13301
https://www.cve.org/CVERecord?id=CVE-2024-13300
https://www.cve.org/CVERecord?id=CVE-2024-13299
https://www.cve.org/CVERecord?id=CVE-2024-13298
https://www.cve.org/CVERecord?id=CVE-2024-13297
https://www.cve.org/CVERecord?id=CVE-2024-13296
https://www.cve.org/CVERecord?id=CVE-2024-13295
https://www.cve.org/CVERecord?id=CVE-2024-13294
https://www.cve.org/CVERecord?id=CVE-2024-13293
https://www.cve.org/CVERecord?id=CVE-2024-13292
https://www.cve.org/CVERecord?id=CVE-2024-13291
https://www.cve.org/CVERecord?id=CVE-2024-13290
https://www.cve.org/CVERecord?id=CVE-2024-13289
https://www.cve.org/CVERecord?id=CVE-2024-13288
https://www.cve.org/CVERecord?id=CVE-2024-13287
https://www.cve.org/CVERecord?id=CVE-2024-13286
https://www.cve.org/CVERecord?id=CVE-2024-13285
https://www.cve.org/CVERecord?id=CVE-2024-13284
https://www.cve.org/CVERecord?id=CVE-2024-13283
https://www.cve.org/CVERecord?id=CVE-2024-13282
https://www.cve.org/CVERecord?id=CVE-2024-13281
https://www.cve.org/CVERecord?id=CVE-2024-13280
https://www.cve.org/CVERecord?id=CVE-2024-13279
https://www.cve.org/CVERecord?id=CVE-2024-13278
https://www.cve.org/CVERecord?id=CVE-2024-13277
https://www.cve.org/CVERecord?id=CVE-2024-13276
https://www.cve.org/CVERecord?id=CVE-2024-13275
https://www.cve.org/CVERecord?id=CVE-2024-13274
https://www.cve.org/CVERecord?id=CVE-2024-13273
https://www.cve.org/CVERecord?id=CVE-2024-13272
https://www.cve.org/CVERecord?id=CVE-2024-13271
https://www.cve.org/CVERecord?id=CVE-2024-13270
https://www.cve.org/CVERecord?id=CVE-2024-13269
https://www.cve.org/CVERecord?id=CVE-2024-13268
https://www.cve.org/CVERecord?id=CVE-2024-13267
https://www.cve.org/CVERecord?id=CVE-2024-13266
https://www.cve.org/CVERecord?id=CVE-2024-13265
https://www.cve.org/CVERecord?id=CVE-2024-13264
https://www.cve.org/CVERecord?id=CVE-2024-13263
https://www.cve.org/CVERecord?id=CVE-2024-13262
https://www.cve.org/CVERecord?id=CVE-2024-13261
https://www.cve.org/CVERecord?id=CVE-2024-13260
https://www.cve.org/CVERecord?id=CVE-2024-13259
https://www.cve.org/CVERecord?id=CVE-2024-13258
https://www.cve.org/CVERecord?id=CVE-2024-13257
https://www.cve.org/CVERecord?id=CVE-2024-13256
https://www.cve.org/CVERecord?id=CVE-2024-13255
https://www.cve.org/CVERecord?id=CVE-2024-13254
https://www.cve.org/CVERecord?id=CVE-2024-13253
https://www.cve.org/CVERecord?id=CVE-2024-13252
https://www.cve.org/CVERecord?id=CVE-2024-13251
https://www.cve.org/CVERecord?id=CVE-2024-13250
https://www.cve.org/CVERecord?id=CVE-2024-13249
https://www.cve.org/CVERecord?id=CVE-2024-13248
https://www.cve.org/CVERecord?id=CVE-2024-13247
https://www.cve.org/CVERecord?id=CVE-2024-13246
https://www.cve.org/CVERecord?id=CVE-2024-13245
https://www.cve.org/CVERecord?id=CVE-2024-13244
https://www.cve.org/CVERecord?id=CVE-2024-13243
https://www.cve.org/CVERecord?id=CVE-2024-13242
https://www.cve.org/CVERecord?id=CVE-2024-13241
https://www.cve.org/CVERecord?id=CVE-2024-13240
https://www.cve.org/CVERecord?id=CVE-2024-13239
https://www.cve.org/CVERecord?id=CVE-2024-13238
https://www.cve.org/CVERecord?id=CVE-2024-13237

🇺🇸United States greggles Denver, Colorado, USA

OK. Done! Thanks to everyone for providing your analysis and feedback.

Some deficiencies I noticed in the json generated by this script that may not be worth fixing:
Something is corrupted in special characters like á from https://www.drupal.org/sa-contrib-2024-020
The 7.x versions should be described as "custom" instead of "semver"

I realized I could create the unsupported advisories without CWE and CAPEC by removing those fields from vulnogram (I had read they were optional earlier, but thought maybe vulnogram was going to require it). So I did that.

There are no doubt a small number of instances of inaccurate data in these CVEs compared to their advisories, especially as it relates to version strings and 7.x values. There may also be more appropriate or additional CWE and CAPEC values that we should add.

I'm going to mark this issue as fixed since the initial effort is done.

If anyone notices any inaccurate data in these please open new issues in this queue and I should be able to address them quickly.

🇺🇸United States greggles Denver, Colorado, USA

Adding my +1 to the perspective in #26.

Given that Drupal CMS smooths over a lot of details from site builders it seems important to make reasonable decisions for them that match their preferences/risk profile.

🇺🇸United States greggles Denver, Colorado, USA

@kentr I think some bulk updates are coming to address some issue metadata, but agreed this issue should stay focused on getting the MR into D11 and not worry about D7. Removing the "Needs backport to D7" issue tag.

🇺🇸United States greggles Denver, Colorado, USA

No advisory is needed from Drupal as we're not the vendor. There are tons of 3rd party software that get integrated with Drupal and have vulnerabilities regularly that we don't issue advisories for. Some past advisories reinforcing this practice are https://www.drupal.org/psa-2024-06-26

🇺🇸United States greggles Denver, Colorado, USA

I don't think there is a way to mark older releases as unsupported. Branches can be marked as unsupported, but not releases.

🇺🇸United States greggles Denver, Colorado, USA
🇺🇸United States greggles Denver, Colorado, USA

adding explanation for handling an advisory being published after the fix is already public

🇺🇸United States greggles Denver, Colorado, USA

TIL - thanks @solideogloria! It would be ideal to know the number of Drupal sites among those, but I recognize that may not be possible.

🇺🇸United States greggles Denver, Colorado, USA

Updating title to clarify this affects drupal.org and not the Drupal software more generally.

🇺🇸United States greggles Denver, Colorado, USA

Maybe the best short-term answer here is not to show anything.

In the long run it seems great if we could do the recursive calculating you mention, catch, and then have icons/text to explain "all modules are covered with stable releases" or "It's a mix of statuses and stable releases, get details."

🇺🇸United States greggles Denver, Colorado, USA

It seems important to show the coverage before the modules are installed on a site. The status is pretty prominent on the project page to help people make informed choices.

🇺🇸United States greggles Denver, Colorado, USA

Thanks for the thoughts in #10.

I'm inclined to take small steps here and see how the process of updating it this time goes before we make a big change to the scope. Most of the other organization scopes I reviewed have rather brief and broad scope statements, so I'm hesitant to enshrine too much of the project's practices into the scope.

I guess a good system would be to revisit this periodically (every year or so?) to ensure it matches the current practices.

🇺🇸United States greggles Denver, Colorado, USA

The issue summary says:

Nginx is one of the most popular web servers on which Drupal is run.

Does anyone have data about the level of popularity?

🇺🇸United States greggles Denver, Colorado, USA

I think comment #10 got flagged by the d.o auto moderation system. I've published it and confirmed nitinpatil's account so that won't happen again. Welcome nitinpatil and thanks for your comment on this issue!

🇺🇸United States greggles Denver, Colorado, USA

The concept of the check for CSP header on the status page feels a like a pretty big additional functionality for core. It seems like something security_review could handle, so I filed Check for CSP on private and public SVG files Active to track it there.

🇺🇸United States greggles Denver, Colorado, USA

Some other questions to consider - I've added numbers to them to facilitate discussion.

1 Could the .htaccess change interfere with the use of typical
theme-provided SVGs?

Great question. I don't think it's very common for svgs to use these features (I've only seen it once on a non-Drupal mapping site) but it made me realize the change could be inside of the htaccess for the files directory and therefore only apply to a subset of files. That feels like it reduces the risk this change will negatively impact while still retaining most of the value in protecting sites from malicious files. I asked mr.baileys and he agreed on that idea, but we could certainly discuss it more.

2 Do SVGs pose risks for users outside of an http request, eg when downloading them and viewing them? This risk of course exists with other file types, but less so for jpg/png images.

I think they do pose a risk, but solving it feels like a separate problem to me. I filed Filter SVGs before uploading by default Postponed and linked it to this as related for followup that could address this risk. The situation today is that site admins are enabling SVG uploads on their site often and there is no protection for a variety of risks that creates. This issue attempts to solve one of the risks (XSS), but is not a complete protection against all risks.

3 Are typical XML-issues such as XXE, XSLT a possible issue, if so, in what contexts?

As far as I understand those risks they are not relevant on a typical Drupal site and would only be relevant on sites that parse the XML of the SVG file. These changes don't affect that for better/worse.

* Are we sure all possible threats from SVGs in img/object/background contexts are tackled? Which specs apply?

I'm not sure this mitigates all possible threats (several additional threats are mentioned in this issue already). I'm sure the change in this issue is progress in securing sites against cross site scripting, but not a solution to all risks of SVG files.

🇺🇸United States greggles Denver, Colorado, USA

It...appears I failed to include the link to the gist in comment #18.

Here is the script to generate cve jsons https://gist.github.com/greggles/e3c525af1790c05b1ff882eee826f0fd

As I said there, php advisory-to-cvejson.php and it will create the jsons. Note that the URLs on line 202/203 need to be manually edited to create all of them, i.e. comment out line 203 to generate the most recent advisories.

🇺🇸United States greggles Denver, Colorado, USA

Creating this as a postponed followup to #2868079: Add a default Content-Security-Policy-header for svg files to provide a more robust solution to a wider set of problems.

🇺🇸United States greggles Denver, Colorado, USA

greggles created an issue.

🇺🇸United States greggles Denver, Colorado, USA

MR is green again and I addressed the feedback in #65.

🇺🇸United States greggles Denver, Colorado, USA

Thanks for your thoughts, gapple, and setting back to RTBC.

I forgot to mention I confirmed this is the header used by github for svgs content they serve.

I agree with gapple's comments that the change to all private binaryresponses could be broken out to another issue and we would still have most of the value in this issue.

🇺🇸United States greggles Denver, Colorado, USA

I did some more manual testing and realized that the previous rule allowed `malicious.sVg` to bypass the protection. I updated the htaccess rule to be case insensitive. I've now manually confirmed this protection works on public and private svg files.

Thanks for the feedback, @larowlan. I accepted the one suggested change.

The proposed new header for all private files was introduced by gapple (CSP maintainer) so it feels pretty likely to be widely acceptable.

🇺🇸United States greggles Denver, Colorado, USA

Thanks @phenaproxima!

mr.baileys and I are doing another round of testing and will ping others to get more eyes on the security component of this.

🇺🇸United States greggles Denver, Colorado, USA

OK!

I think the script is now handling most version strings as well as it can given the source data. I also incorporated the CWE and CAPEC data from the spreadsheet. Feedback on the spreadsheet has slowed down, so we can probably consider that relatively stable.

The script relies on the D7 API on drupal.org which is going away, so I don't think we should try to make this part of the tooling here. The script quality reflects that its a onetime thing that is meant to go away, but feedback is welcome to make it better.

How can you help?

I encourage folks to download the script, run it with php advisory-to-cvejson.php and then review the resulting json either manually or by uploading it to https://vulnogram.github.io/#editor

It's expected that 7.x versions are not valid and will prevent submission in vulnogram until they are manually fixed.

🇺🇸United States greggles Denver, Colorado, USA

Thanks, alexpott. I did a bit more of an update to the issue summary to make it more of a focused summary of the conversation and current status.

There's currently a failing test and I'm unsure if it's related or what the cause is.

🇺🇸United States greggles Denver, Colorado, USA

I added change records as suggested in #54. Thanks for the review!

🇺🇸United States greggles Denver, Colorado, USA

Updating the issue summary with progress. A ton of comments were left on private issues. A few folks have left feedback there or here about the CWE/CAPEC, which is nice. So far nobody has asked for a change in credit on cve vs the advisory.

I've got a pretty simple php script that creates the json for the CVEs, though it has some limitations that I don't think we're going to get beyond:

  • The version data in advisories is not super consistent and support for 7.x makes that worse. Therefore the output is not always accurate which will require some manual work in vulnogram and comparing back to the source advisory.
  • It doesn't create descriptions. My plan is to manually click the "Auto Generate" button in vulnogram.
  • I haven't yet integrated the CWE/CAPEC spreadsheet data to the process, but that's the last step before outputting all the files.
🇺🇸United States greggles Denver, Colorado, USA

updating link and language from provisional toward onboarding

🇺🇸United States greggles Denver, Colorado, USA

Backporting to 10.x can be a followup, IMO, so I removed the web.config from the issue summary.

Consider adding warning to image fields when people allow SVGs to be uploaded.

It seems better for this issue to ship the CSP and consider that good enough. I removed the idea bout labels from the issue summary as well.

🇺🇸United States greggles Denver, Colorado, USA

There were some test fails.

The core.services.yml definition needed to be updated after 📌 Add default autoconfigure to all *.services.yml and remove event_subscriber tags Fixed .
Since this issue is about updating the htaccess we also need to update the scaffold htaccess.

The other test fails didn't look related to me, but I'm not sure.

🇺🇸United States greggles Denver, Colorado, USA

Tried to address the feedback from the bot in #48.

🇺🇸United States greggles Denver, Colorado, USA

If #2868079: Add a default Content-Security-Policy-header for svg files happens then that should get rolled into these recipes as well.

🇺🇸United States greggles Denver, Colorado, USA

This seems like a highly valuable feature before Drupal CMS 1.0 ships, so bumping priority.

🇺🇸United States greggles Denver, Colorado, USA

Issues that will be packaged in a security releases and advisories are worked on in private. Working on this in public was agreed which means there will be no advisory nor security release.

The question of whether it needs CR? Not sure personally.

🇺🇸United States greggles Denver, Colorado, USA

Great, thanks for taking a look, mradcliffe!

🇺🇸United States greggles Denver, Colorado, USA
🇺🇸United States greggles Denver, Colorado, USA

IMO this is a critical bug, so adjusting priority.

🇺🇸United States greggles Denver, Colorado, USA

Yes, I think 54 is similar and potentially relevant. Thanks for reviewing!

🇺🇸United States greggles Denver, Colorado, USA

I think we could consider providing OpenSSF format in addition to CVE. However, the CVE process has gotten a bit easier since the slack thread linked in 2022.

There are now CVEs for all of core issues for 2024.
I'm working through contrib for 2024 in 📌 Create CVEs for contributed projects in 2024 Active .

I'd love help on those to the extent folks can do it. Ping on slack or those issues if you're interested in helping.

🇺🇸United States greggles Denver, Colorado, USA

Lots of great discussion here and it was created first. However, I think this should be marked as a duplicate of 📌 Create CVEs for contributed projects in 2024 Active since that's where a lot more work is happening.

🇺🇸United States greggles Denver, Colorado, USA

For the Smartling and Loft Data Grids advisories they had hardcoded/distributed vulnerable libraries that had their own CVEs. I updated those advisories with the relevant CVEs and I think we should not issue new CVEs for those. I deleted them out of the spreadsheet.

I also deleted any PSAs.

🇺🇸United States greggles Denver, Colorado, USA

I started commenting on private issues using this text. Feedback to improve it is welcome.

Hello,

The Drupal Security Team is attempting to create CVEs for advisories issued in 2024. We would appreciate your assistance in this process in a few ways.

We will classify the Problem Type using a CWE https://cwe.mitre.org/ and classify the Impact using a CAPEC from https://capec.mitre.org/data/index.html We will do our best to assign a CWE and CAPEC value. <strong>We would appreciate the help of folks involved in this issue in identifying the right CWE and CAPEC. </strong> You can leave your suggestion as a comment on the <a href="https://www.drupal.org/project/securitydrupalorg/issues/3491985">public issue about this process</a> or as an edit on the spreadsheet linked from that public issue. If you want to help filling in more values in the spreadsheet that would be welcome as well.

We will use the names in the advisory and credit them on the CVE as finder, remediation developer, and coordinator. If you wish for your name to be excluded, you may comment here indicating that preference.

We hope this process will help site owners to maintain their sites AND give more valuable recognition for the work of finding and fixing vulnerabilities.

Thanks!

Also the process to assign CWE and CAPEC is about 25% done though I imagine it will be slower to do the rest than these first few.

🇺🇸United States greggles Denver, Colorado, USA

noting the limit of 50 items per page in the limit section.

🇺🇸United States greggles Denver, Colorado, USA

OK, I published these and updated the advisories to include the CVE number.

Up next is 📌 Create CVEs for contributed projects in 2024 Active .

If there's any proposed necessary edits to these feel free to comment with them, though my priority personally is on getting all of 2024 filed.

🇺🇸United States greggles Denver, Colorado, USA

Thanks for raising that detail.

Option 2 feels like an OK solution in the short term.

Also, if anyone wants to help assigning CWE and CAPEC in that spreadsheet please request "Edit" access via the google interface. Or you can leave comments here with suggestions of values and I will get them into the spreadsheet.

Thanks!

🇺🇸United States greggles Denver, Colorado, USA

OK, here's a spreadsheet with some data that will hopefully help us to get to CWE and CAPEC values for all of these advisories.

🇺🇸United States greggles Denver, Colorado, USA

Has this situation come up again?

It seems uncommon enough that more documentation is not warranted.

🇺🇸United States greggles Denver, Colorado, USA

Do you have some example scenarios to add?

I think we could say that XSS is CI:Some/II:Some.

What else?

Production build 0.71.5 2024