github / advisory-database Goto Github PK

CVE-2022-1650 (GHSA-6h5x-7c5m-7cr7) lists the affected versions as < 2.0.2.

From my understanding, the fix has been subsequenly back-ported, so version 1.1.1 is not affected.

Unfortunately I cannot suggest an improvement to the current entry due to its current use of an unsupported versioning operator.

Which leads me to ask: how can I go about flagging this advisory for review?

Many thanks.

Swift Package Manager (SwiftPM) is the canonical package manager and dependency solutions for building Swift applications on the server. Swift on Server applications are deployed and used by many companies, including Apple and Amazon so adding support for the SwiftPM ecosystem would be great.

Vapor, the most popular server-side framework already publishes security advisories on GitHub.

Newlines in the input markdown get will get converted to literal "\n" in the final markdown for some reason. See GHSA-3vjf-82ff-p4r3

Hello!
Thanks for your work!

I'm trying to get GO vulnerabilities with GitHub GraphQL API but getting null and error.
This error appeared 2 days ago.
small example with GitHub Docs:
query:

query { 
  securityVulnerabilities(ecosystem: GO, first: 6) {
    nodes {
      severity
      advisory {
        ghsaId
      }
      vulnerableVersionRange
    }
  }
}

response:

{
  "data": {
    "securityVulnerabilities": {
      "nodes": [
        [
          [
            "severity",
            "MODERATE"
          ],
          [
            "advisory",
            [
              [
                "ghsaId",
                "GHSA-qggc-pj29-j27m"
              ]
            ]
          ],
          [
            "vulnerableVersionRange",
            "< 5.37.9"
          ]
        ],
        [
          [
            "severity",
            "MODERATE"
          ],
          [
            "advisory",
            [
              [
                "ghsaId",
                "GHSA-qggc-pj29-j27m"
              ]
            ]
          ],
          [
            "vulnerableVersionRange",
            ">= 6.0.0, < 6.2.5"
          ]
        ],
        [
          [
            "severity",
            "MODERATE"
          ],
          [
            "advisory",
            [
              [
                "ghsaId",
                "GHSA-qggc-pj29-j27m"
              ]
            ]
          ],
          [
            "vulnerableVersionRange",
            ">= 6.3.0, < 6.3.5"
          ]
        ],
        [
          [
            "severity",
            "MODERATE"
          ],
          [
            "advisory",
            [
              [
                "ghsaId",
                "GHSA-qggc-pj29-j27m"
              ]
            ]
          ],
          [
            "vulnerableVersionRange",
            ">= 6.4.0, < 6.4.2"
          ]
        ],
        null,
        [
          [
            "severity",
            "HIGH"
          ],
          [
            "advisory",
            [
              [
                "ghsaId",
                "GHSA-xg75-q3q5-cqmv"
              ]
            ]
          ],
          [
            "vulnerableVersionRange",
            "< 1.2.6"
          ]
        ]
      ]
    }
  },
  "errors": [
    {
      "type": "INTERNAL",
      "message": "Something went wrong while executing your query. Please include `2CF6:089E:1738E38:3742B62:626640C9` when reporting this issue."
    }
  ]
}

Thanks in advance for your reply!

Hi,

I just found out the ecosystem thingy is mandatory to put in affected versions. Is there a reason/need behind that? Because for example, WordPress plugins are in the database, but you can't use the form for them as WordPress is not in the predefined ecosystem fields. The same goes for GHSA-gqhp-5j32-xwmm which is a nodejs issue which doesn't fall into an ecosystem that is predefined. There are probably also plenty of other examples.

I am mainly wondering about the reason why it is mandatory, as I think having typed version ranges alone are also very helpful in case anyone wants to use the database for a tool. However, typed versions seem impossible without the ecosystem at this time.

CVE-2021-3121 is missing from the advisory database, which means Dependabot is not offering updates for it.

https://nvd.nist.gov/vuln/detail/CVE-2021-3121
https://security.snyk.io/vuln/SNYK-GOLANG-GITHUBCOMGOGOPROTOBUFPLUGINUNMARSHAL-1058921

