TQRG/raw-osv-data huggingface dataset:
Vulnerability: GHSA-q9x4-q76f-5h5j
Summary: Unauthenticated users can exploit an enumeration vulnerability in Harbor (CVE-2019-19030)
Aliases: CVE-2019-19030
Severity: LOW
Published: 2022-02-11T23:17:25Z

# Impact
Sean Wright from Secureworks has discovered an enumeration vulnerability. An attacker can make use of the Harbor API to make unauthenticated calls to the Harbor instance. Based on the HTTP status code in the response, an attacker is then able to work out which resources exist, and which do not. This would likely be accomplished by either providing a wordlist or enumerating through a sequence an
unauthenticated attacker is able to enumerate resources on the system. This provides them with information such as existing projects, repositories, etc.

The vulnerability was immediately fixed by the Harbor team.  

# Issue 
The following API resources where found to be vulnerable to enumeration attacks:
/api/chartrepo/{repo}/prov (POST)
/api/chartrepo/{repo}/charts (GET, POST)
/api/chartrepo/{repo}/charts/{name} (GET, DELETE)
/api/chartrepo/{repo}/charts/{name}/{version} (GET, DELETE)
/api/labels?name={name}&scope=p (GET)
/api/repositories?project_id={id} (GET)
/api/repositories/{repo_name}/ (GET, PUT, DELETE)
/api/repositories/{repo_name}/tags (GET)
/api/repositories/{repo_name}/tags/{tag}/manifest?version={version} (GET)
/api/repositories/{repo_name/{tag}/labels (GET)
/api/projects?project_name={name} (HEAD)
/api/projects/{project_id}/summary (GET)
/api/projects/{project_id}/logs (GET)
/api/projects/{project_id} (GET, PUT, DELETE)
/api/projects/{project_id}/metadatas (GET, POST)
/api/projects/{project_id}/metadatas/{metadata_name} (GET, PUT)

# Known Attack Vectors
Successful exploitation of this issue will lead to bad actors identifying which resources exist in Harbor without requiring authentication for the Harbor API.

# Patches
If your product uses the affected releases of Harbor, update to version 1.10.3 or 2.0.1 to patch this issue immediately.

https://github.com/goharbor/harbor/releases/tag/v1.10.3
https://github.com/goharbor/harbor/releases/tag/v2.0.1

# Workarounds
There is no known workaround

# For more information
If you have any questions or comments about this advisory, contact cncf-harbor-security@lists.cncf.io
View our security policy at https://github.com/goharbor/harbor/security/policy
Vulnerability: GHSA-r9w6-rhh9-7v53
Summary: Incorrect Authorization in HashiCorp Consul
Aliases: CVE-2020-7955
Severity: MODERATE
CWE: CWE-863
Published: 2021-07-28T17:57:57Z

HashiCorp Consul and Consul Enterprise 1.4.1 through 1.6.2 did not uniformly enforce ACLs across all API endpoints, resulting in potential unintended information disclosure. Fixed in 1.6.3.
Vulnerability: GHSA-65f3-3278-7m65
Summary: Improper Authorization in Gogs
Aliases: CVE-2022-0871
Severity: HIGH
CWE: CWE-863, CWE-285
Published: 2022-03-12T00:00:34Z

### Impact

Expired PAM accounts and accounts with expired passwords are continued to be seen as valid. Installations use PAM as authentication sources are affected.

### Patches

Expired PAM accounts and accounts with expired passwords are no longer being seen as valid. Users should upgrade to 0.12.5 or the latest 0.13.0+dev.

### Workarounds

In addition to marking PAM accounts as expired, also disable/lock them. Running `usermod -L <username>` will add an exclamation mark to the password hash and would result in wrong passwords responses when trying to login. 

### References

https://huntr.dev/bounties/ea82cfc9-b55c-41fe-ae58-0d0e0bd7ab62/

### For more information

If you have any questions or comments about this advisory, please post on https://github.com/gogs/gogs/issues/6810.
Vulnerability: GHSA-6g5f-f5pm-mjrg
Summary: Vulnerability in Istio
Aliases: CVE-2019-12243
Severity: HIGH
CWE: CWE-284
Published: 2022-02-15T01:57:18Z

Istio 1.1.x through 1.1.6 has Incorrect Access Control.
Vulnerability: GHSA-qhm4-jxv7-j9pq
Summary: Allocation of Resources Without Limits or Throttling and Uncontrolled Memory Allocation in Kubernetes
Aliases: CVE-2020-8551
Severity: LOW
CWE: CWE-789
Published: 2022-02-15T01:57:18Z

The Kubelet component in versions 1.15.0-1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via the kubelet API, including the unauthenticated HTTP read-only API typically served on port 10255, and the authenticated HTTPS API typically served on port 10250.
Vulnerability: GHSA-82hx-w2r5-c2wq
Summary: Allocation of Resources Without Limits or Throttling and Uncontrolled Memory Allocation in Kubernetes
Aliases: CVE-2020-8552
Severity: MODERATE
CWE: CWE-789, CWE-400
Published: 2022-02-15T01:57:18Z

The Kubernetes API server component in versions prior to 1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via successful API requests.
Vulnerability: GHSA-fqh4-rh59-xhvf
Summary: Denial of service
Aliases: CVE-2021-23351
Severity: MODERATE
CWE: CWE-400
Published: 2021-05-18T21:07:43Z

The package `github.com/pires/go-proxyproto` before 0.5.0 are vulnerable to Denial of Service (DoS) via the parseVersion1() function. The reader in this package is a default bufio.Reader wrapping a net.Conn. It will read from the connection until it finds a newline. Since no limits are implemented in the code, a deliberately malformed V1 header could be used to exhaust memory in a server process using this code - and create a DoS. This can be exploited by sending a stream starting with PROXY and continuing to send data (which does not contain a newline) until the target stops acknowledging. The risk here is small, because only trusted sources should be allowed to send proxy protocol headers.
Vulnerability: GO-2021-0092
Aliases: CVE-2020-15222
Published: 2021-04-14T12:00:00Z

Uniqueness of JWT IDs (jti) are not checked, allowing the JWT to be
replayed.
Vulnerability: GO-2020-0036
Aliases: CVE-2019-11254
Published: 2021-04-14T12:00:00Z

Due to unbounded aliasing, a crafted YAML file can cause consumption
of significant system resources. If parsing user supplied input, this
may be used as a denial of service vector.
Vulnerability: GHSA-jr9c-h74f-2v28
Summary: Improper Authorization in Gitea
Aliases: CVE-2022-0905
Severity: MODERATE
CWE: CWE-863, CWE-285
Published: 2022-03-11T00:02:35Z

Gitea 1.16.3 and prior is vulnerable to improper authorization. A patch is available and is anticipated to be part of the 1.16.4 release.
Vulnerability: GHSA-c72p-9xmj-rx3w
Summary: Archive package allows chmod of file outside of unpack target directory
Aliases: CVE-2021-32760
Severity: MODERATE
CWE: CWE-668
Published: 2021-07-26T21:17:45Z

## Impact

A bug was found in containerd where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host’s filesystem.  Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky.  This bug does not directly allow files to be read, modified, or executed without an additional cooperating process.

## Patches

This bug has been fixed in containerd 1.5.4 and 1.4.8.  Users should update to these versions as soon as they are released.  Running containers do not need to be restarted.

## Workarounds

Ensure you only pull images from trusted sources.

Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with unexpected files.

## For more information

If you have any questions or comments about this advisory:

* [Open an issue](https://github.com/containerd/containerd/issues/new/choose)
* Email us at security@containerd.io if you think you’ve found a security bug.
Vulnerability: GHSA-xcqr-9h24-vrgw
Summary: Improper Restriction of Excessive Authentication Attempts in Argo API
Aliases: CVE-2020-8827
Severity: HIGH
CWE: CWE-307
Published: 2021-07-26T21:19:37Z

As of v1.5.0, the Argo API does not implement anti-automation measures such as rate limiting, account lockouts, or other anti-bruteforce measures. Attackers can submit an unlimited number of authentication attempts without consequence.
Vulnerability: GHSA-wjm3-fq3r-5x46
Summary: Denial of service
Aliases: CVE-2020-36066
Severity: MODERATE
CWE: CWE-400
Published: 2021-05-18T21:07:54Z

GJSON <1.6.5 allows attackers to cause a denial of service (remote) via crafted JSON.
Vulnerability: GHSA-8v99-48m9-c8pm
Summary: Incorrect Authorization in imgcrypt
Aliases: CVE-2022-24778
Severity: HIGH
CWE: CWE-863
Published: 2022-03-28T19:33:44Z

Imgcrypt implements a function `CheckAuthorization()` that is supposed to check whether a user is authorized to access an encrypted image given the keys that the user has provided on the command line that would enable decryption of the image. The check is to prevent that a user can start a container from an image that has previously been decrypted by another user on the same system and therefore a decrypted version of the image layers may be already available in the cache locally.

The failure occurs when an image with a ManifestList is used and the architecture of the local host is not the first one in the ManifestList. In the version prior to the fix, only the first architecture in the list was tested, which may not have its layers available locally (were not pulled) since it cannot be run on the host architecture. Therefore, the verdict on unavailable layers was that the image could be run anticipating that image run failure would occur later due to the layers not being available. However, this verdict to allow the image to run lead to other architectures in the ManifestList be able to run an image without providing keys if that image had previously been decrypted. The fixed version now skips over irrelevant architectures and tests the Manifest of the local architecture, if available.

Known projects that use the `CheckAuthorization()` of imgcrypt is for example the ctr-enc client tool provided by imgcrypt. In this implementation, the call to `CheckAuthorization()` is used on the client side and could therefore also be easily circumvented by a modified client tool not calling this function.

In relation to the vulnerability in ctr-enc, affected environments would have to allow different users to invoke ctr-enc indirectly using some sort of management stack that gives user indirect access to ctr-enc.

The patch has been applied to imgcrypt v1.1.4. Workarounds may include usage of different namespaces for each remote user.
Vulnerability: GHSA-grj5-8x6q-hc9q
Summary: Path traversal in Grafana Loki
Aliases: CVE-2021-36156
Severity: MODERATE
CWE: CWE-22
Published: 2021-09-02T22:00:40Z

An issue was discovered in Grafana Loki through 2.2.1. The header value X-Scope-OrgID is used to construct file paths for rules files, and if crafted to conduct directory traversal such as ae ../../sensitive/path/in/deployment pathname, then Loki will attempt to parse a rules file at that location and include some of the contents in the error message.
Vulnerability: GHSA-qqc5-rgcc-cjqh
Summary: Information Disclosure in go.elastic.co/apm
Aliases: CVE-2021-22133
Severity: LOW
CWE: CWE-532
Published: 2021-05-18T18:34:18Z

The Elastic APM agent for Go versions before 1.11.0 can leak sensitive HTTP header information when logging the details during an application panic. Normally, the APM agent will sanitize sensitive HTTP header details before sending the information to the APM server. During an application panic it is possible the headers will not be sanitized before being sent.
Vulnerability: GHSA-75qf-wgfj-v652
Summary: Arbitrary File Write via Archive Extraction (Zip Slip)
Aliases: CVE-2020-7669
Severity: HIGH
CWE: CWE-22
Published: 2021-05-18T18:28:03Z

This affects all versions up to and including version 7.0.0 of package github.com/u-root/u-root/pkg/tarutil. It is vulnerable to both leading and non-leading relative path traversal attacks in tar file extraction.
Vulnerability: GHSA-vmf7-hmh6-vv57
Summary: Denial of Service in Go-Ethereum
Aliases: CVE-2022-23328
Severity: HIGH
CWE: CWE-400
Published: 2022-03-05T00:00:46Z

A design flaw in all versions of Go-Ethereum allows an attacker node to send 5120 pending transactions of a high gas price from one account that all fully spend the full balance of the account to a victim Geth node, which can purge all of pending transactions in a victim node's memory pool and then occupy the memory pool to prevent new transactions from entering the pool, resulting in a denial of service (DoS).
Vulnerability: GHSA-w4x5-jqq4-qc8x
Summary: SQL Injection in Cloud Native Computing Foundation Harbor
Aliases: CVE-2019-19026
Severity: MODERATE
CWE: CWE-89
Published: 2021-05-18T18:27:43Z

Cloud Native Computing Foundation Harbor prior to 1.8.6 and 1.9.3 allows SQL Injection via project quotas in the VMware Harbor Container Registry for the Pivotal Platform.
Vulnerability: GHSA-f5f7-6478-qm6p
Summary: Files or Directories Accessible to External Parties in kubernetes
Aliases: CVE-2021-25741
Severity: HIGH
CWE: CWE-20, CWE-552
Published: 2021-11-01T17:32:28Z

A security issue was discovered in Kubernetes where a user may be able to create a container with subpath volume mounts to access files & directories outside of the volume, including on the host filesystem.
Vulnerability: GO-2021-0084
Aliases: CVE-2019-16354
Published: 2021-04-14T12:00:00Z

Session data is stored using permissive permissions, allowing local users
with filesystem access to read arbitary data.
Vulnerability: GHSA-j6wp-3859-vxfg
Summary: OIDC claims not updated from Identity Provider in Pomerium
Aliases: CVE-2021-41230
Severity: MODERATE
CWE: CWE-863
Published: 2021-11-10T16:52:24Z

### Impact
Changes to the OIDC claims of a user after initial login are not reflected in policy evaluation when using [`allowed_idp_claims`](https://www.pomerium.com/reference/#allowed-idp-claims) as part of policy.  If using `allowed_idp_claims` and a user's claims are changed, Pomerium can make incorrect authorization decisions.

### Patches
v0.15.6

### Workarounds
- Clear data on `databroker` service by clearing redis or restarting the in-memory databroker to force claims to be updated

### References
https://github.com/pomerium/pomerium/pull/2724

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [Pomerium](https://github.com/pomerium/pomerium)
* Email us at [security@pomerium.com](mailto:security@pomerium.com)
Vulnerability: GHSA-5wjf-62hw-q78r
Summary: Excessive CPU usage
Aliases: CVE-2021-39204
Severity: HIGH
CWE: CWE-834
Published: 2021-09-10T17:54:13Z

Envoy, which Pomerium is based on, incorrectly handles resetting of HTTP/2 streams with excessive complexity.  This can lead to high CPU utilization when a large number of streams are reset.  

### Impact

This can result in a DoS condition.

### Patches
Pomerium versions 0.14.8 and 0.15.1 contain an upgraded envoy binary with this vulnerability patched.

### Workarounds
N/A

### References
[envoy GSA](https://github.com/envoyproxy/envoy/security/advisories/GHSA-3xh3-33v5-chcc)
[envoy CVE](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32778)
[envoy announcement](https://groups.google.com/g/envoy-announce/c/5xBpsEZZDfE/m/wD05NZBbAgAJ)

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [pomerium/pomerium](https://github.com/pomerium/pomerium/issues)
* Email us at [security@pomerium.com](mailto:security@pomerium.com)
Vulnerability: GHSA-f9fq-vjvh-779p
Summary: Improper Input Validation in vault-ssh-helper
Aliases: CVE-2020-24359
Severity: HIGH
CWE: CWE-20
Published: 2022-02-15T01:57:18Z

HashiCorp vault-ssh-helper up to and including version 0.1.6 incorrectly accepted Vault-issued SSH OTPs for the subnet in which a host's network interface was located, rather than the specific IP address assigned to that interface. Fixed in 0.2.0.
Vulnerability: GHSA-h2fg-54x9-5qhq
Summary: Nil dereference in NATS JWT, DoS of nats-server
Aliases: CVE-2020-26521
Severity: LOW
CWE: CWE-476
Published: 2022-02-11T23:43:13Z

## Problem Description

The NATS account system has an Operator trusted by the servers, which signs Accounts, and each Account can then create and sign Users within their account.  The Operator should be able to safely issue Accounts to other entities which it does not fully trust.

A malicious Account could create and sign a User JWT with a state not created by the normal tooling, such that decoding by the NATS JWT library (written in Go) would attempt a nil dereference, aborting execution.

The NATS Server is known to be impacted by this.


## Affected versions

#### JWT library

 * all versions prior to 1.1.0

#### NATS Server

 * Version 2 prior to 2.1.9


## Impact

#### JWT library

 * Programs would nil dereference and panic, aborting execution by default.

#### NATS server

 * Denial of Service caused by process termination


## Workaround

If your NATS servers do not trust any accounts which are managed by untrusted entities, then malformed User credentials are unlikely to be encountered.


## Solution

Upgrade the JWT dependency in any application using it.

Upgrade the NATS server if using NATS Accounts.
Vulnerability: GHSA-vw47-mr44-3jf9
Summary: Confused Deputy in Kubernetes
Aliases: CVE-2021-25740
Severity: LOW
CWE: CWE-441, CWE-610
Published: 2021-09-21T18:28:30Z

A security issue was discovered with Kubernetes that could enable users to send network traffic to locations they would otherwise not have access to via a confused deputy attack.
Vulnerability: GO-2020-0020
Published: 2021-04-14T12:00:00Z

Usage of the [`CORS`] handler may apply improper CORS headers, allowing
the requester to explicitly control the value of the Access-Control-Allow-Origin
header, which bypasses the expected behavior of the Same Origin Policy.
Vulnerability: GHSA-4fc7-hc63-7fjg
Summary: Exposure of repository credentials to external third-party sources in Rancher
Aliases: CVE-2021-36778
Severity: HIGH
CWE: CWE-200
Published: 2022-05-02T19:33:34Z

### Impact
This issue only happens when the user configures access credentials to a private repository in Rancher inside `Apps & Marketplace > Repositories`. It affects Rancher versions 2.5.0 up to and including 2.5.11 and from 2.6.0 up to and including 2.6.2.

An insufficient check of the same-origin policy when downloading Helm charts from a configured private repository can lead to exposure of the repository credentials to a third-party provider. This exposure happens when the private repository:

1. Does an HTTP redirect to a third-party repository or external storage provider.
2. Downloads an icon resource for the chart hosted on a third-party provider.

The address of the private repository is not leaked, only the credentials are leaked in the HTTP `Authorization` header in base64 format.

With the patched versions, the default behavior now is to only send the private repository credentials when subdomain or domain hostname match when following the redirect or downloading external resources.

### Patches
Patched versions include releases 2.5.12, 2.6.3 and later versions.

### Workarounds
1. Update Rancher to a patched version.
2. Check the Helm charts in your configured private repository for possible redirects to third-party storage, and for Helm chart icons from third-party sources.
3. Evaluate any Helm chart that might lead to the mentioned scenario and change affected credentials if deemed necessary.

### References
Information about the same-origin check and how to disable it is available in Rancher [documentation](https://rancher.com/docs/rancher/v2.6/en/helm-charts/#repositories).

### For more information
If you have any questions or comments about this advisory:
* Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
* Open an issue in [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
* Verify our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
Vulnerability: GHSA-6jqj-f58p-mrw3
Summary: Denial of Service in TenderMint
Aliases: CVE-2020-15091
Severity: MODERATE
CWE: CWE-347
Published: 2021-12-20T18:17:33Z

### Description

**Denial of Service**

Tendermint 0.33.0 and above allow block proposers to include signatures for the wrong block. This may happen naturally if you start a network, have it run for some time and restart it without changing the chainID. (It is a [misconfiguration](https://docs.tendermint.com/master/tendermint-core/using-tendermint.html) to reuse chainIDs.) Correct block proposers will accidentally include signatures for the wrong block if they see these signatures, and then commits won't validate, making all proposed blocks invalid. A malicious validator (even with a minimal amount of stake) can use this vulnerability to completely halt the network.

Tendermint 0.33.6 checks all the signatures are for the block with +2/3 majority before creating a commit.

**False Witness**

Tendermint 0.33.1 and above are no longer fully verifying commit signatures during block execution - they stop after +2/3. This means proposers can propose blocks that contain valid +2/3 signatures and then the rest of the signatures can be whatever they want. They can claim that all the other validators signed just by including a CommitSig with arbitrary signature data. While this doesn't seem to impact safety of Tendermint per se, it means that Commits may contain a lot of invalid data **.

_** This was already true of blocks, since they could include invalid txs filled with garbage, but in that case the application knew that they are invalid and could punish the proposer. But since applications didn't--and don't-- verify commit signatures directly (they trust Tendermint to do that), they won't be able to detect it._

This can impact incentivization logic in the application that depends on the LastCommitInfo sent in BeginBlock, which includes which validators signed. For instance, Gaia incentivizes proposers with a bonus for including more than +2/3 of the signatures. But a proposer can now claim that bonus just by including arbitrary data for the final -1/3 of validators without actually waiting for their signatures. There may be other tricks that can be played because of this.

Tendermint 0.33.6 verifies all the signatures during block execution ***.

_*** Please note that the light client does not check nil votes and exits as soon as 2/3+ of the signatures are checked._

### Impact

- All nodes
- The network stops due to having a commit with a wrong signature.

### Patches

- v0.33.6

### Workarounds

No workarounds.

### References

- https://github.com/tendermint/tendermint/issues/4926

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [tendermint/tendermint](https://github.com/tendermint/tendermint)
* Email us at [security@tendermint.com](mailto:security@tendermint.com)

More information can be found [here](https://tendermint.com/security/).
Vulnerability: GHSA-6h3m-36w8-hv68
Summary: Arbitrary file write in nats-server
Aliases: CVE-2022-26652
Severity: HIGH
CWE: CWE-22
Published: 2022-03-10T22:07:30Z

(This document is canonically: <https://advisories.nats.io/CVE/CVE-2022-26652.txt>)

## Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

JetStream is the optional RAFT-based resilient persistent feature of NATS.


## Problem Description

The JetStream streams can be backed up and restored via NATS. The backup format is a tar archive file.  Inadequate checks on the filenames within the archive file permit a so-called "Zip Slip" attack in the stream restore.

NATS nats-server through 2022-03-09 (fixed in release 2.7.4) did not correctly sanitize elements of the archive file, thus a user of NATS
could cause the NATS server to write arbitrary content to an attacker-controlled filename.


## Affected versions

NATS Server:
 * 2.2.0 up to and including 2.7.3.
   + Introduced with JetStream Restore functionality
 * Fixed with nats-io/nats-server: 2.7.4
 * Docker image:  nats <https://hub.docker.com/_/nats>
 * NB users of OS package files from our releases: a change in goreleaser defaults, discovered late in the release process, moved the install directory from /usr/local/bin to /usr/bin; we are evaluating the correct solution for subsequent releases, but not recutting this release.

NATS Streaming Server
 * 0.15.0 up to and including 0.24.2
 * Fixed with nats-io/nats-streaming-server: 0.24.3
 * Embeds a nats-server, but this server is the old approach which JetStream replaces, so unlikely (but not impossible) to be
   configured with JS support


## Workarounds

 * Disable JetStream for untrusted users.
 * If only one NATS account uses JetStream, such that cross-user attacks are not an issue, and any user in that account with access to the JetStream API is fully trusted anyway, then appropriate sandboxing techniques will prevent exploit.
   + Eg, with systemd, the supplied util/nats-server-hardened.service example configuration demonstrates that NATS runs fine as an unprivileged user under ProtectSystem=strict and PrivateTmp=true restrictions; by only opening a ReadWritePaths hole for the JetStream storage area, the impact of this vulnerability is limited.


## Solution

Upgrade the NATS server to at least 2.7.4.

We fully support the util/nats-server-hardened.service configuration for running a NATS server and encourage this approach.


## Credits

This issue was reported (on 2022-03-07) to the NATS Maintainers by
Yiming Xiang, TIANJI LAB of NSFOCUS.  
Thank you / 谢谢你！
Vulnerability: GHSA-74j8-88mm-7496
Summary: Confused Deputy in Kubernetes
Aliases: CVE-2020-8561
Severity: MODERATE
CWE: CWE-441, CWE-610
Published: 2021-09-21T18:28:21Z

A security issue was discovered in Kubernetes where actors that control the responses of MutatingWebhookConfiguration or ValidatingWebhookConfiguration requests are able to redirect kube-apiserver requests to private networks of the apiserver. If that user can view kube-apiserver logs when the log level is set to 10, they can view the redirected responses and headers in the logs.
Vulnerability: GHSA-58pf-pcwv-qg85
Summary: Path traversal
Aliases: CVE-2020-7665
Severity: MODERATE
CWE: CWE-22
Published: 2021-05-18T21:08:28Z

This affects all versions of package github.com/u-root/u-root/pkg/uzip. It is vulnerable to both leading and non-leading relative path traversal attacks in zip file extraction.
Vulnerability: GHSA-8c26-wmh5-6g9v
Summary: Use of a Broken or Risky Cryptographic Algorithm in golang.org/x/crypto/ssh
Aliases: CVE-2022-27191
Severity: HIGH
CWE: CWE-327
Published: 2022-03-19T00:01:02Z

golang.org/x/crypto/ssh versions 0.0.0-20220214200702-86341886e292 and prior in Go through 1.16.15 and 1.17.x through 1.17.8 allows an attacker to crash a server in certain circumstances involving AddHostKey. Version 0.0.0-20220315160706-3147a52a75dd includes a fix for the vulnerability and support for SHA-2.
Vulnerability: GO-2020-0016
Aliases: CVE-2021-29482
Published: 2021-04-14T12:00:00Z

An attacker can construct a series of bytes such that calling
[`Reader.Read`] on the bytes could cause an infinite loop. If
parsing user supplied input, this may be used as a denial of
service vector.
Vulnerability: GHSA-23fq-q7hc-993r
Summary: Improper Preservation of Permissions in HashiCorp Vault
Aliases: CVE-2021-38553
Severity: CRITICAL
CWE: CWE-281
Published: 2021-08-30T17:22:53Z

HashiCorp Vault and Vault Enterprise 1.4.0 through 1.7.3 initialized an underlying database file associated with the Integrated Storage feature with excessively broad filesystem permissions. Fixed in Vault and Vault Enterprise 1.8.0.
Vulnerability: GHSA-hqxw-mm44-gc4r
Summary: Fragments in Path May Lead to Authorization Policy Bypass
Aliases: CVE-2021-39156
Severity: HIGH
CWE: CWE-863
Published: 2021-08-30T16:16:14Z

### Impact
Istio 1.11.0, 1.10.3 and below, and 1.9.7 and below contain a remotely exploitable vulnerability where an HTTP request with `#fragment` in the path may bypass Istio’s URI path based authorization policies. 

### Patches
* Istio 1.11.1 and above
* Istio 1.10.4 and above
* Istio 1.9.8 and above

### Workarounds
A Lua filter may be written to normalize the path.  This is similar to the Path normalization presented in the [Security Best Practices](https://istio.io/latest/docs/ops/best-practices/security/#case-normalization) guide.

### References
More details can be found in the [Istio Security Bulletin](https://istio.io/latest/news/security/istio-security-2021-008)

### For more information
If you have any questions or comments about this advisory, please email us at istio-security-vulnerability-reports@googlegroups.com
Vulnerability: GHSA-5m6c-jp6f-2vcv
Summary: Open Redirect in OAuth2 Proxy
Aliases: CVE-2020-4037
Severity: MODERATE
CWE: CWE-601
Published: 2021-12-20T17:58:59Z

### 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.
Vulnerability: GHSA-fv82-r8qv-ch4v
Summary: pomerium_signature is not verified in middleware in github.com/pomerium/pomerium
Aliases: CVE-2021-29652
Severity: HIGH
CWE: CWE-601
Published: 2021-05-21T16:24:22Z

### 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 [security@pomerium.com](mailto:security@pomerium.com)
Vulnerability: GO-2020-0041
Aliases: CVE-2020-7668
Published: 2021-04-14T12:00:00Z

Due to improper path santization, archives containing relative file
paths can cause files to be written (or overwritten) outside of the
target directory.
Vulnerability: GHSA-jm34-xm8m-w958
Summary: Open Redirect in oauth2_proxy
Aliases: CVE-2017-1000070
Severity: MODERATE
CWE: CWE-601
Published: 2021-12-20T18:04:40Z

The Bitly oauth2_proxy in version 2.1 and earlier was affected by an open redirect vulnerability during the start and termination of the 2-legged OAuth flow. This issue was caused by improper input validation and a violation of RFC-6819
Vulnerability: GHSA-m836-gxwq-j2pm
Summary: Improper Access Control in github.com/treeverse/lakefs
Severity: MODERATE
CWE: CWE-284
Published: 2021-10-28T16:27:03Z

### Impact

1. [medium] A user with write permissions to a portion of a repository may use the S3 gateway to copy any object in the repository if they know its name.
1. [medium] A user with permission to write any one of tags, branches, or commits on a repository may write all of them.
1. [low] A user with permission to read any one of tags, branches, or commits on a repository may read all of them.
1. [low] A user allowed to list objects in a repository _or_ read repository meta-data may retrieve graveler information about the location on underlying storage of all objects stored in any commit that they can view.  If the user additionally has the capability to read underlying storage, they will be able to retrieve metadata associated with all objects in that commit.

### For more information

If you have any questions or comments about this advisory please:
* Email us at security@treeverse.io.
* Open an issue on https://github.com/treeverse/lakeFS/issues/new.
Vulnerability: GHSA-g9wh-3vrx-r7hg
Summary: OctoRPKI crashes when processing GZIP bomb returned via malicious repository
Aliases: CVE-2021-3912
Severity: MODERATE
CWE: CWE-400
Published: 2021-11-10T20:39:23Z

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 security@cloudflare.com
Vulnerability: GO-2021-0071
Aliases: CVE-2015-1340
Published: 2021-04-14T12:00:00Z

A race between chown and chmod operations during a container filesystem shift
may allow a user who can modify the filesystem to chmod an arbitary path of
their choice, rather than the expected path.
Vulnerability: GHSA-w6v2-qchm-grj7
Summary: Insecure permissions on user namespace / fakeroot temporary rootfs in Singularity
Aliases: CVE-2020-25039
Severity: HIGH
CWE: CWE-732, CWE-668
Published: 2021-12-20T18:25:46Z

### Impact

Insecure permissions on temporary directories used in fakeroot or user namespace container execution.

When a Singularity action command (run, shell, exec) is run with the fakeroot or user namespace option, Singularity will extract a container image to a temporary sandbox directory. Due to insecure permissions on the temporary directory it is possible for any user with access to the system to read the contents of the image. Additionally, if the image contains a world-writable file or directory, it is possible for a user to inject arbitrary content into the running container.

### Patches

This issue is addressed in Singularity 3.6.3.

All users are advised to upgrade to 3.6.3.

### Workarounds

The issue is mitigated if `TMPDIR` is set to a location that is only accessible to the user, as any subdirectories directly under `TMPDIR` cannot then be accessed by others. However, this is difficult to enforce so it is not recommended to rely on this as a mitigation.

### 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: security@sylabs.io

See our Security Policy here: https://sylabs.io/security-policy
Vulnerability: GHSA-4mf2-f3wh-gvf2
Summary: Subdomain checking of whitelisted domains could allow unintended redirects in oauth2-proxy
Aliases: CVE-2021-21291
Severity: LOW
CWE: CWE-601
Published: 2021-05-25T18:42:20Z

### Impact
_What kind of vulnerability is it? Who is impacted?_
For users that use the whitelist domain feature, a domain that ended in a similar way to the intended domain could have been allowed as a redirect.

For example, if a whitelist domain was configured for `.example.com`, the intention is that subdomains of `example.com` are allowed.
Instead, `example.com` and `badexample.com` could also match.

### Patches
_Has the problem been patched? What versions should users upgrade to?_
This is fixed in version 7.0.0 onwards.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
Disable the whitelist domain feature and run separate OAuth2 Proxy instances for each subdomain.

# Original Issue Posted by @semoac:

Whitelist Domain feature is not working as expected because is not matching a dot to ensure the redirect is a subdomain.

## Expected Behavior

If whitelist domain is set to `.example.com` , then `hack.alienexample.com`  should be rejected as a valid redirect.

## Current Behavior

The code is removing the `dot`  from `.example.com`  and  only checking if the redirect string end with `example.com`

## Possible Solution
Here
https://github.com/oauth2-proxy/oauth2-proxy/blob/c377466411f2aee180a732187edb638f2f7e57fb/oauthproxy.go#L661

Include the dot when checking the string:
```
strings.HasSuffix(redirectHostname, "." + domainHostname)
```

## Steps to Reproduce (for bugs)

```
package main

import (
	"fmt"
	"strings"
)

func validOptionalPort(port string) bool {
	if port == "" || port == ":*" {
		return true
	}
	if port[0] != ':' {
		return false
	}
	for _, b := range port[1:] {
		if b < '0' || b > '9' {
			return false
		}
	}
	return true
}

func splitHostPort(hostport string) (host, port string) {
	host = hostport

	colon := strings.LastIndexByte(host, ':')
	if colon != -1 && validOptionalPort(host[colon:]) {
		host, port = host[:colon], host[colon+1:]
	}

	if strings.HasPrefix(host, "[") && strings.HasSuffix(host, "]") {
		host = host[1 : len(host)-1]
	}

	return
}

func main() {
	domain := ".example.com"
	domainHostname, _ := splitHostPort(strings.TrimLeft(domain, "."))
	redirectHostname := "https://hack.alienexample.com"
	if (strings.HasPrefix(domain, ".") && strings.HasSuffix(redirectHostname, domainHostname)) { fmt.Println("This should not have happen.")}
}

```

Users of `github.com/oauth2-proxy/oauth2-proxy` are advised to update to `github.com/oauth2-proxy/oauth2-proxy/v7`
Vulnerability: GHSA-c8x3-rg72-fwwg
Summary: Privilege escalation in Hashicorp Nomad
Aliases: CVE-2021-37218
Severity: HIGH
CWE: CWE-295
Published: 2021-09-08T20:14:38Z

HashiCorp Nomad and Nomad Enterprise Raft RPC layer allows non-server agents with a valid certificate signed by the same CA to access server-only functionality, enabling privilege escalation. Fixed in 1.0.10 and 1.1.4.
Vulnerability: GHSA-fx5p-f64h-93xc
Summary:  Opened exploitable ports in default docker-compose.yaml in go-ipfs
Severity: MODERATE
Published: 2022-04-04T21:23:55Z

### Impact

Allows admin API access to the IPFS node.

### Who ?

This affects people running the  [docker-compose.yaml](https://github.com/ipfs/go-ipfs/blob/master/docker-compose.yaml) service in an environment where the docker host is directly attached to a public or untrusted IP.  In the vulnerable version, the private API endpoint is publicly forwarded by exposing it as `0.0.0.0:5001` on the host machine.  

If the host machine is hidden behind a firewall or NAT (and the LAN is trusted for NAT), this is not an immediate issue because of the protection from the firewall or NAT.  That said, we still recommend users update to follow security best practices of not putting unnecessary dependency on a working firewall.

### Patches
This issue is in [docker-compose.yaml](https://github.com/ipfs/go-ipfs/blob/master/docker-compose.yaml).  Users need to replace their current `docker-compose.yaml` file with a version `0.12.1` or later.

There is no need to update any of the binaries. Users running previous versions like `0.12.0` or earlier can download the `0.12.1` `docker-compose.yaml` file.  You can replace a vulnerable `docker-compose.yaml` file with a the new one with:

```
curl https://raw.githubusercontent.com/ipfs/go-ipfs/v0.12.1/docker-compose.yaml > docker-compose.yaml
```

### How to test if you are vulnerable
#### Binding check on the host
On the host machine, while IPFS is running, run as root:

```bash
netstat -lnp | grep ":5001"
```

The output will be a list of listeners bound to `:5001`.
You then need to check that those listeners are private and preferably even localhost IPs.
⚠️ If this listener is on `0.0.0.0` or a public IP you are very likely vulnerable.

#### Remote hailing
While IPFS is running, you can try to contact the API from a remote machine. (Replace `1.2.3.4` with your node public IP.  Or if you want to test in an untrusted NAT, then substitute the LAN IP instead.)

```bash
curl -X POST http://1.2.3.4:5001/api/v0/version
```

⚠️ If you see any json outputted (e.g.,  `{"Commit": "<string>","Golang": "<string>","Repo": "<string>","System": "<string>","Version": "<string>"}`), then you are vulnerable.

If it **fails**, then you are safe.

### For more information
If you have any questions or comments about this advisory:
* Please first read https://docs.ipfs.io/reference/http/api/ about best practices
* Ask in [IPFS Discord #ipfs-chatter](https://discord.gg/ipfs)
* Open an issue in [go-ipfs](https://github.com/ipfs/go-ipfs)
Vulnerability: GHSA-5796-p3m6-9qj4
Summary: Denial of Service (DoS) in Cloud Foundry Routing
Aliases: CVE-2019-11289
Severity: HIGH
CWE: CWE-20
Published: 2021-05-18T15:31:39Z

Cloud Foundry Routing, all versions before 0.193.0, does not properly validate nonce input. A remote unauthorized malicious user could forge a route service request using an invalid nonce that will cause the Gorouter to crash.
Vulnerability: GHSA-xcf7-q56x-78gh
Summary: Connection descriptor exhaustion in proxyproto
Aliases: CVE-2021-23409
Severity: HIGH
CWE: CWE-400
Published: 2021-07-26T21:23:49Z

The package `github.com/pires/go-proxyproto` before 0.6.0 are vulnerable to Denial of Service (DoS) via creating connections without the proxy protocol header.
Vulnerability: GHSA-2jhh-5xm2-j4gf
Summary: Improper Authentication in HashiCorp Nomad
Aliases: CVE-2021-43415
Severity: HIGH
CWE: CWE-287
Published: 2021-12-10T20:17:55Z

HashiCorp Nomad and Nomad Enterprise up to 1.0.13, 1.1.7, and 1.2.0, with the QEMU task driver enabled, allowed authenticated users with job submission capabilities to bypass the configured allowed image paths. Fixed in 1.0.14, 1.1.8, and 1.2.1.
Vulnerability: GHSA-x5m6-jh4r-34mv
Summary: Arbitrary File Overwrite in hub
Aliases: CVE-2014-0177
Severity: MODERATE
CWE: CWE-377
Published: 2022-02-15T01:07:53Z

The am function in lib/hub/commands.rb in hub before 1.12.1 allows local users to overwrite arbitrary files via a symlink attack on a temporary patch file.
Vulnerability: GHSA-xjqr-g762-pxwp
Summary: Improper limitation of path name
Aliases: CVE-2021-20206
Severity: HIGH
CWE: CWE-20, CWE-22
Published: 2022-02-15T01:57:18Z

An improper limitation of path name flaw was found in containernetworking/cni in versions before 0.8.1. When specifying the plugin to load in the 'type' field in the network configuration, it is possible to use special elements such as "../" separators to reference binaries elsewhere on the system. This flaw allows an attacker to execute other existing binaries other than the cni plugins/types, such as 'reboot'. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.
Vulnerability: GHSA-7gfg-6934-mqq2
Summary: Improper Authenication in Pion DTLS
Aliases: CVE-2019-20786
Severity: CRITICAL
CWE: CWE-287
Published: 2021-06-29T21:34:57Z

handleIncomingPacket in conn.go in Pion DTLS before 1.5.2 lacks a check for application data with epoch 0, which allows remote attackers to inject arbitrary unencrypted data after handshake completion.
Vulnerability: GHSA-rrm8-32g4-w8m3
Summary: Cross-site Request Forgery (CSRF)
Aliases: CVE-2017-1000069
Severity: HIGH
CWE: CWE-352
Published: 2021-12-20T18:04:46Z

CSRF in Bitly oauth2_proxy 2.1 during authentication flow
Vulnerability: GHSA-wmwp-pggc-h4mj
Summary: Cross-site Scripting in Documize
Aliases: CVE-2019-19619
Severity: MODERATE
CWE: CWE-79
Published: 2021-05-18T15:30:30Z

domain/section/markdown/markdown.go in Documize before 3.5.1 mishandles untrusted Markdown content. This was addressed by adding the bluemonday HTML sanitizer to defend against XSS.
Vulnerability: GO-2021-0067
Aliases: CVE-2021-27919
Published: 2021-04-14T12:00:00Z

Using Reader.Open on an archive containing a file with a path
prefixed by "../" will cause a panic due to a stack overflow.
If parsing user supplied archives, this may be used as a
denial of service vector.
Vulnerability: GHSA-3fx4-7f69-5mmg
Summary: Integer Overflow in go-jose
Aliases: CVE-2016-9123
Severity: HIGH
CWE: CWE-190
Published: 2021-06-23T17:14:12Z

go-jose before 1.0.5 suffers from a CBC-HMAC integer overflow on 32-bit architectures. An integer overflow could lead to authentication bypass for CBC-HMAC encrypted ciphertexts on 32-bit architectures.
Vulnerability: GHSA-997c-fj8j-rq5h
Summary: Arbitrary Code Execution
Aliases: CVE-2014-9357
Severity: HIGH
CWE: CWE-285
Published: 2022-02-15T01:57:18Z

Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build in a Dockerfile in an LZMA (.xz) archive, related to the chroot for archive extraction.
Vulnerability: GHSA-m6gx-rhvj-fh52
Summary: Denial of service in go-ethereum due to CVE-2020-28362
Severity: CRITICAL
Published: 2021-06-29T21:13:54Z

### Impact
Versions of Geth built with Go `<1.15.5` or `<1.14.12` are most likely affected by a critical DoS-related security vulnerability. The golang team has registered the underlying flaw as ‘CVE-2020-28362’.

We recommend all users to rebuild (ideally `v1.9.24`) with Go `1.15.5` or `1.14.12`, to avoid node crashes. Alternatively, if you are running binaries distributed via one of our official channels, we’re going to release `v1.9.24` ourselves built with Go `1.15.5`.

### Patches
This is not an issue in go-ethereum, rebuilding an older version with Go `1.15.5` or `1.14.12` will suffice to address the vulnerability. 

### Workarounds
Rebuilding with Go `1.15.5` or `1.14.12` will suffice to address the vulnerability. 

### References
- https://blog.ethereum.org/2020/11/12/geth_security_release/
- https://groups.google.com/g/golang-announce/c/NpBGTTmKzpM

### 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 [security@ethereum.org](mailto:security@ethereum.org)
Vulnerability: GO-2021-0088
Aliases: CVE-2019-3564
Published: 2021-04-14T12:00:00Z

Skip ignores unknown fields, rather than failing. A malicious user can craft small
messages with unknown fields which can take significant resources to parse. If a
server accepts messages from an untrusted user, it may be used as a denial of service
vector.
Vulnerability: GHSA-gv2h-gf8m-r68j
Summary: Exposure of server configuration in github.com/go-vela/server
Aliases: CVE-2020-26294
Severity: HIGH
CWE: CWE-200, CWE-78
Published: 2022-02-15T00:19:57Z

### Impact
_What kind of vulnerability is it? Who is impacted?_

* The ability to expose configuration set in the [Vela server](https://github.com/go-vela/server) via [pipeline template functionality](https://go-vela.github.io/docs/templates/overview/).
* It impacts all users of Vela.


Sample of template exposing server configuration [using Sprig's `env` function](http://masterminds.github.io/sprig/os.html):

```yaml
metadata:
  template: true

steps:
  - name: sample
    image: alpine:latest
    commands:
      # OAuth client ID for Vela <-> GitHub communication
      - echo {{ env "VELA_SOURCE_CLIENT" }}
      # secret used for server <-> worker communication
      - echo {{ env "VELA_SECRET" }}
```

### Patches
_Has the problem been patched? What versions should users upgrade to?_

* Upgrade to `0.6.1`

#### Additional Recommended Action(s)

* Rotate all secrets

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

* No

### For more information

If you have any questions or comments about this advisory:

* Email us at [vela@target.com](mailto:vela@target.com)
Vulnerability: GHSA-q6gq-997w-f55g
Summary: Infinite loop in xz
Aliases: CVE-2020-16845
Severity: HIGH
CWE: CWE-835
Published: 2021-12-16T19:16:40Z

Go before 1.13.15 and 14.x before 1.14.7 can have an infinite read loop in ReadUvarint and ReadVarint in encoding/binary via invalid inputs.
Vulnerability: GHSA-gmq2-39ff-f5qg
Summary: A failed upgrade may lead to hung goroutines
Severity: LOW
Published: 2021-05-21T16:25:48Z

### Impact
Processes using tableflip may encounter hung goroutines in the parent process, after a failed upgrade.

The Go runtime has annoying behaviour around setting and clearing
O_NONBLOCK: exec.Cmd.Start() ends up calling os.File.Fd() for any
file in exec.Cmd.ExtraFiles. os.File.Fd() disables both the use
of the runtime poller for the file and clears O_NONBLOCK from
the underlying open file descriptor.

This can lead to goroutines hanging in a parent process, after at least
one failed upgrade. The bug manifests in goroutines which rely on
either a deadline or interruption via Close() to be unblocked being stuck
in read or accept like syscalls. As far as I can tell we've not experienced
this problem in production, so it's most likely quite rare.

### Patches
The problem has been fixed in v1.2.2.

### Workarounds
None.

### References
* https://github.com/cloudflare/tableflip/commit/cae714b289e199db5da5f08af861ea65be6232c0