Got feedback for our new open-source Advisory Database repository?

[KateCatlin]

Welcome 🎉

Github just released our new Community Contributions feature, and we can’t wait to hear your feedback!

Along with Community Contributions, GitHub is publishing the entire contents of the Advisory Database to this new public repository. Together these changes make it easier for you to share your knowledge and for the community to benefit from the advisory intel.

How to use this database

There are two ways to provide a community contribution to a security advisory. The first way is to open a pull request against a vulnerability in this repository.

The second way is to navigate from https://github.com/advisories to the advisory to which you wish to contribute to, and submit your research through the “suggest improvements for this vulnerability” workflow. In the following form, you can suggest changes or provide more context on packages, affected versions, impacted ecosystems, and more.

To complete your submission, the form will walk you through opening a pull request that details your suggested changes. Once the pull request is open, security researchers from the GitHub Security Lab, as well as the maintainer of the project who filed the CVE (if known), will be able to review your request. Contributors will get public credit on their GitHub profile once their contribution is merged!

Let's talk!

Do you have questions? Comments? Concerns? Kudos? This is the place to voice them. Let’s chat!

[ljharb]

It'd be great to use CODEOWNERS so that maintainers of packages got automatically notified on PRs that affected their packages; that way i wouldn't have to watch the entire repo.

[KateCatlin]

Thanks for the feedback @ljharb!
We currently @ mention the author and/or publisher of the vulnerability if they created it on GitHub (otherwise we don't have the data). Are you saying you'd prefer we notify everyone listed in the CODEOWNERS file?

[ljharb]

ah, then maybe you've already set up what i'm hoping for :-) i don't actually care if it's CODEOWNERS or not, i just want to be sure that i don't miss any activity that affect packages I maintain.

[KateCatlin]

Sounds like we've got you covered here! But don't be shy to share feedback if it's not working for you. Thanks @ljharb!

[ljharb]

Could PR titles mention the ecosystem, package name, and vuln category? The GSA id doesn’t seem particularly useful as at-a-glance info.

[KateCatlin]

Great feedback, thank you! I'll write up an issue to address it.

[KateCatlin]

We've picked this up to ship and it should be changed shortly!

With a slight change– Decided to make the PR title the same as the advisory title as that will hopefully be an equally good at-a-glance reminder and frequently includes the ecosystem/package name/vuln type regardless. Let me know if that works or is still not solving the problem.

[ljharb]

I’ll take a look once it’s shipped, but that sounds workable!

[KateCatlin]

Shipped! 🚀

[MTRNord]

Coming from #24 it would be nice to get some visual indication on which fields are required to get set for submitting a change :)

[KateCatlin]

Thanks @MTRNord, great feedback. Got a ticket written to address this and we'll get it fixed asap.

[westonsteimel]

Has there been any discussion about how to go about contributing an entirely new advisory (for instance some historical CVE that just hasn't been tagged with specific package information)?

[westonsteimel]

I help triage advisories for the Python Packaging Advisory Database and it would be really great to have a way to get GHSA entries created for anything that doesn't yet have one and is deemed valid (and if it turns out we have something that shouldn't be there, we can get it withdrawn from ours)

[KateCatlin]

Hi @westonsteimel thanks for reaching out!

Has there been any discussion about how to go about contributing an entirely new advisory

Most definitely!

If you are the package maintainer, you can already create a new security advisory and even get a formal CVE number through our repository security advisory feature.

If you are not the package maintainer, we are brainstorming a possible feature to report a new vulnerability for the maintainer to review. This is still in its initial idea stages and will be separate from this community contribution feature.

for instance some historical CVE that just hasn't been tagged with specific package information

This part is possible now. Our new unreviewed category is filled with advisories that are auto-imported from NVD and have not yet been tagged with the ecosystem and package information. Our Curation team does a pass through them to seek the ones that are part of our eight supported ecosystems (currently including Composer, Go, Maven, npm, NuGet, pip, RubyGems, and Rust), but of course, there could be more that we missed.

If you find one without a package name and it is part of our eight supported ecosystems, you can go through the community contribution process and add it as described above.

Right now our unreviewed category only goes back to November 2021, but we also have plans to backfill historical NVD advisories as well.

I hope I answered your question, but let me know if there's more I can clarify! We'd love to work with communities like Pypa to drive closer integration!