This might sound like an obvious question and maybe I'm wrong and this is supported or I didn't read the documentation correctly.

But I think it would be great if the Advisory Database integrated with Github Releases, Github Packages and Github Advisories for Github Projects.

# Use case

This could work well with dependabot and the new Dependency submission API. For example, I'm using Nix. Nix as a package manage does not typically use a centralized registry and rather uses "channels" that contain packages.

However, nix packages many times fetch the sources from github. With the dependency submission API, a given nix dependency could be reported to be from github (or other supported ecosystem such as npm) and dependabot now would be able to report security vulnerability for nix dependencies.

Should re-packagings of software artifacts from other ecosystems be supported for automatic inclusion in security advisories?

As a specific example, there exists the webjars project which packages javascript packages up and makes them available on Maven for inclusion of js dependencies in a java project. It might be useful to have these automatically included on new npm advisories for which a webjars artifact exists

Continues discussions from #607

Hi all,

First of all, thanks for being participants in the GitHub Advisory Database! Your contributions make our community safer and stronger.

If you are consuming this database in some programmatic manner or otherwise harnessing the OSV schema we've defined our vulnerabilities in, then we want your feedback!

We're happy to share a $60 gift card for a 25-minute call. You can arrange a time here: https://calendly.com/security-advisories-ux-calls/25min?month=2022-06

If that's too much of a commitment, also feel free to comment below!

Thank you in advance,

Kate Catlin
Senior Product Manager, Advisory Database Team

As of 7 October 2021 with the npm audit shift to GAD, all listings previously found at npmjs.com/advisories now redirect to the matching listing in GAD.

All npmjs.com/advisories links should be removed now that they are recursive.

One example: GHSA-333w-rxj3-f55r

When analyzing aquasecurity/trivy#2034 I was surprised to find the advisory id GHSA-qq97-vm5h-rrhg in two different states:

1. GHSA-qq97-vm5h-rrhg from the repo maintainers which seems to be the most up-to-date version, including the CVE number
2. GHSA-qq97-vm5h-rrhg as a public Github Advisory which has not been updated

Because I did not find a machine readable format of the first one I have to ask:

• is there any automation to keep the official advisories in-sync (bot for automated pull requests on updates)?
• where is the official process documented?
• one id, two links, different information: which one is expected to be used by the public? I guess the second one because the on mouse over preview has more details

I have noticed recently the npm vulnerability affected ranges types changed from SEMVER to ECOSYSTEM but the way the impacted versions are described are described as if SEMVER using the introduced and fixed and no versions list is defined which is what the spec suggest should be done.

i am looking at the spec here https://ossf.github.io/osv-schema/#affectedrangestype-field

Any reason why this has changed as it did used to be correct ?

An example is GHSA-mf22-92pm-m8p8

"affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@awsui/components-react"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",                                        <= Should this be SEMVER ? As events below are in semver format?
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.367"
            }
          ]
        }
      ]
    }
  ],

We received a dependabot alert about this advisory:
GHSA-w687-f44x-x42j

It's very strange, because this isn't an NPM package - it's a built-in element of the Unity game engine and is referenced from their "package.json" manifest files (not related to NPM).

Are there any more details about this advisory and if it is indeed an issue with Unity packages?

Thanks for any insight!

Hi!
While consuming data from OSV that is based on the advisory_database data, I found something that doesn't make sense:
Why the package microweber/microweber is listed in the PyPI ecosystem? As of my understanding it has nothing to do with PyPI.

https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2022/07/GHSA-xg72-6c83-ghh4/GHSA-xg72-6c83-ghh4.json

If it's not wrong, I will appreciate if you can check it out, and help me understand the reason it does make sense, thank you.

e.g. ansi_term we provided informational advisory: https://rustsec.org/advisories/RUSTSEC-2021-0139.html
But GHSA has different intepretation / representation: GHSA-74w3-p89x-ffgh

It's an advisory as others but it should be represented in canonical way as RustSec database implicitly intended.

Informational advisories do have security related concerns but these are nonetheless different to regular advisories -

