mirror of
https://github.com/netbirdio/advisory-database.git
synced 2026-05-22 18:04:22 -07:00
Publish Advisories
GHSA-32wr-qqw6-5mfp GHSA-5wj4-wffq-3378 GHSA-7286-pgfv-vxvh GHSA-9qqg-mh7c-chfq GHSA-fp9f-44c2-cw27 GHSA-fw9c-75hh-89p6 GHSA-g4mx-q9vg-27p4 GHSA-gvrm-w2f9-f77q GHSA-j3w8-2p2h-mrr9 GHSA-mq26-g339-26xf GHSA-r6j3-px5g-cq3x GHSA-xfrj-6vvc-3xm2
This commit is contained in:
advisory-database[bot]
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-32wr-qqw6-5mfp",
|
||||
"modified": "2023-10-19T13:18:48Z",
|
||||
"modified": "2025-02-13T19:18:24Z",
|
||||
"published": "2023-10-14T12:30:23Z",
|
||||
"aliases": [
|
||||
"CVE-2023-42663"
|
||||
],
|
||||
"summary": "Apache Airflow vulnerable to sensitive information exposure",
|
||||
"details": "Apache Airflow, versions before 2.7.2, has a vulnerability that allows an authorized user with access to read specific DAGs _only_ to read information about task instances in other DAGs. Users of Apache Airflow are advised to upgrade to version 2.7.2 or newer to mitigate the risk associated with this vulnerability.\n\n",
|
||||
"details": "Apache Airflow, versions before 2.7.2, has a vulnerability that allows an authorized user with access to read specific DAGs _only_ to read information about task instances in other DAGs. Users of Apache Airflow are advised to upgrade to version 2.7.2 or newer to mitigate the risk associated with this vulnerability.",
|
||||
"severity": [
|
||||
{
|
||||
"type": "CVSS_V3",
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-5wj4-wffq-3378",
|
||||
"modified": "2023-11-03T19:13:55Z",
|
||||
"modified": "2025-02-13T19:18:20Z",
|
||||
"published": "2023-10-25T21:30:33Z",
|
||||
"aliases": [
|
||||
"CVE-2023-5043"
|
||||
@@ -48,6 +48,10 @@
|
||||
"type": "WEB",
|
||||
"url": "https://groups.google.com/g/kubernetes-security-announce/c/pVsXsOpxYZo"
|
||||
},
|
||||
{
|
||||
"type": "WEB",
|
||||
"url": "https://security.netapp.com/advisory/ntap-20240307-0012"
|
||||
},
|
||||
{
|
||||
"type": "WEB",
|
||||
"url": "http://www.openwall.com/lists/oss-security/2023/10/25/4"
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-7286-pgfv-vxvh",
|
||||
"modified": "2024-06-21T21:33:57Z",
|
||||
"modified": "2025-02-13T19:18:13Z",
|
||||
"published": "2023-10-11T12:30:27Z",
|
||||
"aliases": [
|
||||
"CVE-2023-44981"
|
||||
],
|
||||
"summary": "Authorization Bypass Through User-Controlled Key vulnerability in Apache ZooKeeper",
|
||||
"details": "Authorization Bypass Through User-Controlled Key vulnerability in Apache ZooKeeper. If SASL Quorum Peer authentication is enabled in ZooKeeper (quorum.auth.enableSasl=true), the authorization is done by verifying that the instance part in SASL authentication ID is listed in zoo.cfg server list. The instance part in SASL auth ID is optional and if it's missing, like 'eve@EXAMPLE.COM', the authorization check will be skipped. As a result an arbitrary endpoint could join the cluster and begin propagating counterfeit changes to the leader, essentially giving it complete read-write access to the data tree. Quorum Peer authentication is not enabled by default.\n\nUsers are recommended to upgrade to version 3.9.1, 3.8.3, 3.7.2, which fixes the issue.\n\nAlternately ensure the ensemble election/quorum communication is protected by a firewall as this will mitigate the issue.\n\nSee the documentation for more details on correct cluster administration.\n",
|
||||
"details": "Authorization Bypass Through User-Controlled Key vulnerability in Apache ZooKeeper. If SASL Quorum Peer authentication is enabled in ZooKeeper (quorum.auth.enableSasl=true), the authorization is done by verifying that the instance part in SASL authentication ID is listed in zoo.cfg server list. The instance part in SASL auth ID is optional and if it's missing, like 'eve@EXAMPLE.COM', the authorization check will be skipped. As a result an arbitrary endpoint could join the cluster and begin propagating counterfeit changes to the leader, essentially giving it complete read-write access to the data tree. Quorum Peer authentication is not enabled by default.\n\nUsers are recommended to upgrade to version 3.9.1, 3.8.3, 3.7.2, which fixes the issue.\n\nAlternately ensure the ensemble election/quorum communication is protected by a firewall as this will mitigate the issue.\n\nSee the documentation for more details on correct cluster administration.",
|
||||
"severity": [
|
||||
{
|
||||
"type": "CVSS_V3",
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-9qqg-mh7c-chfq",
|
||||
"modified": "2024-09-11T19:38:15Z",
|
||||
"modified": "2025-02-13T19:18:33Z",
|
||||
"published": "2023-10-23T21:30:58Z",
|
||||
"aliases": [
|
||||
"CVE-2023-46288"
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-fp9f-44c2-cw27",
|
||||
"modified": "2024-07-08T19:07:58Z",
|
||||
"modified": "2025-02-13T19:18:23Z",
|
||||
"published": "2023-10-25T21:30:33Z",
|
||||
"aliases": [
|
||||
"CVE-2023-5044"
|
||||
],
|
||||
"summary": "Ingress-nginx code injection via nginx.ingress.kubernetes.io/permanent-redirect annotation",
|
||||
"details": "A security issue was identified in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the nginx.ingress.kubernetes.io/permanent-redirect annotation on an Ingress object (in the networking.k8s.io or extensions API group) can be used to inject arbitrary commands, and obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.\n\n",
|
||||
"details": "A security issue was identified in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the nginx.ingress.kubernetes.io/permanent-redirect annotation on an Ingress object (in the networking.k8s.io or extensions API group) can be used to inject arbitrary commands, and obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.",
|
||||
"severity": [
|
||||
{
|
||||
"type": "CVSS_V3",
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-fw9c-75hh-89p6",
|
||||
"modified": "2023-10-20T22:58:47Z",
|
||||
"modified": "2025-02-13T19:18:13Z",
|
||||
"published": "2023-10-16T09:30:19Z",
|
||||
"aliases": [
|
||||
"CVE-2023-4822"
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-g4mx-q9vg-27p4",
|
||||
"modified": "2024-11-18T23:14:49Z",
|
||||
"modified": "2025-02-13T19:18:31Z",
|
||||
"published": "2023-10-17T20:15:25Z",
|
||||
"aliases": [
|
||||
"CVE-2023-45803"
|
||||
],
|
||||
"summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET",
|
||||
"details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n",
|
||||
"details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.",
|
||||
"severity": [
|
||||
{
|
||||
"type": "CVSS_V3",
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-gvrm-w2f9-f77q",
|
||||
"modified": "2024-03-07T18:30:26Z",
|
||||
"modified": "2025-02-13T19:18:18Z",
|
||||
"published": "2023-10-25T21:30:32Z",
|
||||
"aliases": [
|
||||
"CVE-2022-4886"
|
||||
],
|
||||
"summary": "Ingress-nginx path sanitization can be bypassed",
|
||||
"details": "Ingress-nginx `path` sanitization can be bypassed with `log_format` directive.\n",
|
||||
"details": "Ingress-nginx `path` sanitization can be bypassed with `log_format` directive.",
|
||||
"severity": [
|
||||
{
|
||||
"type": "CVSS_V3",
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-j3w8-2p2h-mrr9",
|
||||
"modified": "2024-09-03T21:34:02Z",
|
||||
"modified": "2025-02-13T19:18:26Z",
|
||||
"published": "2023-10-14T12:30:23Z",
|
||||
"aliases": [
|
||||
"CVE-2023-42792"
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-mq26-g339-26xf",
|
||||
"modified": "2024-10-14T21:21:21Z",
|
||||
"modified": "2025-02-13T19:18:35Z",
|
||||
"published": "2023-10-25T18:32:26Z",
|
||||
"aliases": [
|
||||
"CVE-2023-5752"
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-r6j3-px5g-cq3x",
|
||||
"modified": "2024-04-24T15:41:59Z",
|
||||
"modified": "2025-02-13T19:18:10Z",
|
||||
"published": "2023-10-10T21:31:12Z",
|
||||
"aliases": [
|
||||
"CVE-2023-45648"
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-xfrj-6vvc-3xm2",
|
||||
"modified": "2023-10-31T21:31:25Z",
|
||||
"modified": "2025-02-13T19:18:15Z",
|
||||
"published": "2023-10-20T12:31:04Z",
|
||||
"aliases": [
|
||||
"CVE-2023-44483"
|
||||
],
|
||||
"summary": "Apache Santuario - XML Security for Java are vulnerable to private key disclosure",
|
||||
"details": "All versions of Apache Santuario - XML Security for Java prior to 2.2.6, 2.3.4, and 3.0.3, when using the JSR 105 API, are vulnerable to an issue where a private key may be disclosed in log files when generating an XML Signature and logging with debug level is enabled. Users are recommended to upgrade to version 2.2.6, 2.3.4, or 3.0.3, which fixes this issue.\n",
|
||||
"details": "All versions of Apache Santuario - XML Security for Java prior to 2.2.6, 2.3.4, and 3.0.3, when using the JSR 105 API, are vulnerable to an issue where a private key may be disclosed in log files when generating an XML Signature and logging with debug level is enabled. Users are recommended to upgrade to version 2.2.6, 2.3.4, or 3.0.3, which fixes this issue.",
|
||||
"severity": [
|
||||
{
|
||||
"type": "CVSS_V3",
|
||||
|
||||
Reference in New Issue
Block a user