[westonsteimel]

Thanks so much! Yes I think that covers it. I suspect that most of the cases where PyPA has one that GitHub doesn't fall before the November 2021 threshold, but I'll run some scripts later to have a look.

[tony]

Hi! Thank you for this feature!

I have an auto-imported security advisory GHSA-mv2w-4jqc-6fg4.

My user story (what's worked so far!)

I've been able to add a suggestion by clicking "Suggest improvements for this vulnerability". It created a PR at #108 which was merged d184017. It's live now and looks very to see it connected with data from pip, versions, and a connected package also subject to the flaw.

I have some curiosities!

• Where does my security credit come from? Is it my fix for the vulnerability as the package maintainer or just me having a suggestion merged in this repository?

• Can it be credited to the finder @dellalibera also, or in my place?

  He found the vulnerability and I just wrote a fix. The fix and test I ultimately merged was almost verbatim the suggested fix he offered, I recreated it in test form. I feel a tad guilty taking credit 😆

• Can an auto-imported security advisory be attached to a github repository?

  In my case, would it be possible to have it show here: https://github.com/vcs-python/libvcs/security/advisories

  I believe that if the advisory was connected to the github repository, it'd alleviate the issue above as I'd be able to add credit them there

[dkasak]

I find it similarly weird that GHSA-xvqg-mv25-rwvw is credited to a person who submitted an advisory suggestion but not to the original reporter. The credits section certainly gives the (wrong) impression that it's listing the vulnerability reporter.

[KateCatlin]

@tony thanks for all the questions! I have answers for you...

Where does my security credit come from? Is it my vcs-python/libvcs#306 as the package maintainer or just me having a #108 in this repository?

Today you are getting that credit for having a contribution merged. It looks the same as the credit for having originally reported it and being given credit on the original security advisory. We agree @dkasak that this is weird, so we're changing it! I don't want to commit to ship date too soon but this is on our roadmap to differentiate types of advisories.

Can it be credited to the finder @dellalibera also, or in my place?

Not right now. But giving credit to others is a functionality we'd like in the future too.

Can an auto-imported security advisory be attached to a github repository?

Again, not yet. But great suggestion for the future.

[GrahamCampbell]

I am having trouble correcting a listing. How do I combine version constraints?

[GrahamCampbell]

Tried that too, and it didn't work. Same error.

[chrisbloom7]

@GrahamCampbell I am pretty sure it's due to needing a space between the range operator >= and the version string 3.0.0

[ljharb]

if so, i'd encourage you to use https://npmjs.com/semver for that form (http://semver.npmjs.com for a demo) which is more forgiving :-)

[chrisbloom7]

We'll log an issue about making that a little more obvious, or better yet fix it automatically.

[chrisbloom7]

@ljharb just an overeager regexp IIRC 🤣 😭

[Bibo-Joshi]

Hi. The "Suggest improvement" interface is nice 👍 After opening #323 I also noticed the info

Submitting improvements to this security advisory will create a pull request for the GitHub curation team to review and track.

which is directly below the headline and easy to overlook IMO :D I would suggest to relabel the "Submit improvements" to something like "Create Pull Request" or "Submit improvements as Pull Requests". Maybe one could also include a note somewhere about checking for already openend PRs to avoid duplicates :)

[KateCatlin]

Great idea, thanks @Bibo-Joshi! We're still actively iterating on these advisories so I'll add that to the list of papercuts to address. Appreciate it!

[kornelski]

The "Improve security advisory" form looks like a full submission of the whole advisory. It doesn't have a free-form field where I can comment what's wrong with the advisory. It feels weird to submit new data without an explanation why it needs to be changed.

[KateCatlin]

That's great feedback @kornelski, thank you. We've been toying with the idea of adding a comments section so that's good evidence to do so.

For now, you can submit it and when it opens a pull request you can edit the pull request description with the explanation. But I agree that not everyone may know that's a possibility and something more inviting would help.

[kornelski]

GitHub uses CVSS scores of a "worst possible scenario", and this means that severities of alerts are highly inflated. This policy combines exceptionally poorly with Rust advisories about unsoundness in APIs.

1. Rust has safety-related concepts and API contracts that don't exist in most other languages, so it publishes security advisories about things that wouldn't be notable in other languages. In other languages such problems are mere "the documentation wasn't clear about an edge case" or "downstream user could have used the library in a way it wasn't meant to be used, but it's their fault for writing code that doesn't make sense" (it's cool Rust gives a higher level of guarantees, but you have to keep a perspective that it's not your average security advisory).

