[vulndb] internal/report: move some functionality from vulnreport to report.New
10 views
Skip to first unread message
Tatiana Bradley (Gerrit)
Jun 26, 2024, 4:24:34 PM6/26/24
to goph...@pubsubhelper.golang.org, golang-co...@googlegroups.com
Tatiana Bradley has uploaded the change for review![]( "Open in Gerrit")
Commit message
internal/report: move some functionality from vulnreport to report.New
Change-Id: Ie533f3ef5642f0866c91c28010482eec1d844739
Change diff
diff --git a/cmd/vulnreport/creator.go b/cmd/vulnreport/creator.go
index 08e0a84..b9dce34 100644
--- a/cmd/vulnreport/creator.go
+++ b/cmd/vulnreport/creator.go
@@ -200,13 +200,6 @@
case meta.excluded != "":
// nothing
case meta.reviewStatus == report.Unreviewed:
- r.Description = ""
- // Package-level data is often wrong/incomplete, which could lead
- // to false negatives, so remove it for unreviewed reports.
- // TODO(tatianabradley): instead of removing all package-level data,
- // consider doing a surface-level check such as making sure packages are
- // known to pkgsite, but skip symbol-level checks.
- r.removePackages()
r.removeUnreachableRefs()
default:
// Regular, full-length reports.
@@ -218,12 +211,6 @@
return r, nil
}
-func (r *yamlReport) removePackages() {
- for _, m := range r.Report.Modules {
- m.Packages = nil
- }
-}
-
func (r *yamlReport) removeUnreachableRefs() {
r.Report.References = slices.DeleteFunc(r.Report.References, func(r *report.Reference) bool {
resp, err := http.Head(r.URL)
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2020-9283.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2020-9283.txtar
index da08e98..8f99405 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2020-9283.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2020-9283.txtar
@@ -10,11 +10,6 @@
- module: golang.org/x/crypto
vulnerable_at: 0.24.0
summary: CVE-2020-9283 in golang.org/x/crypto
-description: |-
- golang.org/x/crypto before v0.0.0-20200220183623-bac4c82f6975 for Go allows a
- panic during signature verification in the golang.org/x/crypto/ssh package. A
- client can attack an SSH server that accepts public keys. Also, a server can
- attack any SSH client.
cves:
- CVE-2020-9283
references:
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2021-27919.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2021-27919.txtar
index a1e8786..02d69fb 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2021-27919.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2021-27919.txtar
@@ -11,10 +11,6 @@
packages:
- package: archive/zip
summary: CVE-2021-27919 in archive/zip
-description: |-
- archive/zip in Go 1.16.x before 1.16.1 allows attackers to cause a denial of
- service (panic) upon attempted use of the Reader.Open API for a ZIP archive in
- which ../ occurs at the beginning of any filename.
cves:
- CVE-2021-27919
references:
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2021-3115.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2021-3115.txtar
index b13fb0f..27bb975 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2021-3115.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2021-3115.txtar
@@ -11,11 +11,6 @@
packages:
- package: cmd/go
summary: CVE-2021-3115 in cmd
-description: |-
- Go before 1.14.14 and 1.15.x before 1.15.7 on Windows is vulnerable to Command
- Injection and remote code execution when using the "go get" command to fetch
- modules that make use of cgo (for example, cgo can execute a gcc program from an
- untrusted download).
cves:
- CVE-2021-3115
references:
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2022-39213.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2022-39213.txtar
index c597111..af55f8e 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2022-39213.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2022-39213.txtar
@@ -13,20 +13,6 @@
- fixed: 0.4.0
vulnerable_at: 0.3.0
summary: Out-of-bounds Read in go-cvss in github.com/pandatix/go-cvss
-description: |-
- go-cvss is a Go module to manipulate Common Vulnerability Scoring System (CVSS).
- In affected versions when a full CVSS v2.0 vector string is parsed using
- `ParseVector`, an Out-of-Bounds Read is possible due to a lack of tests. The Go
- module will then panic. The problem is patched in tag `v0.4.0`, by the commit
- `d9d478ff0c13b8b09ace030db9262f3c2fe031f4`. Users are advised to upgrade. Users
- unable to upgrade may avoid this issue by parsing only CVSS v2.0 vector strings
- that do not have all attributes defined (e.g.
- `AV:N/AC:L/Au:N/C:P/I:P/A:C/E:U/RL:OF/RC:C/CDP:MH/TD:H/CR:M/IR:M/AR:M`). As
- stated in
- [SECURITY.md](https://github.com/pandatix/go-cvss/blob/master/SECURITY.md), the
- CPE v2.3 to refer to this Go module is
- `cpe:2.3:a:pandatix:go_cvss:*:*:*:*:*:*:*:*`. The entry has already been
- requested to the NVD CPE dictionary.
cves:
- CVE-2022-39213
references:
@@ -34,9 +20,6 @@
- fix: https://github.com/pandatix/go-cvss/commit/d9d478ff0c13b8b09ace030db9262f3c2fe031f4
- web: https://github.com/pandatix/go-cvss/blob/master/SECURITY.md
- web: https://github.com/pandatix/go-cvss/security/advisories/GHSA-xhmf-mmv2-4hhx
-notes:
- - lint: 'description: possible markdown formatting (found [SECURITY.md](https://github.com/pandatix/go-cvss/blob/master/SECURITY.md))'
- - lint: 'description: possible markdown formatting (found `ParseVector`)'
source:
id: CVE-2022-39213
created: 1999-01-01T00:00:00Z
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2023-29407.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2023-29407.txtar
index d8351af..3213e03 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2023-29407.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2023-29407.txtar
@@ -11,19 +11,9 @@
versions:
- fixed: 0.10.0
vulnerable_at: 0.9.0
- packages:
- - package: golang.org/x/image/tiff
- symbols:
- - newDecoder
- - Decode
- - DecodeConfig
summary: |-
Excessive CPU consumption when decoding 0-height images in
golang.org/x/image/tiff
-description: |-
- A maliciously-crafted image can cause excessive CPU consumption in decoding. A
- tiled image with a height of 0 and a very large width can cause excessive CPU
- consumption, despite the image size (width * height) appearing to be zero.
credits:
- Philippe Antoine (Catena cyber)
references:
@@ -37,6 +27,8 @@
cve_metadata:
id: CVE-2023-29407
cwe: 'CWE-834: Excessive Iteration'
+notes:
+ - lint: 'description: missing (reports with Go CVEs must have a description)'
source:
id: CVE-2023-29407
created: 1999-01-01T00:00:00Z
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2023-44378.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2023-44378.txtar
index 724d3b5..6b6585e 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2023-44378.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2023-44378.txtar
@@ -14,15 +14,6 @@
summary: |-
gnark vulnerable to unsoundness in variable comparison/non-unique binary
decomposition in github.com/consensys/gnark
-description: |-
- gnark is a zk-SNARK library that offers a high-level API to design circuits.
- Prior to version 0.9.0, for some in-circuit values, it is possible to construct
- two valid decomposition to bits. In addition to the canonical decomposition of
- `a`, for small values there exists a second decomposition for `a+r` (where `r`
- is the modulus the values are being reduced by). The second decomposition was
- possible due to overflowing the field where the values are defined. Upgrading to
- version 0.9.0 should fix the issue without needing to change the calls to value
- comparison methods.
cves:
- CVE-2023-44378
references:
@@ -30,8 +21,6 @@
- fix: https://github.com/Consensys/gnark/commit/59a4087261a6c73f13e80d695c17b398c3d0934f
- report: https://github.com/zkopru-network/zkopru/issues/116
- web: https://github.com/Consensys/gnark/security/advisories/GHSA-498w-5j49-vqjg
-notes:
- - lint: 'description: possible markdown formatting (found `a`, for small values there exists a second decomposition for `a+r` (where `r`)'
source:
id: CVE-2023-44378
created: 1999-01-01T00:00:00Z
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2023-45141.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2023-45141.txtar
index 6e6d488..914d1aa 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2023-45141.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2023-45141.txtar
@@ -14,17 +14,6 @@
- fixed: 2.50.0
vulnerable_at: 2.49.2
summary: CSRF Token Validation Vulnerability in fiber in github.com/gofiber/fiber
-description: |-
- Fiber is an express inspired web framework written in Go. A Cross-Site Request
- Forgery (CSRF) vulnerability has been identified in the application, which
- allows an attacker to obtain tokens and forge malicious requests on behalf of a
- user. This can lead to unauthorized actions being taken on the user's behalf,
- potentially compromising the security and integrity of the application. The
- vulnerability is caused by improper validation and enforcement of CSRF tokens
- within the application. This vulnerability has been addressed in version 2.50.0
- and users are advised to upgrade. Users should take additional security measures
- like captchas or Two-Factor Authentication (2FA) and set Session cookies with
- SameSite=Lax or SameSite=Secure, and the Secure and HttpOnly attributes.
cves:
- CVE-2023-45141
references:
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2023-45283.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2023-45283.txtar
index 1f8bfc6..6ba147c 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2023-45283.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2023-45283.txtar
@@ -70,21 +70,6 @@
- Walk
- WalkDir
summary: Insecure parsing of Windows paths with a \??\ prefix in path/filepath
-description: |-
- The filepath package does not recognize paths with a \??\ prefix as special. On
- Windows, a path beginning with \??\ is a Root Local Device path equivalent to a
- path beginning with \\?\. Paths with a \??\ prefix may be used to access
- arbitrary locations on the system. For example, the path \??\c:\x is equivalent
- to the more common path c:\x. Before fix, Clean could convert a rooted path such
- as \a\..\??\b into the root local device path \??\b. Clean will now convert this
- to .\??\b. Similarly, Join(\, ??, b) could convert a seemingly innocent sequence
- of path elements into the root local device path \??\b. Join will now convert
- this to \.\??\b. In addition, with fix, IsAbs now correctly reports paths
- beginning with \??\ as absolute, and VolumeName correctly reports the \??\
- prefix as a volume name. UPDATE: Go 1.20.11 and Go 1.21.4 inadvertently changed
- the definition of the volume name in Windows paths starting with \?, resulting
- in filepath.Clean(\?\c:) returning \?\c: rather than \?\c:\ (among other
- effects). The previous behavior has been restored.
references:
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2023-45283
- fix: https://go.dev/cl/540277
@@ -101,8 +86,7 @@
notes:
- fix: 'module merge error: could not merge versions of module std: range events must be in strictly ascending order (found 1.20.11>=1.20.11)'
- fix: 'std: could not add vulnerable_at: not implemented for std/cmd'
- - fix: 'std: could not add vulnerable_at: not implemented for std/cmd'
- - fix: 'std: could not add vulnerable_at: not implemented for std/cmd'
+ - lint: 'description: missing (reports with Go CVEs must have a description)'
- lint: 'modules[0] "std": packages[0] "internal/safefilepath": at least one of vulnerable_at and skip_fix must be set'
- lint: 'modules[1] "std": packages[0] "path/filepath": at least one of vulnerable_at and skip_fix must be set'
- lint: 'modules[2] "std": packages[0] "path/filepath": at least one of vulnerable_at and skip_fix must be set'
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2023-45285.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2023-45285.txtar
index e0881b0..d369f03 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2023-45285.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2023-45285.txtar
@@ -15,12 +15,6 @@
packages:
- package: cmd/go
summary: Command 'go get' may unexpectedly fallback to insecure git in cmd/go
-description: |-
- Using go get to fetch a module with the ".git" suffix may unexpectedly fallback
- to the insecure "git://" protocol if the module is unavailable via the secure
- "https://" and "git+ssh://" protocols, even if GOINSECURE is not set for said
- module. This only affects users who are not using the module proxy and are
- fetching modules directly (i.e. GOPROXY=off).
credits:
- David Leadbeater
references:
@@ -34,6 +28,7 @@
cwe: 'CWE-636: Not Failing Securely (''Failing Open'')'
notes:
- fix: 'cmd: could not add vulnerable_at: not implemented for std/cmd'
+ - lint: 'description: missing (reports with Go CVEs must have a description)'
- lint: 'modules[0] "cmd": packages[0] "cmd/go": at least one of vulnerable_at and skip_fix must be set'
- lint: 'references[0] "https://nvd.nist.gov/vuln/detail/CVE-2023-45285": "https://nvd.nist.gov/vuln/detail/CVE-2023-45285": advisory reference must not be set for first-party issues'
- lint: 'references[4] "https://lists.fedoraproject.org/archives/list/package-...@lists.fedoraproject.org/message/UIU6HOGV6RRIKWM57LOXQA75BGZSIH6G/": "https://lists.fedoraproject.org/archives/list/package-...@lists.fedoraproject.org/message/UIU6HOGV6RRIKWM57LOXQA75BGZSIH6G/": web reference must match regex "https://groups.google.com/g/golang-(announce|dev|nuts)/c/([^/]+)"'
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2023-45286.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2023-45286.txtar
index 4619858..8f4cd61 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2023-45286.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2023-45286.txtar
@@ -14,31 +14,7 @@
- introduced: 2.10.0
- fixed: 2.11.0
vulnerable_at: 2.10.0
- packages:
- - package: github.com/go-resty/resty/v2
- symbols:
- - handleRequestBody
- - Backoff
- - Request.Delete
- - Request.Execute
- - Request.Get
- - Request.Head
- - Request.Options
- - Request.Patch
- - Request.Post
- - Request.Put
- - Request.Send
summary: HTTP request body disclosure in github.com/go-resty/resty/v2
-description: |-
- A race condition in go-resty can result in HTTP request body disclosure across
- requests. This condition can be triggered by calling sync.Pool.Put with the same
- *bytes.Buffer more than once, when request retries are enabled and a retry
- occurs. The call to sync.Pool.Get will then return a bytes.Buffer that hasn't
- had bytes.Buffer.Reset called on it. This dirty buffer will contain the HTTP
- request body from an unrelated request, and go-resty will append the current
- HTTP request body to it, sending two bodies in one request. The sync.Pool in
- question is defined at package level scope, so a completely unrelated server
- could receive the request body.
credits:
- Logan Attwood (@lattwood)
references:
@@ -50,6 +26,8 @@
cve_metadata:
id: CVE-2023-45286
cwe: 'CWE-200: Exposure of Sensitive Information to an Unauthorized Actor'
+notes:
+ - lint: 'description: missing (reports with Go CVEs must have a description)'
source:
id: CVE-2023-45286
created: 1999-01-01T00:00:00Z
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2024-2056.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2024-2056.txtar
index e1b9635..7de341f 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2024-2056.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2024-2056.txtar
@@ -12,14 +12,6 @@
- cve_version_range: 'affected at 4.50 (default: unaffected)'
vulnerable_at: 1.1.0
summary: Artica Proxy Loopback Services Remotely Accessible Unauthenticated in github.com/gvalkov/tailon
-description: |-
- Services that are running and bound to the loopback interface on the Artica
- Proxy are accessible through the proxy service. In particular, the "tailon"
- service is running, running as the root user, is bound to the loopback
- interface, and is listening on TCP port 7050. Security issues associated with
- exposing this network service are documented at gvalkov's 'tailon' GitHub repo.
- Using the tailon service, the contents of any file on the Artica Proxy can be
- viewed.
cves:
- CVE-2024-2056
credits:
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2024-3094.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2024-3094.txtar
index 2659d87..10ee4f7 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2024-3094.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2024-3094.txtar
@@ -13,14 +13,6 @@
- cve_version_range: 'affected at 5.6.1 (default: unaffected)'
vulnerable_at: 0.0.0-20240403045847-8ae5b706fb2c
summary: 'Xz: malicious code in distributed source in github.com/amlweems/xzbot'
-description: |-
- Malicious code was discovered in the upstream tarballs of xz, starting with
- version 5.6.0. Through a series of complex obfuscations, the liblzma build
- process extracts a prebuilt object file from a disguised test file existing in
- the source code, which is then used to modify specific functions in the liblzma
- code. This results in a modified liblzma library that can be used by any
- software linked against this library, intercepting and modifying the data
- interaction with this library.
cves:
- CVE-2024-3094
credits:
diff --git a/internal/cve5/testdata/cve/TestToReport/CVE-2024-33522.txtar b/internal/cve5/testdata/cve/TestToReport/CVE-2024-33522.txtar
index 07e0951..083e191 100644
--- a/internal/cve5/testdata/cve/TestToReport/CVE-2024-33522.txtar
+++ b/internal/cve5/testdata/cve/TestToReport/CVE-2024-33522.txtar
@@ -29,14 +29,6 @@
- fixed: 3.19.0-2.0
vulnerable_at: 3.18.2-networking-calico+incompatible
summary: Privilege escalation in Calico CNI install binary in github.com/projectcalico/calico
-description: |-
- In vulnerable versions of Calico (v3.27.2 and below), Calico Enterprise
- (v3.19.0-1, v3.18.1, v3.17.3 and below), and Calico Cloud (v19.2.0 and below),
- an attacker who has local access to the Kubernetes node, can escalate their
- privileges by exploiting a vulnerability in the Calico CNI install binary. The
- issue arises from an incorrect SUID (Set User ID) bit configuration in the
- binary, combined with the ability to control the input binary, allowing an
- attacker to execute an arbitrary binary with elevated privileges.
cves:
- CVE-2024-33522
credits:
diff --git a/internal/genericosv/testdata/osv/GHSA-m99c-q26r-m7m7.json b/internal/genericosv/testdata/osv/GHSA-m99c-q26r-m7m7.json
new file mode 100644
index 0000000..889db2f
--- /dev/null
+++ b/internal/genericosv/testdata/osv/GHSA-m99c-q26r-m7m7.json
@@ -0,0 +1,77 @@
+{
+ "schema_version": "1.4.0",
+ "id": "GHSA-m99c-q26r-m7m7",
+ "modified": "2024-06-10T20:09:07Z",
+ "published": "2024-04-17T17:37:23Z",
+ "aliases": [
+
+ ],
+ "summary": "Evmos vulnerable to unauthorized account creation with vesting module",
+ "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nUsing the vesting module, a malicious attacker can create a new vesting account at a given\naddress, before a contract is created on that address.\n\nAddresses of smart contracts deployed to the EVM are deterministic. Therefore, it would be possible for an attacker to front-run a contract creation and create a vesting account at that address. \nWhen an address has been initialized without any contract code deployed to it, it will not be possible to upload any afterwards. In the described attack, this would mean that a malicious actor could prevent smart contracts from being deployed correctly.\n\nIn order to remediate this, an alternative user flow is being implemented for the vesting module:\n- only the account receiving the vesting funds will be able to create such an account by calling the `CreateClawbackVestingAccount` method and defining a funder address\n- vesting and lockup periods can then be created by that funder address using `FundClawbackAccount`\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n### References\n_Are there any links users can visit to find out more?_\n",
+ "severity": [
+
+ ],
+ "affected": [
+ {
+ "package": {
+ "ecosystem": "Go",
+ "name": "github.com/evmos/evmos/v13/x/vesting"
+ },
+ "ranges": [
+ {
+ "type": "ECOSYSTEM",
+ "events": [
+ {
+ "introduced": "0"
+ },
+ {
+ "last_affected": "13.0.2"
+ }
+ ]
+ }
+ ]
+ },
+ {
+ "package": {
+ "ecosystem": "Go",
+ "name": "github.com/evmos/evmos/v13"
+ },
+ "ranges": [
+ {
+ "type": "ECOSYSTEM",
+ "events": [
+ {
+ "introduced": "0"
+ },
+ {
+ "last_affected": "13.0.2"
+ }
+ ]
+ }
+ ]
+ }
+ ],
+ "references": [
+ {
+ "type": "WEB",
+ "url": "https://github.com/evmos/evmos/security/advisories/GHSA-m99c-q26r-m7m7"
+ },
+ {
+ "type": "PACKAGE",
+ "url": "https://github.com/evmos/evmos"
+ },
+ {
+ "type": "WEB",
+ "url": "https://pkg.go.dev/vuln/GO-2024-2731"
+ }
+ ],
+ "database_specific": {
+ "cwe_ids": [
+
+ ],
+ "severity": "MODERATE",
+ "github_reviewed": true,
+ "github_reviewed_at": "2024-04-17T17:37:23Z",
+ "nvd_published_at": null
+ }
+}
\ No newline at end of file
diff --git a/internal/genericosv/testdata/proxy/TestToReport/GHSA-m99c-q26r-m7m7.json b/internal/genericosv/testdata/proxy/TestToReport/GHSA-m99c-q26r-m7m7.json
new file mode 100644
index 0000000..3afda46
--- /dev/null
+++ b/internal/genericosv/testdata/proxy/TestToReport/GHSA-m99c-q26r-m7m7.json
@@ -0,0 +1,60 @@
+{
+ "github.com/evmos/evmos/@latest": {
+ "body": "{\"Version\":\"v1.1.3\",\"Time\":\"2022-07-13T15:43:34Z\"}",
+ "status_code": 200
+ },
+ "github.com/evmos/evmos/v10/@latest": {
+ "body": "{\"Version\":\"v10.0.1\",\"Time\":\"2023-01-03T20:26:16Z\",\"Origin\":{\"VCS\":\"git\",\"URL\":\"https://github.com/evmos/evmos\",\"Ref\":\"refs/tags/v10.0.1\",\"Hash\":\"f2180eb9bef3e957a0a327c4927dedfc93f9c80a\"}}",
+ "status_code": 200
+ },
+ "github.com/evmos/evmos/v11/@latest": {
+ "body": "{\"Version\":\"v11.0.2\",\"Time\":\"2023-02-10T16:47:56Z\",\"Origin\":{\"VCS\":\"git\",\"URL\":\"https://github.com/evmos/evmos\",\"Ref\":\"refs/tags/v11.0.2\",\"Hash\":\"8eeeac7ae42a5b2695fea7f56868f3c6e9bc2378\"}}",
+ "status_code": 200
+ },
+ "github.com/evmos/evmos/v12/@latest": {
+ "body": "{\"Version\":\"v12.1.6\",\"Time\":\"2023-07-04T13:24:07Z\",\"Origin\":{\"VCS\":\"git\",\"URL\":\"https://github.com/evmos/evmos\",\"Ref\":\"refs/tags/v12.1.6\",\"Hash\":\"b43ee16a10b61e06431ef5b3ae3f6b75015e42e0\"}}",
+ "status_code": 200
+ },
+ "github.com/evmos/evmos/v13/@latest": {
+ "body": "{\"Version\":\"v13.0.2\",\"Time\":\"2023-07-05T11:42:45Z\",\"Origin\":{\"VCS\":\"git\",\"URL\":\"https://github.com/evmos/evmos\",\"Ref\":\"refs/tags/v13.0.2\",\"Hash\":\"23322b5a38e89c574282e8b31f8576157c1c5221\"}}",
+ "status_code": 200
+ },
+ "github.com/evmos/evmos/v13/x/@latest": {
+ "status_code": 404
+ },
+ "github.com/evmos/evmos/v13/x/vesting/@latest": {
+ "status_code": 404
+ },
+ "github.com/evmos/evmos/v2/@latest": {
+ "body": "{\"Version\":\"v2.0.2\",\"Time\":\"2022-07-13T14:33:04Z\",\"Origin\":{\"VCS\":\"git\",\"URL\":\"https://github.com/evmos/evmos\",\"Ref\":\"refs/tags/v2.0.2\",\"Hash\":\"dca9da1813b6173e5bc0ab779601793aef1f42ce\"}}",
+ "status_code": 200
+ },
+ "github.com/evmos/evmos/v3/@latest": {
+ "body": "{\"Version\":\"v3.0.3\",\"Time\":\"2022-07-13T14:33:19Z\",\"Origin\":{\"VCS\":\"git\",\"URL\":\"https://github.com/evmos/evmos\",\"Ref\":\"refs/tags/v3.0.3\",\"Hash\":\"552555b2ea3c08a1c8b57b53f151436775ed61b7\"}}",
+ "status_code": 200
+ },
+ "github.com/evmos/evmos/v4/@latest": {
+ "body": "{\"Version\":\"v4.0.2\",\"Time\":\"2022-07-13T14:33:15Z\"}",
+ "status_code": 200
+ },
+ "github.com/evmos/evmos/v5/@latest": {
+ "body": "{\"Version\":\"v5.0.1\",\"Time\":\"2022-07-13T14:33:24Z\"}",
+ "status_code": 200
+ },
+ "github.com/evmos/evmos/v6/@latest": {
+ "body": "{\"Version\":\"v6.0.4\",\"Time\":\"2022-08-03T15:16:21Z\",\"Origin\":{\"VCS\":\"git\",\"URL\":\"https://github.com/evmos/evmos\",\"Ref\":\"refs/tags/v6.0.4\",\"Hash\":\"6ce34e5c13e83e559628e625df53f53dfca57d06\"}}",
+ "status_code": 200
+ },
+ "github.com/evmos/evmos/v7/@latest": {
+ "body": "{\"Version\":\"v7.0.0\",\"Time\":\"2022-08-04T19:51:07Z\",\"Origin\":{\"VCS\":\"git\",\"URL\":\"https://github.com/evmos/evmos\",\"Ref\":\"refs/tags/v7.0.0\",\"Hash\":\"a1c4b7af4cecd908d703a00bbb808c66ea61ab8a\"}}",
+ "status_code": 200
+ },
+ "github.com/evmos/evmos/v8/@latest": {
+ "body": "{\"Version\":\"v8.2.3\",\"Time\":\"2022-10-16T01:33:17Z\",\"Origin\":{\"VCS\":\"git\",\"URL\":\"https://github.com/evmos/evmos\",\"Ref\":\"refs/tags/v8.2.3\",\"Hash\":\"1ca54a4e1c0812933960a9c943a7ab6c4901210d\"}}",
+ "status_code": 200
+ },
+ "github.com/evmos/evmos/v9/@latest": {
+ "body": "{\"Version\":\"v9.1.0\",\"Time\":\"2022-10-25T20:04:49Z\",\"Origin\":{\"VCS\":\"git\",\"URL\":\"https://github.com/evmos/evmos\",\"Ref\":\"refs/tags/v9.1.0\",\"Hash\":\"80c38f659a65a983b221e2a568c6172b8ac3bffc\"}}",
+ "status_code": 200
+ }
+}
\ No newline at end of file
diff --git a/internal/genericosv/testdata/yaml/GHSA-28r2-q6m8-9hpx.yaml b/internal/genericosv/testdata/yaml/GHSA-28r2-q6m8-9hpx.yaml
index 2db61e5..0b1f84b 100644
--- a/internal/genericosv/testdata/yaml/GHSA-28r2-q6m8-9hpx.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-28r2-q6m8-9hpx.yaml
@@ -20,10 +20,6 @@
summary: |-
HashiCorp go-getter unsafe downloads could lead to asymmetric resource
exhaustion in github.com/hashicorp/go-getter
-description: |-
- HashiCorp go-getter through 2.0.2 does not safely perform downloads. Asymmetric
- resource exhaustion could occur when go-getter processed malicious HTTP
- responses.
cves:
- CVE-2022-30323
ghsas:
diff --git a/internal/genericosv/testdata/yaml/GHSA-33m6-q9v5-62r7.yaml b/internal/genericosv/testdata/yaml/GHSA-33m6-q9v5-62r7.yaml
index bd07845..abb8b09 100644
--- a/internal/genericosv/testdata/yaml/GHSA-33m6-q9v5-62r7.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-33m6-q9v5-62r7.yaml
@@ -12,38 +12,6 @@
- introduced: 1.2.1-0.20180103161547-0ef6afb2f6cd
- fixed: 1.2.1-0.20180404165556-75cca531ea76
summary: github.com/satori/go.uuid has Predictable SIF UUID Identifiers
-description: |-
- ### Impact
-
- The siftool new command produces predictable UUID identifiers due to insecure
- randomness in the version of the `github.com/satori/go.uuid` module used as a
- dependency.
-
- ### Patches
-
- A patch is available in version >= v1.2.1-0.20180404165556-75cca531ea76 of the
- module. Users are encouraged to upgrade.
-
- Fixed by https://github.com/hpcng/sif/pull/90
-
- ### Workarounds
-
- Users passing CreateInfo struct should ensure the ID field is generated using a
- version of github.com/satori/go.uuid that is not vulnerable to this issue.
- Unfortunately, the latest tagged release is vulnerable to this issue. One way to
- obtain a non-vulnerable version is:
-
- `go get -u github.com/satori/go....@v1.2.1-0.20180404165556-75cca531ea76`
-
- ### References
-
- https://github.com/satori/go.uuid/issues/73
-
- ### For more information
-
- If you have any questions or comments about this advisory:
-
- Open an issue in https://github.com/hpcng/sif/issues
cves:
- CVE-2021-3538
ghsas:
@@ -58,8 +26,6 @@
- web: https://snyk.io/vuln/SNYK-GOLANG-GITHUBCOMSATORIGOUUID-72488
notes:
- fix: 'github.com/satori/go.uuid: could not add vulnerable_at: could not find tagged version between introduced and fixed'
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found `github.com/satori/go.uuid`)'
source:
id: GHSA-33m6-q9v5-62r7
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-3cqf-953p-h5cp.yaml b/internal/genericosv/testdata/yaml/GHSA-3cqf-953p-h5cp.yaml
index 3743d55..316dc65 100644
--- a/internal/genericosv/testdata/yaml/GHSA-3cqf-953p-h5cp.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-3cqf-953p-h5cp.yaml
@@ -13,48 +13,6 @@
- fixed: 2.11.3
vulnerable_at: 2.11.2
summary: Argo-cd authenticated users can enumerate clusters by name in github.com/argoproj/argo-cd
-description: |-
- ### Impact It’s possible for authenticated users to enumerate clusters by name
- by inspecting error messages:
-
- ``` $ curl -k 'https://localhost:8080/api/v1/clusters/in-cluster?id.type=name'
- -H "Authorization: Bearer $token" {"error":"permission denied: clusters, get, ,
- sub: alice, iat: 2022-11-04T20:25:44Z","code":7,"message":"permission denied:
- clusters, get, , sub: alice, iat: 2022-11-04T20:25:44Z"}⏎
-
- $ curl -k 'https://localhost:8080/api/v1/clusters/does-not-exist?id.type=name'
- -H "Authorizati on: Bearer $token" {"error":"permission
- denied","code":7,"message":"permission denied"} ```
-
- It’s also possible to enumerate the names of projects with project-scoped
- clusters if you know the names of the clusters. ``` curl -k
- 'https://localhost:8080/api/v1/clusters/in-cluster-project?id.type=name' -H
- "Authorization: Bearer $token" {"error":"permission denied: clusters, get,
- default/, sub: alice, iat: 2022-11-04T20:25:44Z","code":7,"message":"permission
- denied: clusters, get, default/, sub: alice, iat: 2022-11-04T20:25:44Z"}
-
- curl -k 'https://localhost:8080/api/v1/clusters/does-not-exist?id.type=name' -H
- "Authorization: Bearer $token" {"error":"permission
- denied","code":7,"message":"permission denied"} ```
-
- ### Patches A patch for this vulnerability has been released in the following
- Argo CD versions:
-
- v2.11.3 v2.10.12 v2.9.17
-
- ### For more information If you have any questions or comments about this
- advisory:
-
- Open an issue in [the Argo CD issue
- tracker](https://github.com/argoproj/argo-cd/issues) or
- [discussions](https://github.com/argoproj/argo-cd/discussions) Join us on
- [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd
-
- Credits This vulnerability was found & reported by @crenshaw-dev (Michael
- Crenshaw)
-
- The Argo team would like to thank these contributors for their responsible
- disclosure and constructive communications during the resolve of this issue
cves:
- CVE-2024-36106
ghsas:
@@ -63,10 +21,6 @@
- advisory: https://github.com/argoproj/argo-cd/security/advisories/GHSA-3cqf-953p-h5cp
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2024-36106
- fix: https://github.com/argoproj/argo-cd/commit/c2647055c261a550e5da075793260f6524e65ad9
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [discussions](https://github.com/argoproj/argo-cd/discussions))'
- - lint: 'description: possible markdown formatting (found ```)'
source:
id: GHSA-3cqf-953p-h5cp
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-3hwm-922r-47hw.yaml b/internal/genericosv/testdata/yaml/GHSA-3hwm-922r-47hw.yaml
index 47b2a6c..e875e45 100644
--- a/internal/genericosv/testdata/yaml/GHSA-3hwm-922r-47hw.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-3hwm-922r-47hw.yaml
@@ -5,16 +5,6 @@
- fixed: 0.23.0
vulnerable_at: 0.20.1
summary: Stud42 vulnerable to denial of service in atomys.codes/stud42
-description: |-
- A security vulnerability has been identified in the GraphQL parser used by the
- API of s42.app. An attacker can overload the parser and cause the API pod to
- crash. With a bit of threading, the attacker can bring down the entire API,
- resulting in an unhealthy stream. This vulnerability can be exploited by sending
- a specially crafted request to the API with a large payload.
-
- An attacker can exploit this vulnerability to cause a denial of service (DoS)
- attack on the s42.app API, resulting in unavailability of the API for legitimate
- users.
ghsas:
- GHSA-3hwm-922r-47hw
references:
diff --git a/internal/genericosv/testdata/yaml/GHSA-3wq5-3f56-v5xc.yaml b/internal/genericosv/testdata/yaml/GHSA-3wq5-3f56-v5xc.yaml
index da374cd..e155d7f 100644
--- a/internal/genericosv/testdata/yaml/GHSA-3wq5-3f56-v5xc.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-3wq5-3f56-v5xc.yaml
@@ -16,10 +16,6 @@
- introduced: 6.3.0
vulnerable_at: 6.7.2
summary: Mattermost vulnerable to information disclosure in github.com/mattermost/mattermost-server
-description: |-
- Mattermost allows an attacker to request a preview of an existing message when
- creating a new message via the createPost API call, disclosing the contents of
- the linked message.
cves:
- CVE-2023-1777
ghsas:
diff --git a/internal/genericosv/testdata/yaml/GHSA-54q4-74p3-mgcw.yaml b/internal/genericosv/testdata/yaml/GHSA-54q4-74p3-mgcw.yaml
index 5a250eb..9ec180b 100644
--- a/internal/genericosv/testdata/yaml/GHSA-54q4-74p3-mgcw.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-54q4-74p3-mgcw.yaml
@@ -7,9 +7,6 @@
- last_affected: 4.0.2
vulnerable_at: 1.1.0
summary: rttys SQL Injection vulnerability in github.com/zhaojh329/rttys
-description: |-
- SQL Injection vulnerability in rttys versions 4.0.0, 4.0.1, and 4.0.2 in api.go,
- allows attackers to execute arbitrary code.
cves:
- CVE-2022-38867
ghsas:
diff --git a/internal/genericosv/testdata/yaml/GHSA-5m6c-jp6f-2vcv.yaml b/internal/genericosv/testdata/yaml/GHSA-5m6c-jp6f-2vcv.yaml
index 176b313..63aca8a 100644
--- a/internal/genericosv/testdata/yaml/GHSA-5m6c-jp6f-2vcv.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-5m6c-jp6f-2vcv.yaml
@@ -6,12 +6,6 @@
- fixed: 6.0.0
vulnerable_at: 3.2.0+incompatible
summary: Open Redirect in OAuth2 Proxy in github.com/oauth2-proxy/oauth2-proxy
-description: |-
- ### Impact As users can provide a redirect address for the proxy to send the
- authenticated user to at the end of the authentication flow. This is expected to
- be the original URL that the user was trying to access. This redirect URL is
- checked within the proxy and validated before redirecting the user to prevent
- malicious actors providing redirects to potentially harmful sites.
cves:
- CVE-2020-4037
ghsas:
@@ -21,8 +15,6 @@
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2020-4037
- fix: https://github.com/oauth2-proxy/oauth2-proxy/commit/ee5662e0f5001d76ec76562bb605abbd07c266a2
- web: https://github.com/oauth2-proxy/oauth2-proxy/releases/tag/v6.0.0
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
source:
id: GHSA-5m6c-jp6f-2vcv
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-627p-rr78-99rj.yaml b/internal/genericosv/testdata/yaml/GHSA-627p-rr78-99rj.yaml
index 2fa3462..12895b2 100644
--- a/internal/genericosv/testdata/yaml/GHSA-627p-rr78-99rj.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-627p-rr78-99rj.yaml
@@ -17,48 +17,6 @@
summary: |-
GitLab auth uses full name instead of username as user ID, allowing
impersonation in github.com/concourse/concourse
-description: |-
- ### Impact
-
- Installations which use the GitLab auth connector are vulnerable to identity
- spoofing by way of configuring a GitLab account with the same full name as
- another GitLab user who is granted access to a Concourse team by having their
- full name listed under `users` in the team configuration or given to the
- `--gitlab-user` flag.
-
- See the [GitLab auth docs](https://concourse-ci.org/gitlab-auth.html) for
- details.
-
- Concourse installations which do not configure the GitLab auth connector are not
- affected.
-
- ### Patches
-
- Concourse [v6.3.1](https://github.com/concourse/concourse/releases/tag/v6.3.1)
- and [v6.4.1](https://github.com/concourse/concourse/releases/tag/v6.4.1) were
- both released with a fix on August 4th, 2020.
-
- Both versions change the GitLab connector to use the username, rather than the
- full name. This was always the intent, and the previous behavior was originally
- reported as a bug (concourse/dex#7) prior to being reported as a security issue.
-
- Any Concourse teams which configure GitLab users will have to switch each user
- from their full name to their username upon upgrading to these versions.
-
- ### Workarounds
-
- GitLab groups do not have this vulnerability, so GitLab users may be moved into
- groups which are then configured in the Concourse team.
-
- ### References
-
- * concourse/dex#12: PR with the fix
-
- ### For more information
-
- If you have any questions or comments about this advisory, you may reach us
- privately at
- [concoursete...@gmail.com](mailto:concoursete...@gmail.com).
cves:
- CVE-2020-5415
ghsas:
@@ -67,10 +25,6 @@
- advisory: https://github.com/concourse/concourse/security/advisories/GHSA-627p-rr78-99rj
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2020-5415
- web: https://tanzu.vmware.com/security/cve-2020-5415
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [GitLab auth docs](https://concourse-ci.org/gitlab-auth.html))'
- - lint: 'description: possible markdown formatting (found `users`)'
source:
id: GHSA-627p-rr78-99rj
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-66p8-j459-rq63.yaml b/internal/genericosv/testdata/yaml/GHSA-66p8-j459-rq63.yaml
index 8a7b120..a9ce711 100644
--- a/internal/genericosv/testdata/yaml/GHSA-66p8-j459-rq63.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-66p8-j459-rq63.yaml
@@ -9,30 +9,6 @@
summary: |-
Pterodactyl Wings contains UNIX Symbolic Link (Symlink) Following resulting in
deletion of files and directories on the host system in github.com/pterodactyl/wings
-description: |-
- ### Impact
-
- This vulnerability impacts anyone running the affected versions of Wings. The
- vulnerability can be used to delete files and directories recursively on the
- host system. This vulnerability can be combined with
- [`GHSA-p8r3-83r8-jwj5`](https://github.com/pterodactyl/wings/security/advisories/GHSA-p8r3-83r8-jwj5)
- to overwrite files on the host system.
-
- In order to use this exploit, an attacker must have an existing "server"
- allocated and controlled by Wings. Information on how the exploitation of this
- vulnerability works will be released on February 24th, 2023 in North America.
-
- ### Patches
-
- This vulnerability has been resolved in version `v1.11.4` of Wings, and has been
- back-ported to the 1.7 release series in `v1.7.4`.
-
- Anyone running `v1.11.x` should upgrade to `v1.11.4` and anyone running `v1.7.x`
- should upgrade to `v1.7.4`.
-
- ### Workarounds
-
- None at this time.
cves:
- CVE-2023-25168
ghsas:
@@ -42,10 +18,6 @@
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2023-25168
- fix: https://github.com/pterodactyl/wings/commit/429ac62dba22997a278bc709df5ac00a5a25d83d
- web: https://github.com/pterodactyl/wings/security/advisories/GHSA-p8r3-83r8-jwj5
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [`GHSA-p8r3-83r8-jwj5`](https://github.com/pterodactyl/wings/security/advisories/GHSA-p8r3-83r8-jwj5))'
- - lint: 'description: possible markdown formatting (found `GHSA-p8r3-83r8-jwj5`)'
source:
id: GHSA-66p8-j459-rq63
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-69v6-xc2j-r2jf.yaml b/internal/genericosv/testdata/yaml/GHSA-69v6-xc2j-r2jf.yaml
index 20c3433..c1d5a03 100644
--- a/internal/genericosv/testdata/yaml/GHSA-69v6-xc2j-r2jf.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-69v6-xc2j-r2jf.yaml
@@ -1,36 +1,13 @@
id: GO-ID-PENDING
modules:
- module: github.com/ethereum/go-ethereum
- non_go_versions:
- - fixed: 1.19.7
- vulnerable_at: 1.14.5
- packages:
- - package: github.com/ethereum/go-ethereum/core/vm
- - module: github.com/ethereum/go-ethereum
versions:
- introduced: 1.9.7
- fixed: 1.9.17
+ non_go_versions:
+ - fixed: 1.19.7
vulnerable_at: 1.9.16
summary: Shallow copy bug in geth in github.com/ethereum/go-ethereum
-description: |-
- ### Impact This is a Consensus vulnerability, which can be used to cause a
- chain-split where vulnerable nodes reject the canonical chain.
-
- Geth’s pre-compiled `dataCopy` (at `0x00...04`) contract did a shallow copy on
- invocation. An attacker could deploy a contract that
-
- - writes `X` to an EVM memory region `R`,
- - calls `0x00..04` with `R` as an argument,
- - overwrites `R` to `Y`,
- - and finally invokes the `RETURNDATACOPY` opcode.
-
- When this contract is invoked, a consensus-compliant node would push `X` on the
- EVM stack, whereas Geth would push `Y`.
-
- ### For more information If you have any questions or comments about this
- advisory:
- * Open an issue in [go-ethereum](https://github.com/ethereum/go-ethereum)
- * Email us at [secu...@ethereum.org](mailto:secu...@ethereum.org)
cves:
- CVE-2020-26241
ghsas:
@@ -40,10 +17,6 @@
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2020-26241
- fix: https://github.com/ethereum/go-ethereum/commit/295693759e5ded05fec0b2fb39359965b60da785
- web: https://blog.ethereum.org/2020/11/12/geth_security_release/
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [go-ethereum](https://github.com/ethereum/go-ethereum))'
- - lint: 'description: possible markdown formatting (found `dataCopy` (at `0x00...04`)'
source:
id: GHSA-69v6-xc2j-r2jf
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-6qfg-8799-r575.yaml b/internal/genericosv/testdata/yaml/GHSA-6qfg-8799-r575.yaml
index 9f10298..537f83a 100644
--- a/internal/genericosv/testdata/yaml/GHSA-6qfg-8799-r575.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-6qfg-8799-r575.yaml
@@ -7,23 +7,12 @@
- introduced: 1.14.6
- fixed: 1.14.7
vulnerable_at: 1.14.7-beta.0
- packages:
- - package: github.com/kubernetes/kubernetes/pkg/kubectl/cmd/cp
- module: k8s.io/kubernetes
versions:
- introduced: 1.15.3
- fixed: 1.16.0
vulnerable_at: 1.16.0-rc.2
- packages:
- - package: k8s.io/kubernetes/pkg/kubectl/cmd/cp
summary: Symlink Attack in github.com/kubernetes/kubernetes
-description: |-
- The Kubernetes kubectl cp command in versions 1.1-1.12, and versions prior to
- 1.13.11, 1.14.7, and 1.15.4 allows a combination of two symlinks provided by tar
- output of a malicious container to place a file outside of the destination
- directory specified in the kubectl cp invocation. This could be used to allow an
- attacker to place a nefarious file using a symlink, outside of the destination
- tree.
cves:
- CVE-2019-11251
ghsas:
diff --git a/internal/genericosv/testdata/yaml/GHSA-6rg3-8h8x-5xfv.yaml b/internal/genericosv/testdata/yaml/GHSA-6rg3-8h8x-5xfv.yaml
index 88961a9..b14eb40 100644
--- a/internal/genericosv/testdata/yaml/GHSA-6rg3-8h8x-5xfv.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-6rg3-8h8x-5xfv.yaml
@@ -8,27 +8,10 @@
summary: |-
Unchecked hostname resolution could allow access to local network resources by
users outside the local network in github.com/pterodactyl/wings
-description: |-
- ### Impact A newly implemented route allowing users to download files from
- remote endpoints was not properly verifying the destination hostname for user
- provided URLs. This would allow malicious users to potentially access resources
- on local networks that would otherwise be inaccessible.
-
- This vulnerability requires valid authentication credentials and is therefore
- **not exploitable by unauthenticated users**. If you are running an instance for
- yourself or other trusted individuals this impact is unlikely to be of major
- concern to you. However, you should still upgrade for security sake.
-
- ### Patches Users should upgrade to the latest version of Wings.
-
- ### Workarounds There is no workaround available that does not involve modifying
- Panel or Wings code.
ghsas:
- GHSA-6rg3-8h8x-5xfv
references:
- advisory: https://github.com/pterodactyl/wings/security/advisories/GHSA-6rg3-8h8x-5xfv
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
source:
id: GHSA-6rg3-8h8x-5xfv
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-7943-82jg-wmw5.yaml b/internal/genericosv/testdata/yaml/GHSA-7943-82jg-wmw5.yaml
index 7608a92..c30759d 100644
--- a/internal/genericosv/testdata/yaml/GHSA-7943-82jg-wmw5.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-7943-82jg-wmw5.yaml
@@ -13,112 +13,6 @@
- fixed: 2.4.5
vulnerable_at: 2.4.4
summary: Argo CD certificate verification is skipped for connections to OIDC providers in github.com/argoproj/argo-cd
-description: |-
- ### Impact
-
- All versions of Argo CD starting with v0.4.0 are vulnerable to an improper
- certificate validation bug which could cause Argo CD to trust a malicious (or
- otherwise untrustworthy) OIDC provider.
-
- (Note: external OIDC provider support was added in v0.11.0. Before that version,
- the notes below apply only to the bundled Dex instance.)
-
- You are impacted if 1) have SSO enabled and 2) insecure mode is _not_ enabled on
- the API server. In this case, certificate verification is skipped when
- connecting to your OIDC provider for the following tasks: verifying auth tokens
- on API requests and handling SSO login flows. If you are using the bundled Dex
- instance but have _not_ set the `--dex-server` flag on the API server to an
- HTTPS address, then certificate verification is not being skipped (because [TLS
- is not enabled by default for the bundled Dex
- instance](https://github.com/argoproj/argo-cd/issues/9424)).
-
- Argo CD sends requests to the configured OIDC provider (either the bundled Dex
- instance or an external provider) to 1) retrieve the [OpenID
- configuration](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig),
- 2) to retrieve the OIDC provider's key set (at the location determined by the
- [OIDC provider's configured
- `jwks_uri`](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata)),
- and 3) (during an SSO login) to exchange an authorization code for a token.
-
- (Note: Starting with v2.3.0, certificate verification is _not_ skipped when
- handling an SSO login flow if 1) you are not using the bundled Dex OIDC provider
- and 2) you have set `oidc.config.rootCA` in the `argocd-cm` ConfigMap.
- Certificate verification is still skipped when verifying tokens on API calls.)
-
- Skipping certificate verification when communicating with the OIDC provider
- opens Argo CD to a variety of risks. For example, if an attacker can
- successfully intercept, decrypt, and respond to requests bound for the
- configured OIDC provider (a machine-in-the-middle attack), they could
- theoretically issue a "valid" admin token. Verifying the OIDC provider's
- certificate provides an extra layer of protection against such an attack.
-
- ### Patches
-
- A patch for this vulnerability has been released in the following Argo CD
- versions:
-
- * v2.4.5
- * v2.3.6
- * v2.2.11
-
- **Note:**
-
- To preserve backwards compatibility, this patch adds a
- `oidc.tls.insecure.skip.verify` option to the `argocd-cm` ConfigMap. The default
- is `"false"`. Before resorting to setting this, you should try to get
- certificate verification to work. If you are using the bundled Dex instance,
- user your Argo CD API server's [TLS
- configuration](https://argo-cd.readthedocs.io/en/stable/operator-manual/tls/)
- since the API server acts as a reverse proxy to Dex. If you are using an
- external OIDC provider, [set the `rootCA`
- config](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#configuring-a-custom-root-ca-certificate-for-communicating-with-the-oidc-provider).
-
- If these fail, be sure you are aware of the risks before setting
- `oidc.tls.insecure.skip.verify: "true"`.
-
- ### Workarounds
-
- There is no complete workaround besides upgrading.
-
- #### Partial mitigation when using an external OIDC provider
-
- If you are using an external OIDC provider (not the bundled Dex instance), then
- you can mitigate the issue by setting the `oidc.config.rootCA` field in the
- `argocd-cm` ConfigMap. If your OIDC provider's certificate is self-signed or
- otherwise invalid, you must set the rootCA to a certificate that enables
- verification. If the OIDC provider's certificate passes _without_ an additional
- root CA, then you can set `oidc.config.rootCA` to a bogus non-empty string such
- as `"force cert verification"`. The API server will log a warning, but otherwise
- things should work fine.
-
- Example:
-
- ```yaml metadata: name: argocd-cm data: oidc.config: | ... rootCA: | force cert
- verification ```
-
- This mitigation _only_ forces certificate validation when the API server handles
- login flows. It does not force certificate verification when verifying tokens on
- API calls. To fully resolve the vulnerability, you must upgrade.
-
- ### References
-
- * [Argo CD SSO configuration
- documentation](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#sso)
-
- ### Credits
-
- @jannfis and @crenshaw-dev discovered the vulnerability when reviewing notes
- from ADA Logics' security audit of the Argo project sponsored by CNCF and
- facilitated by OSTIF. Thanks to Adam Korczynski and David Korczynski for their
- work on the audit.
-
- ### For more information
-
- * Open an issue in [the Argo CD issue
- tracker](https://github.com/argoproj/argo-cd/issues) or
- [discussions](https://github.com/argoproj/argo-cd/discussions)
- * Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel
- #argo-cd
cves:
- CVE-2022-31105
ghsas:
@@ -128,10 +22,6 @@
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2022-31105
- web: https://github.com/argoproj/argo-cd/releases/tag/v2.3.6
- web: https://github.com/argoproj/argo-cd/releases/tag/v2.4.5
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [discussions](https://github.com/argoproj/argo-cd/discussions))'
- - lint: 'description: possible markdown formatting (found `--dex-server`)'
source:
id: GHSA-7943-82jg-wmw5
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-7fxj-fr3v-r9gj.yaml b/internal/genericosv/testdata/yaml/GHSA-7fxj-fr3v-r9gj.yaml
index ceee394..7ee6f07 100644
--- a/internal/genericosv/testdata/yaml/GHSA-7fxj-fr3v-r9gj.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-7fxj-fr3v-r9gj.yaml
@@ -8,11 +8,6 @@
- last_affected: 6.4.0-alpha1
vulnerable_at: 1.0.9
summary: TiDB vulnerable to Use of Externally-Controlled Format String in github.com/pingcap/tidb
-description: |-
- TiDB server (importer CLI tool) prior to version 6.4.0 & 6.1.3 is vulnerable to
- data source name injection. The database name for generating and inserting data
- into a database does not properly sanitize user input which can lead to
- arbitrary file reads."
cves:
- CVE-2022-3023
ghsas:
diff --git a/internal/genericosv/testdata/yaml/GHSA-9689-rx4v-cqgc.yaml b/internal/genericosv/testdata/yaml/GHSA-9689-rx4v-cqgc.yaml
index 4438d15..e399c5d 100644
--- a/internal/genericosv/testdata/yaml/GHSA-9689-rx4v-cqgc.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-9689-rx4v-cqgc.yaml
@@ -8,14 +8,7 @@
- introduced: 5.6.0
- fixed: 5.8.1
vulnerable_at: 4.2.3+incompatible
- packages:
- - package: github.com/concourse/concourse/skymarshal/skyserver
summary: Open Redirect in github.com/concourse/concourse
-description: |-
- Pivotal Concourse Release, versions 4.x prior to 4.2.2, login flow allows
- redirects to untrusted websites. A remote unauthenticated attacker could
- convince a user to click on a link using the oAuth redirect link with an
- untrusted website and gain access to that user's access token in Concourse.
cves:
- CVE-2018-15798
ghsas:
diff --git a/internal/genericosv/testdata/yaml/GHSA-cf7g-cm7q-rq7f.yaml b/internal/genericosv/testdata/yaml/GHSA-cf7g-cm7q-rq7f.yaml
index ff4ef59..74955f6 100644
--- a/internal/genericosv/testdata/yaml/GHSA-cf7g-cm7q-rq7f.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-cf7g-cm7q-rq7f.yaml
@@ -7,12 +7,6 @@
- fixed: 2.3.5
vulnerable_at: 2.3.4
summary: SFTPGo WebClient vulnerable to Cross-site Scripting in github.com/drakkan/sftpgo
-description: |-
- ### Impact Cross-site scripting (XSS) vulnerabilities have been reported to
- affect SFTPGo WebClient. If exploited, this vulnerability allows remote
- attackers to inject malicious code.
-
- ### Patches Fixed in v2.3.5.
cves:
- CVE-2022-39220
ghsas:
@@ -21,8 +15,6 @@
- advisory: https://github.com/drakkan/sftpgo/security/advisories/GHSA-cf7g-cm7q-rq7f
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2022-39220
- fix: https://github.com/drakkan/sftpgo/commit/cbef217cfa92478ee8e00ba1a5fb074f8a8aeee0
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
source:
id: GHSA-cf7g-cm7q-rq7f
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-fv82-r8qv-ch4v.yaml b/internal/genericosv/testdata/yaml/GHSA-fv82-r8qv-ch4v.yaml
index 5c8cd00..fe304ef 100644
--- a/internal/genericosv/testdata/yaml/GHSA-fv82-r8qv-ch4v.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-fv82-r8qv-ch4v.yaml
@@ -5,28 +5,7 @@
- introduced: 0.10.0
- fixed: 0.13.4
vulnerable_at: 0.13.3
- - module: github.com/pomerium/pomerium
- versions:
- - introduced: 0.10.0
- - fixed: 0.13.4
- vulnerable_at: 0.13.3
- packages:
- - package: github.com/pomerium/pomerium/authenticate
summary: pomerium_signature is not verified in middleware in github.com/pomerium/pomerium
-description: |-
- ### Impact Some API endpoints under /.pomerium/ do not verify parameters with
- pomerium_signature. This could allow modifying parameters intended to be trusted
- to Pomerium.
-
- The issue mainly affects routes responsible for sign in/out, but does not
- introduce an authentication bypass.
-
- ### Patches Patched in v0.13.4
-
- ### For more information If you have any questions or comments about this
- advisory
- * Open an issue in [pomerium](http://github.com/pomerium/pomerium)
- * Email us at [secu...@pomerium.com](mailto:secu...@pomerium.com)
cves:
- CVE-2021-29652
ghsas:
@@ -35,9 +14,6 @@
- advisory: https://github.com/pomerium/pomerium/security/advisories/GHSA-fv82-r8qv-ch4v
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2021-29652
- fix: https://github.com/pomerium/pomerium/pull/2048
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [pomerium](http://github.com/pomerium/pomerium))'
source:
id: GHSA-fv82-r8qv-ch4v
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-g5gj-9ggf-9vmq.yaml b/internal/genericosv/testdata/yaml/GHSA-g5gj-9ggf-9vmq.yaml
index 4fdb4c3..491c409 100644
--- a/internal/genericosv/testdata/yaml/GHSA-g5gj-9ggf-9vmq.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-g5gj-9ggf-9vmq.yaml
@@ -4,17 +4,7 @@
versions:
- fixed: 1.4.0
vulnerable_at: 1.3.0
- packages:
- - package: github.com/cloudflare/cfrpki/cmd/octorpki
summary: Infinite certificate chain depth results in OctoRPKI running forever in github.com/cloudflare/cfrpki
-description: |-
- OctoRPKI does not limit the depth of a certificate chain, allowing for a CA to
- create children in an ad-hoc fashion, thereby making tree traversal never end.
-
- ## Patches
-
- ## For more information If you have any questions or comments about this
- advisory email us at secu...@cloudflare.com
cves:
- CVE-2021-3908
ghsas:
@@ -24,8 +14,6 @@
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2021-3908
- web: https://github.com/cloudflare/cfrpki/releases/tag/v1.4.0
- web: https://www.debian.org/security/2022/dsa-5041
-notes:
- - lint: 'description: possible markdown formatting (found ## )'
source:
id: GHSA-g5gj-9ggf-9vmq
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-g9wh-3vrx-r7hg.yaml b/internal/genericosv/testdata/yaml/GHSA-g9wh-3vrx-r7hg.yaml
index beb3ce4..0cc7c12 100644
--- a/internal/genericosv/testdata/yaml/GHSA-g9wh-3vrx-r7hg.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-g9wh-3vrx-r7hg.yaml
@@ -5,15 +5,6 @@
- fixed: 1.4.0
vulnerable_at: 1.3.0
summary: OctoRPKI crashes when processing GZIP bomb returned via malicious repository in github.com/cloudflare/cfrpki
-description: |-
- OctoRPKI tries to load the entire contents of a repository in memory, and in the
- case of a GZIP bomb, unzip it in memory, making it possible to create a
- repository that makes OctoRPKI run out of memory (and thus crash).
-
- ## Patches
-
- ## For more information If you have any questions or comments about this
- advisory email us at secu...@cloudflare.com
cves:
- CVE-2021-3912
ghsas:
@@ -23,8 +14,6 @@
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2021-3912
- fix: https://github.com/cloudflare/cfrpki/commit/648658b1b176a747b52645989cfddc73a81eacad
- web: https://www.debian.org/security/2022/dsa-5041
-notes:
- - lint: 'description: possible markdown formatting (found ## )'
source:
id: GHSA-g9wh-3vrx-r7hg
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-hjv9-hm2f-rpcj.yaml b/internal/genericosv/testdata/yaml/GHSA-hjv9-hm2f-rpcj.yaml
index 8b5f81a..f76b70f 100644
--- a/internal/genericosv/testdata/yaml/GHSA-hjv9-hm2f-rpcj.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-hjv9-hm2f-rpcj.yaml
@@ -10,18 +10,6 @@
- fixed: 9.3.8
vulnerable_at: 5.4.5+incompatible
summary: Grafana vulnerable to Cross-site Scripting in github.com/grafana/grafana
-description: |-
- Grafana is an open-source platform for monitoring and observability. Starting
- with the 8.1 branch, Grafana had a stored XSS vulnerability affecting the core
- plugin GeoMap. The stored XSS vulnerability was possible due to map attributions
- weren't properly sanitized and allowed arbitrary JavaScript to be executed in
- the context of the currently authorized user of the Grafana instance. An
- attacker needs to have the Editor role in order to change a panel to include a
- map attribution containing JavaScript. This means that vertical privilege
- escalation is possible, where a user with Editor role can change to a known
- password for a user having Admin role if the user with Admin role executes
- malicious JavaScript viewing a dashboard. Users may upgrade to version 8.5.21,
- 9.2.13 and 9.3.8 to receive a fix.
cves:
- CVE-2023-0507
ghsas:
diff --git a/internal/genericosv/testdata/yaml/GHSA-hmfx-3pcx-653p.yaml b/internal/genericosv/testdata/yaml/GHSA-hmfx-3pcx-653p.yaml
index c5ee4f0..879a6bc 100644
--- a/internal/genericosv/testdata/yaml/GHSA-hmfx-3pcx-653p.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-hmfx-3pcx-653p.yaml
@@ -7,54 +7,6 @@
- fixed: 1.6.18
vulnerable_at: 1.6.17
summary: Supplementary groups are not set up properly in github.com/containerd/containerd
-description: |-
- ### Impact
-
- A bug was found in containerd where supplementary groups are not set up properly
- inside a container. If an attacker has direct access to a container and
- manipulates their supplementary group access, they may be able to use
- supplementary group access to bypass primary group restrictions in some cases,
- potentially gaining access to sensitive information or gaining the ability to
- execute code in that container.
-
- Downstream applications that use the containerd client library may be affected
- as well.
-
- ### Patches This bug has been fixed in containerd v1.6.18 and v.1.5.18. Users
- should update to these versions and recreate containers to resolve this issue.
- Users who rely on a downstream application that uses containerd's client library
- should check that application for a separate advisory and instructions.
-
- ### Workarounds
-
- Ensure that the `"USER $USERNAME"` Dockerfile instruction is not used. Instead,
- set the container entrypoint to a value similar to `ENTRYPOINT ["su", "-",
- "user"]` to allow `su` to properly set up supplementary groups.
-
- ### References
-
- -
- https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/
- - Docker/Moby: CVE-2022-36109, fixed in Docker 20.10.18
- - CRI-O: CVE-2022-2995, fixed in CRI-O 1.25.0
- - Podman: CVE-2022-2989, fixed in Podman 3.0.1 and 4.2.0
- - Buildah: CVE-2022-2990, fixed in Buildah 1.27.1
-
- Note that CVE IDs apply to a particular implementation, even if an issue is
- common.
-
- ### For more information
-
- If you have any questions or comments about this advisory:
-
- * Open an issue in
- [containerd](https://github.com/containerd/containerd/issues/new/choose)
- * Email us at [secu...@containerd.io](mailto:secu...@containerd.io)
-
- To report a security issue in containerd:
- * [Report a new
- vulnerability](https://github.com/containerd/containerd/security/advisories/new)
- * Email us at [secu...@containerd.io](mailto:secu...@containerd.io)
cves:
- CVE-2023-25173
ghsas:
@@ -70,10 +22,6 @@
- web: https://github.com/containerd/containerd/releases/tag/v1.6.18
- web: https://github.com/moby/moby/security/advisories/GHSA-rc4r-wh2q-q6c4
- web: https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [containerd](https://github.com/containerd/containerd/issues/new/choose))'
- - lint: 'description: possible markdown formatting (found `"USER $USERNAME"`)'
source:
id: GHSA-hmfx-3pcx-653p
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-hv53-vf5m-8q94.yaml b/internal/genericosv/testdata/yaml/GHSA-hv53-vf5m-8q94.yaml
index d8b61d1..37d6983 100644
--- a/internal/genericosv/testdata/yaml/GHSA-hv53-vf5m-8q94.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-hv53-vf5m-8q94.yaml
@@ -7,57 +7,11 @@
- fixed: 3.0.1
vulnerable_at: 3.1.2
summary: personnummer/go vulnerable to Improper Input Validation in github.com/personnummer/go
-description: |-
- This vulnerability was reported to the personnummer team in June 2020. The slow
- response was due to locked ownership of some of the affected packages, which
- caused delays to update packages prior to disclosure.
-
- The vulnerability is determined to be low severity.
-
- ### Impact
-
- This vulnerability impacts users who rely on the for last digits of personnummer
- to be a _real_ personnummer.
-
- ### Patches
-
- The issue have been patched in all repositories. The following versions should
- be updated to as soon as possible:
-
- [C#](https://github.com/advisories/GHSA-qv8q-v995-72gr) 3.0.2 D 3.0.1
- [Dart](https://github.com/advisories/GHSA-4xh4-v2pq-jvhm) 3.0.3 Elixir 3.0.0
- [Go](https://github.com/advisories/GHSA-hv53-vf5m-8q94) 3.0.1
- [Java](https://github.com/advisories/GHSA-q3vw-4jx3-rrr2) 3.3.0
- [JavaScript](https://github.com/advisories/GHSA-vpgc-7h78-gx8f) 3.1.0 Kotlin
- 1.1.0 Lua 3.0.1 [PHP](https://github.com/advisories/GHSA-2p6g-gjp8-ggg9) 3.0.2
- Perl 3.0.0 [Python](https://github.com/advisories/GHSA-rxq3-5249-8hgg) 3.0.2
- [Ruby](https://github.com/advisories/GHSA-vp9c-fpxx-744v) 3.0.1
- [Rust](https://github.com/advisories/GHSA-28r9-pq4c-wp3c) 3.0.0 Scala 3.0.1
- Swift 1.0.1
-
- If you are using any of the earlier packages, please update to latest.
-
- ### Workarounds
-
- The issue arrieses from the regular expression allowing the first three digits
- in the last four digits of the personnummer to be 000, which is invalid. To
- mitigate this without upgrading, a check on the last four digits can be made to
- make sure it's not 000x.
-
- ### For more information
-
- If you have any questions or comments about this advisory:
- * Open an issue in [Personnummer
- Meta](https://github.com/personnummer/meta/issues)
- * Email us at [Personnummer Email](mailto:secu...@personnummer.dev)
ghsas:
- GHSA-hv53-vf5m-8q94
references:
- advisory: https://github.com/personnummer/go/security/advisories/GHSA-hv53-vf5m-8q94
- web: https://pkg.go.dev/github.com/personnummer/go
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [C#](https://github.com/advisories/GHSA-qv8q-v995-72gr))'
source:
id: GHSA-hv53-vf5m-8q94
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-jh36-q97c-9928.yaml b/internal/genericosv/testdata/yaml/GHSA-jh36-q97c-9928.yaml
index 6b0d4d3..26eb9dd 100644
--- a/internal/genericosv/testdata/yaml/GHSA-jh36-q97c-9928.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-jh36-q97c-9928.yaml
@@ -12,16 +12,6 @@
- fixed: 1.25.4
vulnerable_at: 1.25.4-rc.0
summary: Kubernetes vulnerable to validation bypass in k8s.io/kubernetes
-description: |-
- Users may have access to secure endpoints in the control plane network.
- Kubernetes clusters are only affected if an untrusted user can modify Node
- objects and send proxy requests to them. Kubernetes supports node proxying,
- which allows clients of kube-apiserver to access endpoints of a Kubelet to
- establish connections to Pods, retrieve container logs, and more. While
- Kubernetes already validates the proxying address for Nodes, a bug in
- kube-apiserver made it possible to bypass this validation. Bypassing this
- validation could allow authenticated requests destined for Nodes to to the API
- server's private network.
cves:
- CVE-2022-3294
ghsas:
diff --git a/internal/genericosv/testdata/yaml/GHSA-jmp2-wc4p-wfh2.yaml b/internal/genericosv/testdata/yaml/GHSA-jmp2-wc4p-wfh2.yaml
index 996bb0f..5c7ad4e 100644
--- a/internal/genericosv/testdata/yaml/GHSA-jmp2-wc4p-wfh2.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-jmp2-wc4p-wfh2.yaml
@@ -13,42 +13,6 @@
summary: |-
Mutagen list and monitor operations do not neutralize control characters in text
controlled by remote endpoints in github.com/mutagen-io/mutagen
-description: |-
- ### Impact
-
- Mutagen command line operations, as well as the log output from `mutagen daemon
- run`, are susceptible to control characters that could be provided by remote
- endpoints. This can cause terminal corruption, either intentional or
- unintentional, if these characters are present in error messages, file
- paths/names, and/or log output. This could be used as an attack vector if
- synchronizing with an untrusted remote endpoint, synchronizing files not under
- control of the user, or forwarding to/from an untrusted remote endpoint. On very
- old systems with terminals susceptible to issues such as
- [CVE-2003-0069](https://nvd.nist.gov/vuln/detail/CVE-2003-0069), the issue could
- theoretically cause code execution.
-
- ### Patches
-
- The problem has been patched in Mutagen v0.16.6 and v0.17.1. Earlier versions of
- Mutagen are no longer supported and will not be patched. Versions of Mutagen
- after v0.18.0 will also have the patch merged.
-
- One caveat is that the templating functionality of Mutagen's `list` and
- `monitor` commands has been only partially patched. In particular, the `json`
- template function already provided escaping and no patching was necessary.
- However, raw template output has been left unescaped because this raw output may
- be necessary for commands which embed Mutagen. To aid these commands, a new
- `shellSanitize` template function has been added which provides control
- character neutralization in strings.
-
- ### Workarounds
-
- Avoiding synchronization of untrusted files or interaction with untrusted remote
- endpoints should mitigate any risk.
-
- ### References
-
- A similar issue can be seen in kubernetes/kubernetes#101695.
cves:
- CVE-2023-30844
ghsas:
@@ -58,10 +22,6 @@
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2023-30844
- web: https://github.com/mutagen-io/mutagen/releases/tag/v0.16.6
- web: https://github.com/mutagen-io/mutagen/releases/tag/v0.17.1
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [CVE-2003-0069](https://nvd.nist.gov/vuln/detail/CVE-2003-0069))'
- - lint: 'description: possible markdown formatting (found `list`)'
source:
id: GHSA-jmp2-wc4p-wfh2
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-m99c-q26r-m7m7.yaml b/internal/genericosv/testdata/yaml/GHSA-m99c-q26r-m7m7.yaml
new file mode 100644
index 0000000..8b9cfad
--- /dev/null
+++ b/internal/genericosv/testdata/yaml/GHSA-m99c-q26r-m7m7.yaml
@@ -0,0 +1,39 @@
+id: GO-ID-PENDING
+modules:
+ - module: github.com/evmos/evmos
+ vulnerable_at: 1.1.3
+ - module: github.com/evmos/evmos/v2
+ vulnerable_at: 2.0.2
+ - module: github.com/evmos/evmos/v3
+ vulnerable_at: 3.0.3
+ - module: github.com/evmos/evmos/v4
+ vulnerable_at: 4.0.2
+ - module: github.com/evmos/evmos/v5
+ vulnerable_at: 5.0.1
+ - module: github.com/evmos/evmos/v6
+ vulnerable_at: 6.0.4
+ - module: github.com/evmos/evmos/v7
+ vulnerable_at: 7.0.0
+ - module: github.com/evmos/evmos/v8
+ vulnerable_at: 8.2.3
+ - module: github.com/evmos/evmos/v9
+ vulnerable_at: 9.1.0
+ - module: github.com/evmos/evmos/v10
+ vulnerable_at: 10.0.1
+ - module: github.com/evmos/evmos/v11
+ vulnerable_at: 11.0.2
+ - module: github.com/evmos/evmos/v12
+ vulnerable_at: 12.1.6
+ - module: github.com/evmos/evmos/v13
+ unsupported_versions:
+ - last_affected: 13.0.2
+ vulnerable_at: 13.0.2
+summary: Evmos vulnerable to unauthorized account creation with vesting module in github.com/evmos/evmos
+ghsas:
+ - GHSA-m99c-q26r-m7m7
+references:
+ - advisory: https://github.com/evmos/evmos/security/advisories/GHSA-m99c-q26r-m7m7
+source:
+ id: GHSA-m99c-q26r-m7m7
+ created: 1999-01-01T00:00:00Z
+review_status: UNREVIEWED
diff --git a/internal/genericosv/testdata/yaml/GHSA-pg5p-wwp8-97g8.yaml b/internal/genericosv/testdata/yaml/GHSA-pg5p-wwp8-97g8.yaml
index 5cbf528..4f00cf6 100644
--- a/internal/genericosv/testdata/yaml/GHSA-pg5p-wwp8-97g8.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-pg5p-wwp8-97g8.yaml
@@ -22,45 +22,6 @@
- fixed: 1.13.2
vulnerable_at: 1.13.1
summary: Debug mode leaks confidential data in Cilium in github.com/cilium/cilium
-description: |-
- ### Impact
-
- When run in debug mode, Cilium may log sensitive information.
-
- In particular, Cilium running in debug mode will log the values of headers if
- they match HTTP network policy rules. This issue affects Cilium versions:
-
- - 1.7.* to 1.10.* inclusive
- - 1.11.* before 1.11.16
- - 1.12.* before 1.12.9
- - 1.13.* before 1.13.2
-
- In addition, Cilium 1.12.* before 1.12.9 and 1.13.* before 1.13.2., when running
- in debug mode, might log secrets used by the Cilium agent. This includes TLS
- private keys for Ingress and GatewayAPI resources, depending on the
- configuration of the affected cluster. Output of the confidential data would
- occur at Cilium agent restart, when the secrets are modified, and on creation of
- Ingress or GatewayAPI resources.
-
- ### Patches
-
- This vulnerability is fixed in Cilium releases 1.11.16, 1.12.9, and 1.13.2.
-
- ### Workarounds Disable debug mode.
-
- ### Acknowledgements The Cilium community has worked together with members of
- Isovalent to prepare these mitigations. Special thanks to @meyskens for
- investigating and fixing the issue.
-
- ### For more information If you have any questions or comments about this
- advisory, please reach out on
- [Slack](https://docs.cilium.io/en/latest/community/community/#slack).
-
- As usual, if you think you found a related vulnerability, we strongly encourage
- you to report security vulnerabilities to our private security mailing list:
- [secu...@cilium.io](mailto:secu...@cilium.io) - first, before disclosing them
- in any public forums. This is a private mailing list where only members of the
- Cilium internal security team are subscribed to, and is treated as top priority.
cves:
- CVE-2023-29002
ghsas:
@@ -70,8 +31,6 @@
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2023-29002
notes:
- fix: 'module merge error: could not merge versions of module github.com/cilium/cilium: introduced and fixed versions must alternate'
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [Slack](https://docs.cilium.io/en/latest/community/community/#slack))'
source:
id: GHSA-pg5p-wwp8-97g8
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-pmfr-63c2-jr5c.yaml b/internal/genericosv/testdata/yaml/GHSA-pmfr-63c2-jr5c.yaml
index cb414a9..10cbc7a 100644
--- a/internal/genericosv/testdata/yaml/GHSA-pmfr-63c2-jr5c.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-pmfr-63c2-jr5c.yaml
@@ -6,57 +6,6 @@
non_go_versions:
- fixed: 3.6.0
summary: Execution Control List (ECL) Is Insecure in Singularity in github.com/sylabs/singularity
-description: |-
- ### Impact
-
- The Singularity Execution Control List (ECL) allows system administrators to set
- up a policy that defines rules about what signature(s) must be (or must not be)
- present on a SIF container image for it to be permitted to run.
-
- In Singularity 3.x versions below 3.6.0, the following issues allow the ECL to
- be bypassed by a malicious user:
-
- * Image integrity is not validated when an ECL policy is enforced.
- * The fingerprint required by the ECL is compared against the signature object
- descriptor(s) in the SIF file, rather than to a cryptographically validated
- signature. Thus, it is trivial to craft an arbitrary payload which will be
- permitted to run, even if the attacker does not have access to the private key
- associated with the fingerprint(s) configured in the ECL.
-
- ### Patches
-
- These issues are addressed in Singularity 3.6.0.
-
- All users are advised to upgrade to 3.6.0. Note that Singularity 3.6.0 uses a
- new signature format that is necessarily incompatible with Singularity < 3.6.0 -
- e.g. Singularity 3.5.3 cannot verify containers signed by 3.6.0.
-
- Version 3.6.0 includes a `legacyinsecure` option that can be set to
- `legacyinsecure = true` in `ecl.toml` to allow the ECL to perform verification
- of the older, and insecure, legacy signatures for compatibility with existing
- containers. This does not guarantee that containers have not been modified since
- signing, due to other issues in the legacy signature format. The option should
- be used only to temporarily ease the transition to containers signed with the
- new 3.6.0 signature format.
-
- ### Workarounds
-
- This issue affects any installation of Singularity configured to use the
- Execution Control List (ECL) functionality. There is no workaround if ECL is
- required.
-
- ### For more information
-
- General questions about the impact of the advisory / changes made in the 3.6.0
- release can be asked in the:
-
- * [Singularity Slack Channel](https://bit.ly/2m0g3lX)
- * [Singularity Mailing
- List](https://groups.google.com/a/lbl.gov/forum/??sdf%7Csort:date#!forum/singularity)
-
- Any sensitive security concerns should be directed to: secu...@sylabs.io
-
- See our Security Policy here: https://sylabs.io/security-policy
cves:
- CVE-2020-13845
ghsas:
@@ -70,9 +19,6 @@
- web: https://medium.com/sylabs
notes:
- fix: 'github.com/sylabs/singularity: could not add vulnerable_at: latest version (0.0.0-20230731083700-61a3083f0c3c) is before last introduced version'
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [Singularity Slack Channel](https://bit.ly/2m0g3lX))'
- - lint: 'description: possible markdown formatting (found `legacyinsecure`)'
source:
id: GHSA-pmfr-63c2-jr5c
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-v6rw-hhgg-wc4x.yaml b/internal/genericosv/testdata/yaml/GHSA-v6rw-hhgg-wc4x.yaml
index 96cc698..10dca21 100644
--- a/internal/genericosv/testdata/yaml/GHSA-v6rw-hhgg-wc4x.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-v6rw-hhgg-wc4x.yaml
@@ -27,76 +27,10 @@
- fixed: 12.0.0
vulnerable_at: 12.0.0-rc4
summary: Evmos vulnerable to DOS and transaction fee expropriation through Authz exploit in github.com/evmos/evmos
-description: |-
- ## Impact _What kind of vulnerability is it? Who is impacted?_
-
- An attacker can use this bug to bypass the block gas limit and gas payment
- completely to perform a full Denial-of-Service against the chain.
-
- ## Disclosure
-
- Evmos versions below `v11.0.1` do not check for `MsgEthereumTx` messages that
- are nested under other messages. This allows a malicious actor to perform EVM
- transactions that do not meet the checks performed under `newEthAnteHandler`.
- This opens the possibility for the DOS of validators and consequently halt the
- chain through an infinite EVM execution.
-
- ### Additional details
-
- The attack scenario is as follows:
-
- 1. The attacker deploys a simple smart contract with an infinite loop to the
- chain.
- 2. The attacker calls the smart contract using an embedded transaction with an
- extremely high gas value (`uint64` max or similar).
- 3. Once the transaction is included in a block, nodes will try to execute the
- EVM transaction with almost infinite gas and get stuck. **This stops new block
- creation and effectively halts the chain, requiring a manual restart of all
- nodes.**
-
- ## Users Impacted All Evmos users are impacted by this vulnerability as it has
- the potential to halt the chain. Users' funds and chain state are safe but when
- under attack, the chain could be deemed unusable.
-
- ## Patches
-
- _Has the problem been patched? What versions should users upgrade to?_
-
- The vulnerability has been patched on Evmos versions ≥v12.0.0.
-
- ### Details
-
- As a temporary workaround, the fix blocks `MsgEthereumTxs` messages from being
- sent under the `authz` module's `MsgExec` message. It also covers the scenario
- in which `MsgEthereumTx` are deeply nested by:
-
- - Doing a recursive check over the nested messages of `MsgExec`
- - Limiting the amount of possible nested messages (inner messages) in `MsgExec`
-
- This is done by adding an additional `AnteHandler` decorator
- (`AuthzLimiterDecorator`) for Cosmos and EIP-712 transactions.
-
- This is a state machine-breaking change as it restricts previously allowed
- messages and thus requires a hard-fork upgrade.
-
- ## References __Are there any links users can visit to find out more?__
-
- ### For more information If you have any questions or comments about this
- advisory:
-
- - Reach out to the Core Team in [Discord](https://discord.gg/evmos)
- - Open a discussion in [evmos/evmos](https://github.com/evmos/evmos/discussions)
- - Email us at [secu...@evmos.org](mailto:secu...@evmos.org) for security
- questions
- - For Press, email us at [ev...@west-comms.com](mailto:ev...@west-comms.com).
ghsas:
- GHSA-v6rw-hhgg-wc4x
references:
- advisory: https://github.com/evmos/evmos/security/advisories/GHSA-v6rw-hhgg-wc4x
-notes:
- - lint: 'description: possible markdown formatting (found ## )'
- - lint: 'description: possible markdown formatting (found [Discord](https://discord.gg/evmos))'
- - lint: 'description: possible markdown formatting (found `v11.0.1` do not check for `MsgEthereumTx`)'
source:
id: GHSA-v6rw-hhgg-wc4x
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-vp35-85q5-9f25.yaml b/internal/genericosv/testdata/yaml/GHSA-vp35-85q5-9f25.yaml
index 33bef7f..a2f54d1 100644
--- a/internal/genericosv/testdata/yaml/GHSA-vp35-85q5-9f25.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-vp35-85q5-9f25.yaml
@@ -5,102 +5,6 @@
- fixed: 20.10.20+incompatible
vulnerable_at: 20.10.19+incompatible
summary: Container build can leak any path on the host into the container in github.com/moby/moby
-description: |-
- ### Description
-
- Moby is the open source Linux container runtime and set of components used to
- build a variety of downstream container runtimes, including Docker CE, Mirantis
- Container Runtime (formerly Docker EE), and Docker Desktop. Moby allows for
- building container images using a set of build instructions (usually named and
- referred to as a "Dockerfile"), and a build context, which is not unlike the CWD
- in which the Dockerfile instructions are executed.
-
- Containers may be built using a variety of tools and build backends available in
- the Moby ecosystem; in all cases, builds may not include files outside of the
- build context (such as using absolute or relative-parent paths). This is
- enforced through both checks in the build backends, and the containerization of
- the build process itself.
-
- Versions of Git where CVE-2022-39253 is present and exploited by a malicious
- repository, when used in combination with Moby, are subject to an unexpected
- inclusion of arbitrary filesystem paths in the build context, without any
- visible warning to the user.
-
- This issue was originally reported by Wenxiang Qian of Tencent Blade Team, and
- the root-cause analysis was performed by Cory Snider of Mirantis, with
- assistance from Bjorn Neergaard of the same. The issue was then reported to the
- Git project, and Taylor Blau led the process resolving the root issue in Git.
-
- ### Impact
-
- This vulnerability originates in Git, but can be used to violate assumptions
- that may have security implications for users of Moby and related components.
- Users may rely on the fact that a build context ensures that outside files
- cannot be referenced or incorporated using multiple enforcement mechanisms, or
- expect a warning if this does not hold true. A maliciously crafted Git
- repository exploiting CVE-2022-39253 can violate this assumption, and
- potentially include sensitive files that are subsequently uploaded to a
- container image repository, or disclosed by code inside the resulting container
- image.
-
- As this issue cannot be triggered remotely, except by users who already have
- full control over the daemon through the API, and it requires exploiting a
- vulnerability in Git by convincing a user to build a maliciously crafted
- repository, the impact in Moby is considered low.
-
- ### Patches
-
- Moby 20.10.20, and Mirantis Container Runtime (formerly Docker Enterprise
- Edition) 20.10.14 will contain mitigations for CVE-2022-39253 when a Git clone
- is performed by Moby components (on either the daemon or API client side).
- However, as these mitigations only apply to certain scenarios (build of
- `git+<protocol>://...` URL contexts) and cannot protect against a malicious
- repository already on disk, users should update to a version of Git containing
- patches for CVE-2022-39253 on all their systems running both API clients and
- daemons.
-
- Specifically, patches in Moby (including patches incorporated from BuildKit)
- protect against the following:
-
- * `docker build` with the legacy builder (e.g. `DOCKER_BUILDKIT` unset or set to
- 0) of a Git URL context. Note that depending on available API versions and the
- CLI version, the Git clone operation can take place on either the client or the
- daemon side. Both must be updated (or have Git updated) to fully protect this
- build method.
- * `docker build` with the BuildKit builder (e.g. `DOCKER_BUILDKIT=1`) of a Git
- URL context.
- * `docker buildx build` with `BUILDKIT_CONTEXT_KEEP_GIT_DIR=1` of a Git URL
- context.
-
- Patches in BuildKit incorporated into Docker Compose protect against
- CVE-2022-39253 during Compose-driven builds of Git URL contexts.
-
- Patches in Moby and related projects such as BuildKit, the Docker CLI, and
- Docker Compose **cannot** fully protect against CVE-2022-39253, as it may be
- triggered by a malicious repository already on disk that a unpatched Git client
- has interacted with (specifically, commands that check out submodules such as
- `git clone --recursive`, `git submodule update`, etc. may have already triggered
- the Git vulnerability).
-
- ### Workarounds
-
- While this behavior is unexpected and undesirable, and has resulted in this
- security advisory, users should keep in mind that building a container entails
- arbitrary code execution. Users should not build a repository/build context they
- do not trust, as containerization cannot protect against all possible attacks.
-
- When building with BuildKit (e.g. `docker buildx build` or `docker build` with
- `DOCKER_BUILDKIT=1`), this issue cannot be exploited unless `--build-arg
- BUILDKIT_CONTEXT_KEEP_GIT_DIR=1` was also passed, as by default BuildKit will
- discard the `.git` directory of a Git URL context immediately after cloning and
- checking out the repository.
-
- ### For more information
-
- If you have any questions or comments about this advisory:
-
- * [Open an issue](https://github.com/moby/moby/issues/new)
- * Email us at [secu...@docker.com](mailto:secu...@docker.com)
ghsas:
- GHSA-vp35-85q5-9f25
references:
@@ -108,10 +12,6 @@
- web: https://github.blog/2022-10-17-git-security-vulnerabilities-announced/
- web: https://github.com/moby/moby/releases/tag/v20.10.20
- web: https://lore.kernel.org/git/xmqq4jw1uku5.fsf@gitster.g/T/#u
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [Open an issue](https://github.com/moby/moby/issues/new))'
- - lint: 'description: possible markdown formatting (found `git+<protocol>://...`)'
source:
id: GHSA-vp35-85q5-9f25
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-w4xh-w33p-4v29.yaml b/internal/genericosv/testdata/yaml/GHSA-w4xh-w33p-4v29.yaml
index b5ca076..b839cb7 100644
--- a/internal/genericosv/testdata/yaml/GHSA-w4xh-w33p-4v29.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-w4xh-w33p-4v29.yaml
@@ -4,17 +4,7 @@
non_go_versions:
- fixed: 2.1.1-0.20170519163204-f913f5f9c7c6
vulnerable_at: 1.5.6
- - module: github.com/git-lfs/git-lfs
- non_go_versions:
- - fixed: 2.1.1-0.20170519163204-f913f5f9c7c6
- vulnerable_at: 1.5.6
- packages:
- - package: github.com/git-lfs/git-lfs/lfsapi
summary: GitHub Git LFS Improper Input Validation vulnerability in github.com/git-lfs/git-lfs
-description: |-
- GitHub Git LFS before 2.1.1 allows remote attackers to execute arbitrary
- commands via an ssh URL with an initial dash character in the hostname, located
- on a `url =` line in a `.lfsconfig` file within a repository.
cves:
- CVE-2017-17831
ghsas:
@@ -30,8 +20,6 @@
- web: https://confluence.atlassian.com/sourcetreekb/sourcetree-security-advisory-2018-01-24-942834324.html
- web: https://github.com/git-lfs/git-lfs/releases/tag/v2.1.1
- web: https://web.archive.org/web/20200227131639/http://www.securityfocus.com/bid/102926
-notes:
- - lint: 'description: possible markdown formatting (found `url =` line in a `.lfsconfig`)'
source:
id: GHSA-w4xh-w33p-4v29
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-wx8q-rgfr-cf6v.yaml b/internal/genericosv/testdata/yaml/GHSA-wx8q-rgfr-cf6v.yaml
index a590feb..a98b9c0 100644
--- a/internal/genericosv/testdata/yaml/GHSA-wx8q-rgfr-cf6v.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-wx8q-rgfr-cf6v.yaml
@@ -7,18 +7,6 @@
summary: |-
Insufficient Granularity of Access Control in
github.com/google/exposure-notifications-verification-server
-description: |-
- ### Impact Users or API keys with permission to expire verification codes could
- have expired codes that belonged to another realm if they guessed the UUID.
-
- ### Patches v1.1.2+
-
- ### Workarounds There are no workarounds, and there are no indications this has
- been exploited in the wild. Verification codes can only be expired by providing
- their 64-bit UUID, and verification codes are already valid for a very short
- period of time (thus the UUID rotates frequently).
-
- ### For more information Contact exposure-notifi...@google.com
cves:
- CVE-2021-22565
ghsas:
@@ -27,8 +15,6 @@
- advisory: https://github.com/google/exposure-notifications-verification-server/security/advisories/GHSA-wx8q-rgfr-cf6v
- advisory: https://nvd.nist.gov/vuln/detail/CVE-2021-22565
- web: https://github.com/google/exposure-notifications-verification-server/releases/tag/v1.1.2
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
source:
id: GHSA-wx8q-rgfr-cf6v
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-xmg8-99r8-jc2j.yaml b/internal/genericosv/testdata/yaml/GHSA-xmg8-99r8-jc2j.yaml
index ef6e3a7..d067a6b 100644
--- a/internal/genericosv/testdata/yaml/GHSA-xmg8-99r8-jc2j.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-xmg8-99r8-jc2j.yaml
@@ -12,54 +12,6 @@
- fixed: 2.3.4
vulnerable_at: 2.3.3
summary: Login screen allows message spoofing if SSO is enabled in github.com/argoproj/argo-cd
-description: |-
- ### Impact
-
- A vulnerability was found in Argo CD that allows an attacker to spoof error
- messages on the login screen when SSO is enabled.
-
- In order to exploit this vulnerability, an attacker would have to trick the
- victim to visit a specially crafted URL which contains the message to be
- displayed.
-
- As far as the research of the Argo CD team concluded, it is not possible to
- specify any active content (e.g. Javascript) or other HTML fragments (e.g.
- clickable links) in the spoofed message.
-
- ### Patched versions
-
- A patch for this vulnerability has been released in the following Argo CD
- versions:
-
- * v2.3.4
- * v2.2.9
- * v2.1.15
-
- ### Workarounds
-
- No workaround available.
-
- #### Mitigations
-
- It is advised to update to an Argo CD version containing a fix for this issue
- (see *Patched versions* above).
-
- ### Credits
-
- This vulnerability was discovered by Naufal Septiadi (<nau...@horangi.com>) and
- reported to us in a responsible way.
-
- ### For more information
-
- <!-- Use only one of the paragraphs below. Remove all others. -->
-
- <!-- For Argo CD -->
-
- * Open an issue in [the Argo CD issue
- tracker](https://github.com/argoproj/argo-cd/issues) or
- [discussions](https://github.com/argoproj/argo-cd/discussions)
- * Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel
- #argo-cd
cves:
- CVE-2022-24905
ghsas:
@@ -70,9 +22,6 @@
- web: https://github.com/argoproj/argo-cd/releases/tag/v2.1.15
- web: https://github.com/argoproj/argo-cd/releases/tag/v2.2.9
- web: https://github.com/argoproj/argo-cd/releases/tag/v2.3.4
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
- - lint: 'description: possible markdown formatting (found [discussions](https://github.com/argoproj/argo-cd/discussions))'
source:
id: GHSA-xmg8-99r8-jc2j
created: 1999-01-01T00:00:00Z
diff --git a/internal/genericosv/testdata/yaml/GHSA-xx9w-464f-7h6f.yaml b/internal/genericosv/testdata/yaml/GHSA-xx9w-464f-7h6f.yaml
index 9a716f9..e67484f 100644
--- a/internal/genericosv/testdata/yaml/GHSA-xx9w-464f-7h6f.yaml
+++ b/internal/genericosv/testdata/yaml/GHSA-xx9w-464f-7h6f.yaml
@@ -11,40 +11,12 @@
- introduced: 1.0.0
vulnerable_at: 2.5.2-rc1+incompatible
summary: Harbor fails to validate the user permissions when updating a robot account in github.com/goharbor/harbor
-description: |-
- ### Impact Harbor fails to validate the user permissions when updating a robot
- account that belongs to a project that the authenticated user doesn’t have
- access to. API call:
-
- PUT /robots/{robot_id}
-
- By sending a request that attempts to update a robot account, and specifying a
- robot account id and robot account name that belongs to a different project that
- the user doesn’t have access to, it was possible to revoke the robot account
- permissions.
-
- ### Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please
- upgrade as soon as possible.
-
- ### Workarounds There are no workarounds available.
-
- ### For more information If you have any questions or comments about this
- advisory:
- * Open an issue in [the Harbor GitHub
- repository](https://github.com/goharbor/harbor)
-
- ### Credits Thanks to [Gal
- Goldstein](https://www.linkedin.com/in/gal-goldshtein/) and [Daniel
- Abeles](https://www.linkedin.com/in/daniel-abeles/) from [Oxeye
- Security](https://www.oxeye.io/) for reporting this issue.
cves:
- CVE-2022-31667
ghsas:
- GHSA-xx9w-464f-7h6f
references:
- advisory: https://github.com/goharbor/harbor/security/advisories/GHSA-xx9w-464f-7h6f
-notes:
- - lint: 'description: possible markdown formatting (found ### )'
source:
id: GHSA-xx9w-464f-7h6f
created: 1999-01-01T00:00:00Z
diff --git a/internal/report/lint.go b/internal/report/lint.go
index 389ef68..40dee22 100644
--- a/internal/report/lint.go
+++ b/internal/report/lint.go
@@ -484,10 +484,17 @@
}
func (r *Report) AddNote(t NoteType, format string, v ...any) {
- r.Notes = append(r.Notes, &Note{
+ n := &Note{
Body: fmt.Sprintf(format, v...),
Type: t,
- })
+ }
+ // Don't add the same note twice.
+ for _, nn := range r.Notes {
+ if nn.Type == n.Type && nn.Body == n.Body {
+ return
+ }
+ }
+ r.Notes = append(r.Notes, n)
}
// LintOffline performs all lint checks that don't require a network connection.
diff --git a/internal/report/new.go b/internal/report/new.go
index 1c2c646..a4074a9 100644
--- a/internal/report/new.go
+++ b/internal/report/new.go
@@ -38,9 +38,34 @@
}
r.Fix(pc)
+
+ if r.ReviewStatus == Unreviewed {
+ r.Description = ""
+ // Package-level data is often wrong/incomplete, which could lead
+ // to false negatives, so remove it for unreviewed reports.
+ // TODO(tatianabradley): instead of removing all package-level data,
+ // consider doing a surface-level check such as making sure packages are
+ // known to pkgsite.
+ r.removePackages(pc)
+ }
+
return r
}
+func (r *Report) removePackages(pc *proxy.Client) {
+ removed := false
+ for _, m := range r.Modules {
+ if !m.IsFirstParty() && len(m.Packages) != 0 {
+ m.Packages = nil
+ removed = true
+ }
+ }
+ // If any packages were removed, we may need to merge some modules.
+ if removed {
+ _ = r.FixModules(pc)
+ }
+}
+
type Fetcher interface {
Fetch(ctx context.Context, id string) (Source, error)
}
Change information
Files:
- M cmd/vulnreport/creator.go
- M internal/cve5/testdata/cve/TestToReport/CVE-2020-9283.txtar
- M internal/cve5/testdata/cve/TestToReport/CVE-2021-27919.txtar
- M internal/cve5/testdata/cve/TestToReport/CVE-2021-3115.txtar
- M internal/cve5/testdata/cve/TestToReport/CVE-2022-39213.txtar
- M internal/cve5/testdata/cve/TestToReport/CVE-2023-29407.txtar
- M internal/cve5/testdata/cve/TestToReport/CVE-2023-44378.txtar
- M internal/cve5/testdata/cve/TestToReport/CVE-2023-45141.txtar
- M internal/cve5/testdata/cve/TestToReport/CVE-2023-45283.txtar
- M internal/cve5/testdata/cve/TestToReport/CVE-2023-45285.txtar
- M internal/cve5/testdata/cve/TestToReport/CVE-2023-45286.txtar
- M internal/cve5/testdata/cve/TestToReport/CVE-2024-2056.txtar
- M internal/cve5/testdata/cve/TestToReport/CVE-2024-3094.txtar
- M internal/cve5/testdata/cve/TestToReport/CVE-2024-33522.txtar
- A internal/genericosv/testdata/osv/GHSA-m99c-q26r-m7m7.json
- A internal/genericosv/testdata/proxy/TestToReport/GHSA-m99c-q26r-m7m7.json
- M internal/genericosv/testdata/yaml/GHSA-28r2-q6m8-9hpx.yaml
- M internal/genericosv/testdata/yaml/GHSA-33m6-q9v5-62r7.yaml
- M internal/genericosv/testdata/yaml/GHSA-3cqf-953p-h5cp.yaml
- M internal/genericosv/testdata/yaml/GHSA-3hwm-922r-47hw.yaml
- M internal/genericosv/testdata/yaml/GHSA-3wq5-3f56-v5xc.yaml
- M internal/genericosv/testdata/yaml/GHSA-54q4-74p3-mgcw.yaml
- M internal/genericosv/testdata/yaml/GHSA-5m6c-jp6f-2vcv.yaml
- M internal/genericosv/testdata/yaml/GHSA-627p-rr78-99rj.yaml
- M internal/genericosv/testdata/yaml/GHSA-66p8-j459-rq63.yaml
- M internal/genericosv/testdata/yaml/GHSA-69v6-xc2j-r2jf.yaml
- M internal/genericosv/testdata/yaml/GHSA-6qfg-8799-r575.yaml
- M internal/genericosv/testdata/yaml/GHSA-6rg3-8h8x-5xfv.yaml
- M internal/genericosv/testdata/yaml/GHSA-7943-82jg-wmw5.yaml
- M internal/genericosv/testdata/yaml/GHSA-7fxj-fr3v-r9gj.yaml
- M internal/genericosv/testdata/yaml/GHSA-9689-rx4v-cqgc.yaml
- M internal/genericosv/testdata/yaml/GHSA-cf7g-cm7q-rq7f.yaml
- M internal/genericosv/testdata/yaml/GHSA-fv82-r8qv-ch4v.yaml
- M internal/genericosv/testdata/yaml/GHSA-g5gj-9ggf-9vmq.yaml
- M internal/genericosv/testdata/yaml/GHSA-g9wh-3vrx-r7hg.yaml
- M internal/genericosv/testdata/yaml/GHSA-hjv9-hm2f-rpcj.yaml
- M internal/genericosv/testdata/yaml/GHSA-hmfx-3pcx-653p.yaml
- M internal/genericosv/testdata/yaml/GHSA-hv53-vf5m-8q94.yaml
- M internal/genericosv/testdata/yaml/GHSA-jh36-q97c-9928.yaml
- M internal/genericosv/testdata/yaml/GHSA-jmp2-wc4p-wfh2.yaml
- A internal/genericosv/testdata/yaml/GHSA-m99c-q26r-m7m7.yaml
- M internal/genericosv/testdata/yaml/GHSA-pg5p-wwp8-97g8.yaml
- M internal/genericosv/testdata/yaml/GHSA-pmfr-63c2-jr5c.yaml
- M internal/genericosv/testdata/yaml/GHSA-v6rw-hhgg-wc4x.yaml
- M internal/genericosv/testdata/yaml/GHSA-vp35-85q5-9f25.yaml
- M internal/genericosv/testdata/yaml/GHSA-w4xh-w33p-4v29.yaml
- M internal/genericosv/testdata/yaml/GHSA-wx8q-rgfr-cf6v.yaml
- M internal/genericosv/testdata/yaml/GHSA-xmg8-99r8-jc2j.yaml
- M internal/genericosv/testdata/yaml/GHSA-xx9w-464f-7h6f.yaml
- M internal/report/lint.go
- M internal/report/new.go
Change size: XL
Delta: 51 files changed, 218 insertions(+), 1092 deletions(-)
Related details
Attention set is empty
Submit Requirements:
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Tatiana Bradley (Gerrit)
Jun 26, 2024, 4:33:27 PM6/26/24
to goph...@pubsubhelper.golang.org, golang-co...@googlegroups.com
Attention needed from Tatiana Bradley
Tatiana Bradley uploaded new patchset![]( "Open in Gerrit")
Tatiana Bradley uploaded patch set #2 to this change.
Following approvals got outdated and were removed:
- LUCI-Pass: LUCI-TryBot-Result-1 by Go LUCI
- TryBots-Pass: LUCI-TryBot-Result-1 by Go LUCI
Related details
Attention is currently required from:
- Tatiana Bradley
Submit Requirements:
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Tatiana Bradley (Gerrit)
Jun 27, 2024, 1:28:23 PM6/27/24
to goph...@pubsubhelper.golang.org, golang-co...@googlegroups.com
Attention needed from Tatiana Bradley
Tatiana Bradley uploaded new patchset![]( "Open in Gerrit")
Tatiana Bradley uploaded patch set #4 to this change.
Following approvals got outdated and were removed:
- LUCI-Pass: LUCI-TryBot-Result-1 by Go LUCI
- TryBots-Pass: LUCI-TryBot-Result-1 by Go LUCI
Related details
Attention is currently required from:
- Tatiana Bradley
Submit Requirements:
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Tatiana Bradley (Gerrit)
Jun 27, 2024, 2:25:13 PM6/27/24
to goph...@pubsubhelper.golang.org, golang-co...@googlegroups.com
Attention needed from Tatiana Bradley
Tatiana Bradley uploaded new patchset![]( "Open in Gerrit")
Tatiana Bradley uploaded patch set #5 to this change.
Following approvals got outdated and were removed:
- LUCI-Pass: LUCI-TryBot-Result-1 by Go LUCI
- TryBots-Pass: LUCI-TryBot-Result-1 by Go LUCI
Related details
Attention is currently required from:
- Tatiana Bradley
Submit Requirements:
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Damien Neil (Gerrit)
Jun 27, 2024, 5:56:34 PM6/27/24
to Tatiana Bradley, goph...@pubsubhelper.golang.org, Go LUCI, golang-co...@googlegroups.com
Attention needed from Tatiana Bradley
Damien Neil voted Code-Review+2![]( "Open in Gerrit")
| Code-Review | +2 |
Related details
Attention is currently required from:
- Tatiana Bradley
Submit Requirements:
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Tatiana Bradley (Gerrit)
Jun 28, 2024, 11:28:17 AM6/28/24
to goph...@pubsubhelper.golang.org, golang-...@googlegroups.com, Damien Neil, Go LUCI, golang-co...@googlegroups.com
Tatiana Bradley submitted the change![]( "Open in Gerrit")
Change information
Commit message:
internal/report: move some functionality from vulnreport to report.New
Move removal of description and packages (for UNREVIEWED reports)
to report.New so that these actions can be tested more easily.
Change-Id: Ie533f3ef5642f0866c91c28010482eec1d844739
Reviewed-on: https://go-review.googlesource.com/c/vulndb/+/595275
LUCI-TryBot-Result: Go LUCI <golang...@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dn...@google.com>
Files:
- M cmd/issue/main.go
- M cmd/vulnreport/creator.go
- M internal/cve4/testdata/cve/TestToReport/CVE-2020-9283.txtar
- M internal/cve4/testdata/cve/TestToReport/CVE-2021-27919.txtar
- M internal/cve4/testdata/cve/TestToReport/CVE-2021-3115.txtar
- M internal/cve4/testdata/cve/TestToReport/CVE-2022-39213.txtar
- M internal/cve4/testdata/cve/TestToReport/CVE-2023-29407.txtar
- M internal/cve4/testdata/cve/TestToReport/CVE-2023-44378.txtar
- M internal/cve4/testdata/cve/TestToReport/CVE-2023-45141.txtar
- M internal/cve4/testdata/cve/TestToReport/CVE-2023-45283.txtar
- M internal/cve4/testdata/cve/TestToReport/CVE-2023-45285.txtar
- M internal/cve4/testdata/cve/TestToReport/CVE-2023-45286.txtar
- M internal/cve4/testdata/proxy/TestToReport.json
- M internal/ghsa/ghsa2report_test.go
- M internal/ghsa/testdata/proxy/TestGHSAToReport.json
- M internal/report/lint.go
- M internal/report/new.go
- M internal/report/testdata/proxy/TestFixModules/preserve_major.json
- M internal/worker/store/fire_store.go
- M internal/worker/store/store.go
- M internal/worker/worker.go
- M internal/worker/worker_test.go
Change size: XL
Delta: 70 files changed, 285 insertions(+), 1266 deletions(-)
Branch: refs/heads/master
Submit Requirements:
Code-Review: +2 by Damien Neil
TryBots-Pass: LUCI-TryBot-Result+1 by Go LUCI
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Reply all
Reply to author
Forward
0 new messages