It is database specific OSV attribute:

  "affected": [
      "database_specific": {
        "informational": "unmaintained"
      },

Problem is GHSA / Dependabot as of now does not take into account of different advisory types as canonical representation.

GHSA / Dependabot also assumes "Critical" severity which is incorrect when we don't even flag CVSS for these -

We had a dicussion about it here:
https://rust-lang.zulipchat.com/#narrow/stream/146229-wg-secure-code/topic/github.20advisory.20flags.20as.20critical/near/299276275

Also I see that GHSA / Dependabot omits the provided actionable advice that is helpful to anyone intepreting these advisories - nonetheless it does link to the original RUSTSEC advisory but I think Dependabot should include this actionable "fix" - if any given people might be just fine using unmaintained - for any given time - based on what ever individual / project opinion they hold as to whether to migrate or not.

I've raised another issue about the omitting actionable advice: #684

I don't think GHSA-74w3-p89x-ffgh is a security advisory, and as such probably shouldn't be in Advisory Database. This crate does what it's supposed to, and there are no known security vulnerabilities in it.

On RUSTSEC (https://rustsec.org/advisories/RUSTSEC-2021-0139.html), it's indicated as "Unmaintained" advisory, not a security one.

Hi,do you consider support multiple language about details ?

Currently, you need to redo the entire contribution and then make your change in one go if you want to make a change to an existing contribution you've made. Otherwise, your previous contribution is reverted in place of the new one.

That's really tedious and annoying. If you make an improvement, you should be able to start from your existing pull request.

👋 Hello!

I work on the Product Security Team at HashiCorp that handles the vulnerability management and response process. I am reaching out on behalf of my team in response to the recently published GHSA-27rq-4943-qcwp (CVE-2022-29810).

The vulnerability description states:

The Hashicorp go-getter library before 1.5.11 could write SSH credentials into its logfile, exposing sensitive credentials to local users able to read the logfile.

The related pull request linked in the advisory added a new feature to the RedactURL function provided by go-getter, redacting the "sshkey" URL query parameter, in addition to the "password" URL query parameter. Before the change introduced in the PR, the function explicitly stated that only "password" would be redacted. Moreover, the go-getter library does not have a log file which SSH credentials, or anything else, can be written to.

We believe the advisory (and the CVE we plan to send a rebuttal for to NVD) is factually inaccurate, and should be removed. From previous interactions with NVD, a public rebuttal is required for updating CVE content, and this issue also serves that use case.

We are looking forward to your response, and please let us know if you require further clarification.

Hello Github Team,

Could you explain why GHSA-3wrr-68x8-p887 security advisory has been removed from database?

Adding the C ecosystem would dramatically help organize CVE communication.

For example, the OpenJPEG project has many CVEs from Chromium fuzzing. It is difficult to understand if certain CVEs have been addressed from this projects commit message history and which commits belong to a patch set of a specific CVEs. Many commits which address specific GitHub Issues are not linked. Most GitHub issues do not mention CVEs they address. Some vulnerabilities relate to multiple GitHub issues. An issue could be made for each CVE to tie everything together, but using GHSA would be a vastly better.

By extending GHSA to the C ecosystem maintainers and community members will have dramatically more tools to organize and resolve CVEs.

OSV supports Package URL, however, the OSV feeds in this repo do not appear to have purls. This request is to enhance all OSV files to include purl.

I went to this advisory GHSA-8489-44mv-ggj8 and on the right clicked the Suggest improvements for this vulnerability.

I just removed the log4j-api packages and left the rest as they were. Clicked "Submit Improvements" and had this error that the > operator is not supported.

Related to #422

We started getting this dependabot alert GHSA-9824-332p-264p. It's unclear why this has happened, and I'm unsure how to resolve this. In the other issue the creator mentions that having a shadow package in npmjs.com caused this problem for them, we don't publish to npmjs.com anymore, but we used to do that under a different package name, but that was many months ago and would be weird for it to only pop up now

Hi

Can the advisory database be downloaded? I would prefer to have a local database and query my data against it instead of calling the graphql endpoint for advisories for each dependency

Thanks

https://github.com/Silverfishnet/opensource.guide/blob/main/.github/dependabot.yml

I've just built a tool that natively parses a bunch of different lockfiles and wraps around this repo to determine if there are vulnerable packages.

I've found that GHSA-fq42-c5rg-92c2 is not included in this repo which I'm assuming is because it's a self-published advisory.

I was wondering what the plan is for that situation, as it seems like it's going against the whole point of having this repo if it's not included as e.g. if open source maintainers suddenly got a tool to help them identify issues and so started self-publishing a bunch of advisories, they'd not be included in here.

Release Notes Persisted

Fixed an issue where BrowserWindow#isFocused() was returning false when blur() was called on macOS.

Originally posted by @release-clerk in electron/electron#34030 (comment)

Reorganizing Team Boards (Onboarding first and Team Board after) will be updated every 2 weeks.

For some reason, the bot has lowered the priority of GHSA-484f-743f-6jx2: 2e8e721

I don't understand why, since it has been validated with "HIGH" severity initially: GHSA-484f-743f-6jx2

I was comparing the results of osv-detector to local-php-security-checker and found a few advisories that don't seem to be in the database:

https://symfony.com/blog/twig-sandbox-information-disclosure
https://nvd.nist.gov/vuln/detail/CVE-2017-9841
https://symfony.com/blog/cve-2019-18887-use-constant-time-comparison-in-urisigner
https://github.com/FriendsOfPHP/security-advisories/blob/master/erusev/parsedown/CVE-2018-1000162.yaml
https://github.com/FriendsOfPHP/security-advisories/blob/master/erusev/parsedown/CVE-2019-10905.yaml
https://github.com/FriendsOfPHP/security-advisories/blob/master/sabberworm/php-css-parser/CVE-2020-13756.yaml
https://github.com/FriendsOfPHP/security-advisories/blob/master/squizlabs/php_codesniffer/2017-05-18.yaml
https://github.com/FriendsOfPHP/security-advisories/blob/master/squizlabs/php_codesniffer/2017-03-01.yaml
https://framework.zend.com/security/advisory/ZF2018-01
https://www.silverstripe.org/download/security-releases/cve-2020-26138/
https://www.silverstripe.org/download/security-releases/cve-2021-25817/

Most of them seem like they should be straightforward to add, though the Zend Framework one(s) I'm not so sure about.
Let me know if I can help in anyway.

We have a package in a private github packages repo called @contrast-security-inc/design-system-foundations.

Somehow a package was also published to NPM
https://www.npmjs.com/package/@contrast-security-inc/design-system-foundations

The NPM team flagged this as containing malware. We've opened a ticket requesting more information about who published this version and how it was determined to be malware and asking if it can be removed.

Our repos that consume this package are now receiving this dependabot alert:
GHSA-fx93-477r-j7xh
Is this a false positive? Our .npmrc file indicates that this package is being picked up from our local github packages repo, not the global NPM repo.

It looks like currently, GHSA entries with affected versions using the "= X" operator without a patched version (e.g. GHSA-wxhq-pm8v-cw75), get converted to:

      "ranges": [                                                                                                                                                                                                                          
        {                                                                                                                                                                                                                                  
          "type": "ECOSYSTEM",                                                                                                                                                                                                             
          "events": [                                                                                                                                                                                                                      
            {                                                                                                                                                                                                                              
              "introduced": "X"                                                                                                                                                                                                       
            }                                                                                                                                                                                                                              
          ]                                                                                                                                                                                                                                
        }                                                                                                                                                                                                                                  
      ],                                                                                                                                                                                                                                   
      "versions": [                                                                                                                                                                                                                        
        "X"                                                                                                                                                                                                                           
      ]              

(example)

According to the OSV spec, this actually implies all versions after and including X are affected, because there is no corresponding "fixed" to end the affected range.

Would it be possible to encode such cases as just:

      "versions": [                                                                                                                                                                                                                        
        "X"                                                                                                                                                                                                                           
      ]              

Without the erroneous "range"?

Looking at detail of this vulnerability a fix version for 2.1.0 through 2.1.1 is documented as 2.12 yet on this https://tanzu.vmware.com/security/cve-2018-1260 the fix version states 2.1.2 so i think you are missing the "."

Follow-Up from: #683 as another issue

We typically strive hard to include actionable advice as to any fixes if any on informational advisories.

Currently GHSA Is omitting to include that actionable advice we've included -

This means when Dependabot raises issue with the repo maintainer they don't really know how to resolve it.

e.g. ansi_term we provided advice as to how to fix it: https://rustsec.org/advisories/RUSTSEC-2021-0139.html

But GHSA omitted this: GHSA-74w3-p89x-ffgh

Problem with omitting this information is that people tend to ignore advisories that have no actionable fixes.

Perhaps even saying in GHSA that the RustSec advisory referenced may contain actionable fixes as to how to resolve the advisory can help the advisory consumer.

While Ukraine is under missile attacks GitHub could be used by Russians to develop apps and platforms aiming to destabilize Ukrainian web resources.

Please, prevent these actions and don't stay on the same side with invaders! All information about war can be found at: https://war.ukraine.ua/

We urge you to close GitHub for Russia and its developers! We value your support and we are in need for your actions!

Hi team!

We would like to backfill to the DB NuGet package vulnerabilities for 2017-2020. The list of vulnerabilities below are for .NET and ASP.NET Microsoft packages. Those already have CVEs and the impacted packages were specified in announcements published with each CVE in the .NET / ASP.NET Announcement repositories (https://github.com/dotnet/announcements/issues?q=is%3Aissue+is%3Aopen+cve , https://github.com/aspnet/announcements/issues?q=is%3Aopen+is%3Aissue+cve).

Please let me know if additional details are needed. //cc @taladrane , @JonDouglas, @leecow

There is a tweet making headlines about some malicious code discovered in some abandoned python and PHP packages. Does it make since to create GitHub advisory records for these? I believe both have now been de-listed by PyPI and packagist, but I think it might still be useful to have records generated for them here.

You provide this advice with no further information

com.unity.mathematics is a math library for the Unity game engine from Unity its self. Doesn't mean its not a problem but does mean you need to offer some evidence to support your claim.

Hello,

MITRE has revoked some CVEs but advisories are available in github advisories.

CVE-2021-43503 MITRE Reviewed by github :-|
CVE-2022-31279 MITRE Reviewed by github :-|

Revoked CVEs:
CVE-2021-43503
CVE-2022-34943
CVE-2021-37298
CVE-2022-31279
CVE-2022-30779
CVE-2022-30778
CVE-2019-9081

Please don't publish advisories for POP chains. These are not vulnerabilities and mislead the developers and the cyber security community.

More CVEs will be revoked in the next few days. Please keep your advisories up-to-date to MITRE db.
Probably there is a bug in synchronization. Please address the issue.

Thank you,
Regards,
Mirhossein Rahmani

#595
#594

I can't submit this via the standard way as the advisory doesn't exist in this database yet due to #19.

4.1.1 was published to fix GHSA-93q8-gq69-wqmw for the 4.x line: chalk/ansi-regex#46

So the affected versions should be updated to be:

Vulnerability GHSA-cjw4-2w9r-r8mv is referencing the wrong arrow package.

It mentions the pip arrow package while it should be the pyarrow package.

https://pypi.org/project/pyarrow/
https://pypi.org/project/arrow/

Thanks,
Jonas

Greetings, I see a large influx of similar issues like this so sorry for only on to the pile.

It looks like a private, and only internally used npm package we have called @ibm-pipeline/logging is not only published in the public registry, but it is also being flagged as malware.
As far as I can tell, our team had nothing to do with this and it very well could be a bad actor that published the public package of the same name.

However, our local .npmrc and package-lock.json files are configured to pull absolutely everything from our private npm registry, so I'm perplexed as to why running npm audit pulls up the alert for the public package as that isn't what we're installing and not how I understood audit to work.

Links:
GHSA-g4xx-7vwp-pq9p
https://www.npmjs.com/package/@ibm-pipeline/logging

Output:

harlow$ npm audit
# npm audit report

@ibm-pipeline/logging  >0
Severity: critical
Malware in @ibm-pipeline/logging - https://github.com/advisories/GHSA-g4xx-7vwp-pq9p
No fix available

harlow$ npm view @ibm-pipeline/logging

@ibm-pipeline/[email protected] | UNLICENSED | deps: 3 | versions: 16
logging framework

dist
.tarball: <NOT THE PUBLIC REGISTRY>/@ibm-pipeline/logging-1.0.14.tgz
.shasum: <SHASUM>
.integrity: <SHA>

dependencies:
joi: 17.5.0    nconf: 0.12.0  winston: 3.3.3 

dist-tags:
latest: 1.0.14

Is this a false positive, or something we should be concerned about?
I'm especially curious about npm audit pointing to the public package despite the local configurations.

Thanks in advance for your time.

Hi,
my Windows 10 security system alarmed about a PHP backdoor in one of the files from your archive.

Detected: Backdoor:PHP/Remoteshell.V
Details: This program provides remote access to the computer it is installed on.
Affected items:
file: C:\work\Source\advisory-database\advisories\github-reviewed\2022\02\GHSA-673j-qm5f-xpv8\GHSA-673j-qm5f-xpv8.json

After restoring the file and having a look at it, it doesn't look much of a threat to me but then again I didn't analyze the embedded links. Perhaps you want to have a look at it ?!?

best regards,
D.

I am looking into adding entries for the malicious PyPI packages reported here:

• https://jfrog.com/blog/malicious-pypi-packages-stealing-credit-cards-injecting-code/
• https://jfrog.com/blog/python-malware-imitates-signed-pypi-traffic-in-novel-exfiltration-technique/

Would you have more details about what "Make your change to the advisory file" entails in CONTRIBUTING.md?

For instance:

• Should I create files under advisories/unreviewed or advisories/github-reviewed? Are files moved from one folder to the other automatically?
• How do I come up with the folder/file name (ex: GHSA-6346-5r4h-ff5x)?

Happy to send a PR on CONTRIBUTING.md to include the guidance received here.

The prototype pollution vulnerability for plist is marked as fixed on 3.0.4 but this version doesn't fix this issue.
GHSA-4cpg-3vgw-4877

I added more details here, could you please update the advisory accordingly? Or point me on how to do it?

Thank you.

Hiya lovelies

I've sent to PR corrections around two advisories re: rust vendored openssl-src

• #406 - <-- Issue 2
• #407 - <-- Issue 1

The above advisories are pinging a lot of people in Rust ecosystem as it's the vendored openssl where 111 is typically pulled

Background vendored OpenSSL release streams and how this translates in 🦀 ecosystem

In Rust 🦀 we have two release streams for openssl-src 1.1.1 and 3.0 and there was CVE outlining patched versions:

OpenSSL 1.1.1 users should upgrade to 1.1.1o
OpenSSL 3.0 users should upgrade to 3.0.3

We today updated RUSTSEC-2022-0025,26,27 to reflect the reality for openssl-src :
rustsec/advisory-db#1263

In crates 1.1.1 are under 111. and 3.0 are under 300.

1.1.1o is brought by 111.20.0 which resolves this advisory

This should meant that anyone either below 111.20.0 (in 1.1.1 release stream) or below 300.0.6 (in 3.0 stream) should upgrade to either of release stream relevant patched versions.

Original issue in RustSec
rustsec/advisory-db#1262

I'll be making some noise to perhaps adopt OSV in the future for best translation

Issue 1 - Is RustSec unaffected field taken into account?

Related to second PR and also for the first one before we updated the advisory for the first.. we had marked all / anything below version 300.0 as "unaffected" and is still as such on the second correct advisory

[versions]
patched = [">= 300.0.6"]
unaffected = ["< 300.0"]

However dependabot both before was and is still currently atm asking 🦀 to switch from 111.0.0 openssl-src release stream to 300.0.6 which is incorrect advice as 111 release stream was supposed to be unaffected by the unaffected statement

Basically this has made all crates that use vendored openssl (quite few of those) to have this advisory pinged on where the vendored openssl typically pulls from 111 release stream leading to this ping.

I suspect this might be an issue where dependabot might not be reading the unaffected attribute from RustSec ?

Going by above should not have asked 111. users to switch to 300.0.6 - a separate issue related to unaffected field perhaps?

Issue 2 - How do the advisories get synced on crates with multiple release streams?

We also resolved this separate issue with the first advisory in list as it should have flagged vulnerable 111. versions too

But fact is that 111 release stream was affected as well so we upgraded our advisory to below to take 111. into account:

The advisory on the first PR related advisory was today changed to:

[versions]
patched = [">= 111.20.0, < 300.0.0", ">= 300.0.6"]

This might also stop dependabot asking 111 release stream users to switch 300 on first PR but in case this doesn't fix it these two issues should probably be addressed.

I am not sure whether this needs to be synced manually over after the advisory has been correlated for the 111 stream ?

Hi

Is there any info about https://tanzu.vmware.com/security/cve-2022-22947? It affects spring cloud gateway but its not clear which library is the one vulnerable, i guess it is spring-cloud-gateway-server.

The CVE has still not been released by NVD

Is this vuln catalogued in the DB? If not, do you have any extra info on the exact library affected to create a PR?

E.g. https://github.com/github/advisory-database/blob/d6004eb8de91ad341605da869ab1b9f1e4abe433/advisories/github-reviewed/2017/10/GHSA-hgmw-x865-hf9x/GHSA-hgmw-x865-hf9x.json refers to "arabic-prawn", which is not a valid gem name according to RubyGems:

> curl https://rubygems.org/api/v1/gems/arabic-prawn.json
This rubygem could not be found.%     
# Gem install will similarly fail 

But using the correct case works:

> curl https://rubygems.org/api/v1/gems/Arabic-Prawn.json
{"name":"Arabic-Prawn","downloads":5615,"version":"0.0.1","version_created_at":"2010-02-27T22:12:06.572Z","version_downloads":5615,"platform":"ruby","authors":"Dynamix Solutions","info":"Allows printing arabic to PDFs generated by prawn","licenses":null,"metadata":{},"yanked":false,"sha":"cc7d1d8259146a465c379b0aca3db2b331e992bb19694722f48159ebe294cf6b","project_uri":"https://rubygems.org/gems/Arabic-Prawn","gem_uri":"https://rubygems.org/gems/Arabic-Prawn-0.0.1.gem","homepage_uri":null,"wiki_uri":null,"documentation_uri":"https://www.rubydoc.info/gems/Arabic-Prawn/0.0.1","mailing_list_uri":null,"source_code_uri":null,"bug_tracker_uri":null,"changelog_uri":null,"funding_uri":null,"dependencies":{"development":[],"runtime":[]}}

Another instance of this is e.g. redcloth.

I came across the guava vulnerability GHSA-5mg8-w23w-74h3 for which GHSA declares the affected version range as <= 29.0.

In OSV however, this is represented as:

"ranges": [
    {
        "type": "ECOSYSTEM",
        "events": [
            {
                "introduced": "0"
            }
        ]
    }
],
"database_specific": {
    "last_known_affected_version_range": "<= 29.0"
}

Given the constraint <= 29.0, I would've expected the following:

"ranges": [
    {
        "type": "ECOSYSTEM",
        "events": [
            {
                "introduced": "0"
            },
            {
                "last_affected": "29.0"
            }
        ]
    }
]

The current situation makes automated processing unnecessarily hard. If I rely on the ECOSYSTEM range, I'll trigger lots of false positives due to it indicating a >0 constraint. database_specific is not intended to influence vulnerability evaluation according to the spec. This is also visible when inspecting the (auto-generated) Affected versions section on OSV's website: https://osv.dev/vulnerability/GHSA-5mg8-w23w-74h3

At the moment, there are about 1990 advisories affected by this:

$ rg -l '"last_known_affected_version_range"' advisory-database | wc -l
1990

google/osv.dev#474 (comment) already hinted that GHSA currently does not support the limit or last_affected events. Is it planned to be addressed anytime soon?