2. CVSS severity doesn't take into account just how unlikely it is that a soundness issue will lead to a vulnerability. Soundness holes are typically about API contracts, not implementations. This may mean they can't be exploited merely by invalid program inputs, and instead require program's code to be written in a specific unusual way. In practice these problems may be purely theoretical and not exist in any real program.

Here's an example where this combination of policy and theoretical issue leads to an absurdly inappropriate Critical score. The advisory is about library trusting results of a hidden auto-implemented method called __private_get_type_id__. Per CVSS some developer could have discovered existence of this undocumented method that has a double-underscore private name screaming not to touch it, and could have deliberately manually implemented it, despite it being difficult and entirely pointless to do so, and this manual implementation could have been incorrect.

I fault GitHub for seriously considering such absurdly unlikely possibility as a "Critical" issue. I've been alerted about this problem as if it was a real imminent security danger, but in practice this was a false alarm. This problem can't happen in practice and doesn't affect anyone.

I already ignore all npm audit warnings. It keeps crying that everything is critically vulnerable all the time, but when I look into it it's just some "if you wrote a bad regular expression, which you didn't, then it'd be bad". I'm disappointed that GitHub's severity scores are inflated in the same way. I'd expect "Critical" score to be reserved for Heartbleed, and not used for anything less.

Labelling trivial issues as Critical puts me in danger, because it teaches me to ignore the severity entirely. I can't be responding to so many pointless non-issues with the urgency and seriousness that real Critical issues require. When an actual Critical issue is discovered, I'll leave it ignored underneath the pile of a hundred false positives labelled as Critical too.

Hey, this is GitHub. YOUR HOUSE IS ON FIRE!!!

Advisory: in your basement cupboard you have a spray with a "warning: flammable" sticker on it, and we've found that the glue on this sticker could be weakened by moisture. According to CVSS worst-possible-scenario rule the sticker could fall off, you wouldn't know it's flammable, and set your house on fire. Therefore, ACT NOW!!! YOU'RE IN CRITICAL DANGER!!! YOUR HOUSE IS ON FIRE!!!

[ljharb]

This is a massive problem in the npm ecosystem as well; it reflects a fundamental flaw in the architecture of the CVE ecosystem.

[boringcactus]

If I get one more alert about a non-exploitable ReDoS in a transitive dependency, I am going to scream. It has been almost two years since https://overreacted.io/npm-audit-broken-by-design/, and nothing has changed.

[dkasak]

Advisories imported from NVD which are not from one of the "supported ecosystems" can't currently be edited and improved, because the ecosystem is a required field. An example is GHSA-269w-9hm6-g22q, which refers to a C library hosted on GitLab.

Surely such advisories should still be editable? Should also consider having an Other ecosystem for stuff that doesn't fit elsewhere, such as C projects.

[kmk3]

Advisories imported from NVD which are not from one of the "supported
ecosystems" can't currently be edited and improved

I just hit this issue as well when trying to update an existing advisory:

• [GHSA-2q4h-h5jp-942w] Firejail before 0.9.64.4 allows attackers to bypass... #1814

Related discussion:

• Include more details in "unreviewed" advisories #568

Surely such advisories should still be editable? Should also consider having
an Other ecosystem for stuff that doesn't fit elsewhere, such as C
projects.

+1

@KateCatlin

@dkasak that's a major issue we're toying with as all contributions right now
are reviewed by our highly-trained curation team. That's why we gate it to
only supported ecosystems because our Curators can only be experts on so
much.

I see, but that might not be necessary for more trivial contributions.

For example, in the PR above, I think that being familiar with git should be
enough to review the changes, as it's more about adding missing information
rather than changing the explanation/metrics/score or anything of the sort.

Still trying to find creative solutions for the future though... perhaps a
category like "Unreviewed but edited" or something? What do you think?

Currently the advisory already mentions the following:

This advisory has been edited. See
History.

So if anything, it might be better to improve the commit messages from the
advisory-database bot to clarify what each one is about (and include a link to
the pull request if applicable). Example commit message titles:

• Advisory Database Sync (NVD)
• Update schema_version
• Review GHSA-XXX
• Edit GHSA-XXX

