Skip to content

Commit 8e96754

Browse files

File tree

6 files changed

+20
-12
lines changed

6 files changed

+20
-12
lines changed

advisories/github-reviewed/2019/04/GHSA-mh33-7rrq-662w/GHSA-mh33-7rrq-662w.json

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -69,6 +69,10 @@
6969
"type": "WEB",
7070
"url": "https://lists.debian.org/debian-lts-announce/2021/06/msg00015.html"
7171
},
72+
{
73+
"type": "WEB",
74+
"url": "https://lists.debian.org/debian-lts-announce/2023/10/msg00012.html"
75+
},
7276
{
7377
"type": "WEB",
7478
"url": "https://lists.fedoraproject.org/archives/list/[email protected]/message/NKGPJLVLVYCL4L4B4G5TIOTVK4BKPG72/"

advisories/github-reviewed/2023/10/GHSA-9pc8-m4vp-ggvf/GHSA-9pc8-m4vp-ggvf.json

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-9pc8-m4vp-ggvf",
4-
"modified": "2023-10-19T17:05:16Z",
4+
"modified": "2023-10-19T19:35:40Z",
55
"published": "2023-10-19T17:05:16Z",
66
"aliases": [
7-
7+
"CVE-2023-45822"
88
],
99
"summary": "Artifact Hub allows unsafe rego built-in",
1010
"details": "### Impact\n\nDuring a security audit of Artifact Hub's code base, a security researcher at [OffSec](https://www.offsec.com/) identified a bug in which a default unsafe rego built-in was allowed to be used when defining authorization policies.\n\nArtifact Hub includes a fine-grained authorization mechanism that allows organizations to define what actions can be performed by their members. It is based on customizable authorization policies that are enforced by the [Open Policy Agent](https://www.openpolicyagent.org/). Policies are written using [rego](https://www.openpolicyagent.org/docs/latest/#rego) and their data files are expected to be json documents. By default, `rego` allows policies to make HTTP requests, which can be abused to send requests to internal resources and forward the responses to an external entity. In the context of Artifact Hub, this capability should have been disabled.\n\n### Patches\n\nThis issue has been resolved in version [1.16.0](https://artifacthub.io/packages/helm/artifact-hub/artifact-hub?modal=changelog&version=1.16.0).",

advisories/github-reviewed/2023/10/GHSA-g6pq-x539-7w4j/GHSA-g6pq-x539-7w4j.json

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-g6pq-x539-7w4j",
4-
"modified": "2023-10-19T17:04:50Z",
4+
"modified": "2023-10-19T19:35:35Z",
55
"published": "2023-10-19T17:04:50Z",
66
"aliases": [
7-
7+
"CVE-2023-45821"
88
],
99
"summary": "Artifact Hub has Incorrect Docker Hub registry check",
1010
"details": "### Impact\n\nDuring a security audit of Artifact Hub's code base, a security researcher at [OffSec](https://www.offsec.com/) identified a bug in which the `registryIsDockerHub` function was only checking that the registry domain had the `docker.io` suffix.\n\nArtifact Hub allows providing some Docker credentials that are used to increase the rate limit applied when interacting with the Docker Hub registry API to read publicly available content. Due to the incorrect check described above, it'd be possible to hijack those credentials by purchasing a domain which ends with `docker.io` and deploying a fake OCI registry on it.\n\n<https://artifacthub.io/> uses some credentials that only have permissions to read public content available in the Docker Hub. However, even though credentials for private repositories (disabled on `artifacthub.io`) are handled in a different way, other Artifact Hub deployments could have been using them for a different purpose.\n\n### Patches\n\nThis issue has been resolved in version [1.16.0](https://artifacthub.io/packages/helm/artifact-hub/artifact-hub?modal=changelog&version=1.16.0).",

advisories/github-reviewed/2023/10/GHSA-hmq4-c2r4-5q8h/GHSA-hmq4-c2r4-5q8h.json

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-hmq4-c2r4-5q8h",
4-
"modified": "2023-10-19T17:06:42Z",
4+
"modified": "2023-10-19T19:35:45Z",
55
"published": "2023-10-19T17:06:42Z",
66
"aliases": [
7-
7+
"CVE-2023-45823"
88
],
99
"summary": "Artifact Hub arbitrary file read vulnerability",
1010
"details": "### Impact\n\nDuring a security audit of Artifact Hub's code base, a security researcher at [OffSec](https://www.offsec.com/) identified a bug in which by using symbolic links in certain kinds of repositories loaded into Artifact Hub, it was possible to read internal files.\n\nArtifact Hub indexes content from a variety of sources, including git repositories. When processing git based repositories, Artifact Hub clones the repository and, depending on the artifact kind, reads some files from it. During this process, in some cases, no validation was done to check if the file was a symbolic link. This made possible to read arbitrary files in the system, potentially leaking sensitive information.\n\n### Patches\n\nThis issue has been resolved in version [1.16.0](https://artifacthub.io/packages/helm/artifact-hub/artifact-hub?modal=changelog&version=1.16.0).",

advisories/github-reviewed/2023/10/GHSA-q24m-6h38-5xj8/GHSA-q24m-6h38-5xj8.json

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-q24m-6h38-5xj8",
4-
"modified": "2023-10-19T17:10:00Z",
4+
"modified": "2023-10-19T19:35:57Z",
55
"published": "2023-10-19T17:10:00Z",
66
"aliases": [
7-
7+
"CVE-2023-45825"
88
],
99
"summary": "ydb-go-sdk token in custom credentials object can leak through logs",
1010
"details": "### Impact\nSince [ydb-go-sdk/v3.48.6](https://github.com/ydb-platform/ydb-go-sdk/blob/v3.48.6/internal/balancer/balancer.go#L71) if you use a custom credentials object (implementation of interface [Credentials](https://github.com/ydb-platform/ydb-go-sdk/blob/master/credentials/credentials.go#L10)) it may leak into logs. This happens because this object could be serialized into an error message using `fmt.Errorf(\"something went wrong (credentials: %q)\", credentials)` during connection to the YDB server. Printf func use placeholder `%q` for string representation of argument with quotes. If an argument implements interface `fmt.Stringer`, it will used through `String()` func. In other cases used fallback - serialization with reflection.\n\nIf such logging occurred, a malicious user with access to logs could read sensitive information (i.e. credentials) information and use it to get access to the database.\n\nWho is impacted: applications with custom credentials object with an explicit token field.\n\nA leak could have occurred if all of these conditions were met simultaneously:\n1) The credentials object does not implement the `fmt.Stringer` interface (does not have a `String()` method) - potentially these are custom credentials. Official credentials have a `String()` method.\n2) There was an error connecting to YDB during driver creation via `ydb.Open(...)`.\n3) Some logging system was configured (`ydb-go-sdk` does not log such errors by default).\n4) The connection error was logged into a system that a malicious user had access to.\n\n### Patches\n`ydb-go-sdk` contains this problem in versions from v3.48.6 to v3.53.2. The fix for this problem has been released in version v3.53.3 ([PR](https://github.com/ydb-platform/ydb-go-sdk/pull/859)).\n\n### Workarounds\nImplement the `fmt.Stringer` interface in your custom credentials type with explicit stringify of object state.\n\n### References\nNo public references.\n",

advisories/github-reviewed/2023/10/GHSA-rp6x-ggw6-8g56/GHSA-rp6x-ggw6-8g56.json

Lines changed: 8 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,15 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-rp6x-ggw6-8g56",
4-
"modified": "2023-10-17T14:23:26Z",
4+
"modified": "2023-10-19T19:36:24Z",
55
"published": "2023-10-16T09:30:19Z",
66
"aliases": [
77
"CVE-2023-43668"
88
],
99
"summary": "Authorization Bypass in Apache InLong",
1010
"details": "Authorization Bypass Through User-Controlled Key vulnerability in Apache InLong.This issue affects Apache InLong: from 1.4.0 through 1.8.0, \n\nsome sensitive params checks will be bypassed, like \"autoDeserizalize\",\"allowLoadLocalInfile\"....\n\n.  \n\nUsers are advised to upgrade to Apache InLong's 1.9.0 or cherry-pick [1] to solve it.\n\n[1]  https://github.com/apache/inlong/pull/8604 \n\n",
1111
"severity": [
12-
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
15+
}
1316
],
1417
"affected": [
1518
{
@@ -57,9 +60,10 @@
5760
],
5861
"database_specific": {
5962
"cwe_ids": [
60-
"CWE-502"
63+
"CWE-502",
64+
"CWE-639"
6165
],
62-
"severity": "MODERATE",
66+
"severity": "CRITICAL",
6367
"github_reviewed": true,
6468
"github_reviewed_at": "2023-10-17T14:23:26Z",
6569
"nvd_published_at": null

0 commit comments

Comments
 (0)