But if you must do something with the fields, I think it would make more sense
as a separate field, since it's arguably something that can happen
independently of when/if an advisory is officially reviewed by GitHub. That
is, community edits can happen multiple times, including after an advisory is
reviewed.

Example fields:

• Reviewed by GitHub: yes/no (type:reviewed / type:unreviewed)
• Edited by the community: yes/no (is:changed / is:unchanged)

(By the way, I find the current type:(un)reviewed a bit confusing, as being
reviewed or not seems more like a status:, though it might be unfeasible to
change it now)

But implementation details aside, I wouldn't consider that a blocker (having
Other as the ecosystem would be enough).

As a user and as someone involved with a project (rather than a being a
reviewer, for example), the key part to me would be enabling contributions to
existing advisories.

[JafarAkhondali]

I decided to add a link to fix commit in GHSA-vf42-37cv-443p, but it doesn't allow me to do so without selecting Ecosystem->Affected products. The vulnerability is related to free-bsd, we can't categorize it.

[darakian]

@JafarAkhondali apologies, but we scope ourselves to a set of ecosystems that we know we can provide high quality advisories for and we do not support free bsd at the moment.

https://github.com/github/advisory-database/?tab=readme-ov-file#supported-ecosystems

[sparrowt]

I'm hitting the same issue: I cannot improve GHSA-jm46-725r-hh9v (to correct which versions of cpython are affected) because it forces me to choose "Affected products" where python is not an option (only pip).

If the GHSA page is going to exist, it should be possible to improve/correct it - so is this a bug, or should that GHSA not exist?

[samueloph]

This issue also happens with the "Title" field, I can't improve an untitled advisory without having to give it a title as well.

[lukaseder]

Some CVE's aren't really actionable because a fix hasn't been published yet. For example, see "patched version: none":

In the "Dismiss alert" dropdown, I'm missing an option allowing to dismiss the alert until a patched version becomes available. I would like to upgrade this dependency eventually, but obviously can't just yet.

[KateCatlin]

Great feedback, thanks @lukaseder. I'll pass this along to our Dependabot team.

[taladrane]

hi @lukaseder 👋 I wanted to follow up and let you know that the ability to snooze a Dependabot alert until a patch is available was beta released yesterday at the repository level 😄

[lukaseder]

That's a very useful addition, thanks a lot for pinging me about it, @taladrane!

[edthedev]

It would be terrific to have a 'Convert to Issue' button on these advisories (much like pull request comments have).

At the moment, if the update needs manual changes, I don't see an easy way to link related git commits and pull requests to these advisories.

[edthedev]

I've settled for adding a link to the CHANGELOG as a reasonable work-around. But it would be great to handle these alongside other issues without manually creating and linking a new issue.

[KateCatlin]

Hey @edthedev! Thanks for reaching out. Would you want that 'convert to issue' button to be on an advisory listed at https://github.com/advisories? Or do you want that to exist on a Dependabot alert within your repository?

[edthedev]

@KateCatlin I would want the 'convert to issue' button on the Dependabot alert within my repository. That way it can flow through the usual issue tooling we have setup on that repository. We do get this benefit when Dependabot can open a pull request, since a pull request is also an issue. But when Dependabot cannot create a pull request, a 'convert to issue' button on the advisory would be very welcome.

[KateCatlin]

Got it thank you @edthedev! I'll pass that request along to the appropriate PM internally here!

[joachimmetz]

Can GitHub please commit to make sure to keep "security advisories" up to date and accurate?

E.g. GHSA-v833-mfjc-7qr5 was updated upstream, the "advisory" here is still stale.

Also the "advisory" here, does not provide any advice.

[joachimmetz]

then why bother importing it in the first place? having stale/incorrect advisory information is worse than not having it

[westonsteimel]

Importing them in the first place is really important because the community can't submit enhancements to historical data if an advisory doesn't already exist in the database. I think GitHub have done an excellent job in bringing these in and building such great tooling for contributing enhancements back to the dataset. I agree having a process to keep unreviewed and unmodified advisories in sync would be ideal, but bringing them in as-is and clearly labelling them as unreviewed seems a very reasonable initial approach to me.

[joachimmetz]

observation during log4j, after months of the upstream advisory had been changed to indicate that originally proposed mitigation measures were inadequate, people were still applying them due to sites with out of date information as you propose to have, and claiming they had addressed the vulnerability while the opposite is the case.

How is one more site with out of date/incorrect vuln advisories going to help? Why not spend the time and energy of having 1 correct and up to date authoritative source?

[dkasak]

but bringing them in as-is and clearly labelling them as unreviewed seems a very reasonable initial approach to me.

Heavily disagreed. When you have prominence on the level of Github, you simply cannot afford to be distributing outdated and inaccurate information. Since in this instance Github is in the business of mirroring information from an upstream rather than being an upstream itself, the first reasonable iteration ought to be the one in which you have the ability to automatically pull upstream revisions.

[KateCatlin]

I agree with all of you. It's our mission as a database to serve up the most accurate information we can, and that's what we work to do every day. Clearly this initial approach is not cutting it and we absolutely should be auto-merging all updates on unreviewed advisories.

I did update my comment above with some more complete information, which is that we auto-merge updates to unreviewed advisories today if the information is purely additive. However, if the update would overwrite existing data we do not merge it because it was historically decided that it must have human eyes on it, and we couldn't manually review it and keep it in the unreviewed category.

That said, we still want to get this resolved! I've already discussed this with the team. As soon as we have an available engineer, we'll be fixing this. I'll return back to this thread and update you all when that's shipped!

[richardfan0606]

Hi there,

As I checking the vuln data for composer, the name and format of the composer packages are not consistent. For example:
librenms >> librenms/librenms in GHSA-5229-94p3-7wwq
adminer >> vrana/adminer in GHSA-m56g-3g8v-2rxw
snipe-it >> snipe/snipe-it in GHSA-4w23-c97g-fq5v
grav >> getgrav/grav in GHSA-wrxc-mr2w-cjpv
Can we suggest a standard of the package names for each type?

[darakian]

Hey @richardfan0606. thank you for the corrections on GHSA-5229-94p3-7wwq, GHSA-4w23-c97g-fq5v, and GHSA-wrxc-mr2w-cjpv. Those three do have erroneous packages listed. I've gone ahead and updated our data to reflect the correct packages.

GHSA-m56g-3g8v-2rxw has been withdrawn as a dupe of GHSA-9pgx-gcph-mpqr which does have vrana/adminer listed as the affected package.

To directly answer

Can we suggest a standard of the package names for each type?

We use the package names for the backing registries (packagist.org in this case). The full list is here https://github.com/github/advisory-database/#supported-ecosystems

[Timwi]

I frequently get advisory warnings for files that have long been deleted from the repo. I don’t think maintainers should be warned about files in long-ago repo history, but only the current version. My latest warning was for an old version of jQuery I already removed from the repo a month ago (Jun 16, today is Jul 11).

[vancluever]

I was recently informed that this repo exists and the advisory DB is open for feedback/discussion!

This is great! But it would be nice if this was a bit more obvious from the dependabot interface itself. Currently, the web form for improvements (https://github.com/advisories/GHSA_ID/improve) does have some links to some detail about the advisory DB, but if there was a way to make that more obvious, I would have been able to find some discussion about the alerts I was seeing that would have answered my questions. 🙂

[KateCatlin]

Thanks for the feedback @vancluever, I'll check in on that.

Out of curiosity, what was the discussion that helped you resolve your question?

[vancluever]

@KateCatlin unfortunately I don't have the exact advisory anymore, but ultimately I made my way to the advisory DB repository where I was able to search for the advisory number and determine that there was already progress towards correcting it.

Hope that helps!

[KateCatlin]

Awesome, thanks for letting me know!

[vin01]

Hi, while trying to update an existing advisory via a PR, I just noticed it is not possible to add Credit to reporters, for e.g. I reported GHSA-rrjw-j4m2-mf34 and see no way to update it and get credit as a reporter of the issue. Is it intentional or there is a way to update an advisory to get Credit?

[KateCatlin]

Hey @vin01, as of today there is no way to exclusively request credit on an advisory.

However, if someone submits a community contribution that improves an advisory and it is accepted by our Curation team, they will then be given credit on an advisory with the analyst credit type.

Allowing folks to request reporter credit is a feature we'd like to build in the future! In the interim, I would suggest doing as much of your reporting as possible through our new private vulnerability reporting feature so that reporter credit is automatically applied.

[vin01]

thanks for the prompt response, appreciate it.

I usually do try to follow the private reporting feature but not all projects use it, for e.g. in Rust ecosystem, reporting via RUSTSEC is mostly how it works: https://rustsec.org/contributing.html

[KateCatlin]

Love to hear that! Thanks @vin01!

[medikoo]

I've just noticed some functionality degradation.

There are cases where vulnerability affects just specific middle range or versions (.e. g just version v8 and v7, but not v6 and not v9), and currently it seems not possible to configure such vulnerability range.

When this database supported, we were able to fix that issues, as e.g. one here: #179

Currently I see another similar regression in database and I'm not sure how it an be fixed

[darakian]

@medikoo can you elaborate on what you mean? Different version ranges should be expressed as the same affected product on a new line with a new range attached. We do still support that if that's what you're getting at.

[medikoo]

@darakian See #2901. The form for PR (https://github.com/advisories/GHSA-c59h-r6p8-q9wc/improve), accepts single range for "Affected versions" and inputs as >=0.9.9 <13.4.20-canary.13 or 0.9.9 - 13.4.20-canary.12 are not accepted.

I see that in PR you've suggested to separate ranges with coma, but it's not valid per semver range spec, see e.g. https://devhints.io/semver

[darakian]

Not all of our ecosystems follow semver which may be the root issue here, but glad you got it working 👍

[ebickle]

GitHub team,

Many packages use a breaking change as an opportunity to rename the package. If a vulnerability is found on the old name for a package, there's often no way to inform users that a new version exists in a different location.

A classic example of this log4j:log4j, the last official version of which is 1.2.17. If you look at https://github.com/advisories/GHSA-f7vh-qwp3-x37m/improve you can see that log4j:log4j is affected for <= 1.2.17 - all versions - and that there is no patched version. However, there is a patched version - the latest release of Log4j 2.x over at org.apache.logging with the log4j-api or log4j-1.2-api packages.

When this occurs our users often incorrectly believe there is no security fix available; they don't realize a new version is available with a new name.

Would it be possible to add fields to the GitHub advisory database to handle this scenario? e.g. a Patched package name field or equivalent? Thanks in advance!

[retr0reg]

Hi, recently I reported the the private advisory-thread GHSA-56xg-wfcc-g829 and it's published in the database as GHSA-56xg-wfcc-g829. When editing my report before publishing, I changed my credit from reporter to finder (since I reported and found this vulnerability which adheres to the docs).

However now it seems like my credit is not marked in the database since I didn't recieve any result when searching for credit:retr0reg (My Username), nor "1 security advisory credit" prompt appears when visit my profile or hover on my icon. I wonder if this is a bug of the database?

[carogalvin]

Hey @retr0reg , we took a look and fixed it! You should see your credit show up in all the right places now!

[KyLeggiero]

There should be a way to ignore the generated lock files of a static GitHub Pages site, because it's generated at pushtime and only runs on GitHub's servers without any opportunity for attack

[carogalvin]

@KyLeggiero can you clarify what you're talking about here? Are you looking for Dependabot alerts to ignore these lock files?

[KyLeggiero]

Yes. For example, I have several sites which have a Gemfile that only contains gem 'github-pages'. When Github Pages builds this site, in the backend, it generates a Gemfile.lock for itself before shutting down its generator and serving the static files.

Eventually, something like nokogiri has a vulnerability. My Gemfile doesn't mention it at all; all my code says is to use the latest version of Github Pages.

This results in Dependabot sending me alerts for dependencies like nokogiri (which I genuinely have no clue what that is), and then when I tell it to show me the problem it fails because that code it's calling out doesn't exist in my repo.

The vulnerability only exists in some dependency that is technically related to my code on Github's backend, but doesn't actually matter because no code actually runs on my site. Github's backend runs the generator and then shuts down, and my Gemfile already says to use the most-recent version of everything, so next time it runs it'll be using the most-recent version of these dependencies and all will be right with the world.

[carogalvin]

@KyLeggiero OK, thank you for the clarification!

[JafarAkhondali]

Not sure to comment here or create an issue:
In my profile it shows "2 security advisory credits", however I have 3 security advisory credits in serchbar: https://github.com/advisories?query=credit%3AJafarAkhondali
Looks like a bug

[carogalvin]

@JafarAkhondali I recommend creating an issue with the details and my team will take a look!