Common Weakness Enumeration

CWE-319

Allowed

Cleartext Transmission of Sensitive Information

Abstraction: Base · Status: Draft

The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

1147 vulnerabilities reference this CWE, most recent first.

GHSA-WHM2-6MHH-GPG8

Vulnerability from github – Published: 2022-05-24 22:01 – Updated: 2022-05-24 22:01
VLAI
Details

LaraCMS v1.0.1 transmits sensitive information in cleartext which can be intercepted by attackers.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-20128"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-319"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-29T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "LaraCMS v1.0.1 transmits sensitive information in cleartext which can be intercepted by attackers.",
  "id": "GHSA-whm2-6mhh-gpg8",
  "modified": "2022-05-24T22:01:48Z",
  "published": "2022-05-24T22:01:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-20128"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wanglelecc/laracms/issues/33"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wanglelecc/laracms"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-WHP9-R49X-695C

Vulnerability from github – Published: 2023-12-01 00:31 – Updated: 2025-11-04 21:30
VLAI
Details

LOYTEC electronics GmbH LINX Configurator 7.4.10 is vulnerable to Insecure Permissions. An admin credential is passed as a value of URL parameters without encryption, so it allows remote attackers to steal the password and gain full control of Loytec device configuration.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-46385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-319"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-30T23:15:07Z",
    "severity": "HIGH"
  },
  "details": "LOYTEC electronics GmbH LINX Configurator 7.4.10 is vulnerable to Insecure Permissions. An admin credential is passed as a value of URL parameters without encryption, so it allows remote attackers to steal the password and gain full control of Loytec device configuration.",
  "id": "GHSA-whp9-r49x-695c",
  "modified": "2025-11-04T21:30:49Z",
  "published": "2023-12-01T00:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46385"
    },
    {
      "type": "WEB",
      "url": "https://packetstormsecurity.com/files/175951/Loytec-LINX-Configurator-7.4.10-Insecure-Transit-Cleartext-Secrets.html"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/fulldisclosure/2023/Nov/6"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-24-247-01"
    },
    {
      "type": "WEB",
      "url": "https://www.txone.com/blog/ten-unpatched-vulnerabilities-in-building-automation-products-identified-by-txone-networks"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2023/Nov/6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WHR9-5G7W-QC2H

Vulnerability from github – Published: 2022-05-24 22:01 – Updated: 2022-05-24 22:01
VLAI
Details

The Taidii Diibear Android application 2.4.0 and all its derivatives allow attackers to view private chat messages and media files via logcat because of excessive logging.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-35456"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-319"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-17T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Taidii Diibear Android application 2.4.0 and all its derivatives allow attackers to view private chat messages and media files via logcat because of excessive logging.",
  "id": "GHSA-whr9-5g7w-qc2h",
  "modified": "2022-05-24T22:01:29Z",
  "published": "2022-05-24T22:01:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35456"
    },
    {
      "type": "WEB",
      "url": "https://github.com/galapogos/Taidii-Diibear-Vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "https://play.google.com/store/apps/details?id=com.taidii.diibear\u0026hl=en_US\u0026gl=US"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-WJCQ-P2HH-4GR7

Vulnerability from github – Published: 2024-06-14 06:34 – Updated: 2024-07-04 06:35
VLAI
Details

Toshiba printers will display the password of the admin user in clear-text and additional passwords when sending 2 specific HTTP requests to the internal API. An attacker stealing the cookie of an admin or abusing a XSS vulnerability can recover this password in clear-text and compromise the printer. This vulnerability can be executed in combination with other vulnerabilities and difficult to execute alone. So, the CVSS score for this vulnerability alone is lower than the score listed in the "Base Score" of this vulnerability. For detail on related other vulnerabilities, please ask to the below contact point. https://www.toshibatec.com/contacts/products/ As for the affected products/models/versions, see the reference URL.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-27163"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-319"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-14T04:15:32Z",
    "severity": "MODERATE"
  },
  "details": "Toshiba printers will display the password of the admin user in clear-text and additional passwords when sending 2 specific HTTP requests to the internal API. An attacker stealing the cookie of an admin or abusing a XSS vulnerability can recover this password in clear-text and compromise the printer. This vulnerability can be executed in combination with other vulnerabilities and  difficult to execute alone. So, the CVSS score for this vulnerability alone is lower than the score listed in the \"Base Score\" of this vulnerability. For detail on related other vulnerabilities, please ask to the below contact point.\n https://www.toshibatec.com/contacts/products/ \nAs for the affected products/models/versions, see the reference URL.",
  "id": "GHSA-wjcq-p2hh-4gr7",
  "modified": "2024-07-04T06:35:04Z",
  "published": "2024-06-14T06:34:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27163"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU97136265/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.toshibatec.com/information/20240531_01.html"
    },
    {
      "type": "WEB",
      "url": "https://www.toshibatec.com/information/pdf/information20240531_01.pdf"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jul/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WJJV-3MJ2-39HF

Vulnerability from github – Published: 2026-05-29 19:23 – Updated: 2026-05-29 19:23
VLAI
Summary
AgenticMail API/storage and outbound relay hardening fixes
Details

The current upstream main branch at commit 7e0206d was reviewed, and the fix-first patch set was rebased on 2026-05-18. The patches cover: validated and bound inactive-agent hour filtering; storage SQL identifier validation; metadata-backed ownership checks for raw storage SQL; blocking direct storage metadata access through raw SQL; fail-closed outbound worker secret handling; SMTP envelope/header control-character validation before command construction; and TLS certificate verification as the default for MailSender with an explicit opt-out for local development. Validation completed locally with targeted API/Core security tests plus API/Core builds. The security patch branch was not published publicly because te repository's SECURITY.md asks reporters not to open public vulnerability issues.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.31"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@agenticmail/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.32"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.9"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@agenticmail/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47255"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-284",
      "CWE-319",
      "CWE-798",
      "CWE-89"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T19:23:29Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The current upstream main branch at commit 7e0206d was reviewed, and the fix-first patch set was rebased on 2026-05-18. The patches cover: validated and bound inactive-agent hour filtering; storage SQL identifier validation; metadata-backed ownership checks for raw storage SQL; blocking direct storage metadata access through raw SQL; fail-closed outbound worker secret handling; SMTP envelope/header control-character validation before command construction; and TLS certificate verification as the default for MailSender with an explicit opt-out for local development. Validation completed locally with targeted API/Core security tests plus API/Core builds. The security patch branch was not published publicly because te repository\u0027s SECURITY.md asks reporters not to open public vulnerability issues.",
  "id": "GHSA-wjjv-3mj2-39hf",
  "modified": "2026-05-29T19:23:29Z",
  "published": "2026-05-29T19:23:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/agenticmail/agenticmail/security/advisories/GHSA-wjjv-3mj2-39hf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/agenticmail/agenticmail/commit/1408de543fa3577d8c2d4fdb289c75fe6faafac7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/agenticmail/agenticmail/commit/234b811e426a0743170f3b10bc43419d64330155"
    },
    {
      "type": "WEB",
      "url": "https://github.com/agenticmail/agenticmail/commit/6c70c8254c906f823392d7f5ccee88a5481e7731"
    },
    {
      "type": "WEB",
      "url": "https://github.com/agenticmail/agenticmail/commit/8cb053f2307dd77b7736ffa0d7df04b0ccc3272d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/agenticmail/agenticmail"
    },
    {
      "type": "WEB",
      "url": "https://github.com/agenticmail/agenticmail/blob/7b9b05d973676e9f3d097c08b8e649f59bfc15d0/CHANGELOG.md?plain=1#L1842"
    },
    {
      "type": "WEB",
      "url": "https://github.com/agenticmail/agenticmail/blob/7b9b05d973676e9f3d097c08b8e649f59bfc15d0/packages/core/src/mail/sender.ts#L33"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "AgenticMail API/storage and outbound relay hardening fixes"
}

GHSA-WP6X-79V3-V6J2

Vulnerability from github – Published: 2022-05-24 22:29 – Updated: 2022-05-24 22:29
VLAI
Details

BIOTRONIK CardioMessenger II, The affected products transmit credentials in clear-text prior to switching to an encrypted communication channel. An attacker can disclose the product’s client credentials for connecting to the BIOTRONIK Remote Communication infrastructure.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-18248"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-319"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-29T14:15:00Z",
    "severity": "LOW"
  },
  "details": "BIOTRONIK CardioMessenger II, The affected products transmit credentials in clear-text prior to switching to an encrypted communication channel. An attacker can disclose the product\u2019s client credentials for connecting to the BIOTRONIK Remote Communication infrastructure.",
  "id": "GHSA-wp6x-79v3-v6j2",
  "modified": "2022-05-24T22:29:04Z",
  "published": "2022-05-24T22:29:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18248"
    },
    {
      "type": "WEB",
      "url": "https://www.us-cert.gov/ics/advisories/icsma-20-170-05"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-WPGC-5CR5-H9GG

Vulnerability from github – Published: 2022-12-11 15:30 – Updated: 2022-12-13 17:56
VLAI
Summary
phpMyFAQ has insecure HTTP cookies
Details

phpMyFAQ is contains Sensitive Cookie in HTTPS Session Without 'Secure' Attribute in versions prior to 3.1.9.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "thorsten/phpmyfaq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-4409"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-311",
      "CWE-319",
      "CWE-614"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-12T22:06:06Z",
    "nvd_published_at": "2022-12-11T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "phpMyFAQ is contains Sensitive Cookie in HTTPS Session Without \u0027Secure\u0027 Attribute in versions prior to 3.1.9.",
  "id": "GHSA-wpgc-5cr5-h9gg",
  "modified": "2022-12-13T17:56:45Z",
  "published": "2022-12-11T15:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4409"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thorsten/phpMyFAQ/commit/c16cc2bbe2687f75aa1204b804483091fae43cba"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thorsten/phpmyfaq/commit/8b47f38"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thorsten/phpmyfaq"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/5915ed4c-5fe2-42e7-8fac-5dd0d032727c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "phpMyFAQ has insecure HTTP cookies"
}

GHSA-WPWQ-4J6V-78M3

Vulnerability from github – Published: 2026-06-19 14:17 – Updated: 2026-06-19 14:17
VLAI
Summary
guzzlehttp/guzzle: Silent HTTPS-Proxy Downgrade to Cleartext
Details

Impact

The built-in cURL handlers (GuzzleHttp\Handler\CurlHandler and GuzzleHttp\Handler\CurlMultiHandler, used by default whenever the PHP cURL extension is available) accept an https:// proxy — a proxy reached over a TLS-encrypted connection — through the proxy request option, client-level proxy defaults, or proxy environment variables such as http_proxy, https_proxy, HTTPS_PROXY, all_proxy, and ALL_PROXY.

When the installed libcurl does not support HTTPS proxies, behavior depends on the libcurl version/build:

  • libcurl older than 7.50.2 silently treats an https:// proxy as a plaintext http:// proxy. The TLS connection to the proxy is never established, and the proxy leg is cleartext with no error or warning.
  • libcurl 7.50.2 through 7.51.x rejects the unsupported proxy scheme at connect time, so no cleartext exposure occurs, but the failure is late and opaque.
  • libcurl 7.52.0 or newer builds without HTTPS-proxy support also fail at connect time rather than downgrading.

The security-relevant case is the silent downgrade on libcurl older than 7.50.2. An application is affected when it sends requests through one of the built-in cURL handlers, configures an https:// proxy expecting the proxy connection itself to be encrypted, and runs with libcurl older than 7.50.2.

In that configuration, traffic expected to be protected by TLS on the hop to the proxy is transmitted in cleartext. Proxy authentication credentials (the Proxy-Authorization header, proxy userinfo in the proxy URL, or CURLOPT_PROXYUSERPWD) are sent without encryption, and the CONNECT target host and port for tunneled HTTPS requests are exposed. For plain HTTP requests, request headers and bodies are also exposed on the proxy leg. End-to-end HTTPS requests tunneled through the proxy remain protected by their inner TLS session; the exposure is limited to the proxy negotiation and proxy credentials.

Applications that do not configure an https:// proxy are not affected. Installations running libcurl 7.52.0 or newer built with HTTPS-proxy support are not affected because HTTPS proxies work as intended. Installations running libcurl 7.50.2 through 7.51.x, or libcurl 7.52.0 or newer built without HTTPS-proxy support, are not exposed to the silent cleartext downgrade, but Guzzle now rejects those unsupported configurations up front as well. The built-in stream handler is not affected; the issue is specific to the cURL handlers' proxy handling. Low-level cURL options under the curl request option, such as CURLOPT_PROXY or CURLOPT_PROXYTYPE, are advanced custom configuration and remain the caller's responsibility.

Patches

The issue is patched in 7.12.1 and later. Starting in that release, the built-in cURL handlers detect whether the installed libcurl supports HTTPS proxies — requiring both libcurl 7.52.0 or newer and the CURL_VERSION_HTTPS_PROXY feature bit — and reject a request configured through Guzzle's first-class proxy handling with an https:// proxy up front by throwing a GuzzleHttp\Exception\RequestException. No request bytes reach the network when the proxy cannot be used securely. Versions before 7.12.1 are affected by the silent downgrade when run against libcurl older than 7.50.2.

Workarounds

If you cannot upgrade immediately, do not configure an https:// proxy on an installation whose libcurl lacks HTTPS-proxy support, and verify the capability in application code before using one. Remember to check proxy environment variables as well as any explicit proxy option:

$curl = \curl_version();
$httpsProxyBit = \defined('CURL_VERSION_HTTPS_PROXY') ? \CURL_VERSION_HTTPS_PROXY : (1 << 21);

if (\version_compare($curl['version'], '7.52.0', '<') || 0 === ($curl['features'] & $httpsProxyBit)) {
    throw new \RuntimeException('Installed libcurl does not support HTTPS proxies.');
}

Upgrading the system libcurl to 7.52.0 or newer built with HTTPS-proxy support also resolves the underlying unsupported-proxy behavior.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "guzzlehttp/guzzle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55568"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-311",
      "CWE-319",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T14:17:59Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe built-in cURL handlers (`GuzzleHttp\\Handler\\CurlHandler` and `GuzzleHttp\\Handler\\CurlMultiHandler`, used by default whenever the PHP cURL extension is available) accept an `https://` proxy \u2014 a proxy reached over a TLS-encrypted connection \u2014 through the `proxy` request option, client-level `proxy` defaults, or proxy environment variables such as `http_proxy`, `https_proxy`, `HTTPS_PROXY`, `all_proxy`, and `ALL_PROXY`.\n\nWhen the installed libcurl does not support HTTPS proxies, behavior depends on the libcurl version/build:\n\n- libcurl older than 7.50.2 silently treats an `https://` proxy as a plaintext `http://` proxy. The TLS connection to the proxy is never established, and the proxy leg is cleartext with no error or warning.\n- libcurl 7.50.2 through 7.51.x rejects the unsupported proxy scheme at connect time, so no cleartext exposure occurs, but the failure is late and opaque.\n- libcurl 7.52.0 or newer builds without HTTPS-proxy support also fail at connect time rather than downgrading.\n\nThe security-relevant case is the silent downgrade on libcurl older than 7.50.2. An application is affected when it sends requests through one of the built-in cURL handlers, configures an `https://` proxy expecting the proxy connection itself to be encrypted, and runs with libcurl older than 7.50.2.\n\nIn that configuration, traffic expected to be protected by TLS on the hop to the proxy is transmitted in cleartext. Proxy authentication credentials (the `Proxy-Authorization` header, proxy userinfo in the proxy URL, or `CURLOPT_PROXYUSERPWD`) are sent without encryption, and the `CONNECT` target host and port for tunneled HTTPS requests are exposed. For plain HTTP requests, request headers and bodies are also exposed on the proxy leg. End-to-end HTTPS requests tunneled through the proxy remain protected by their inner TLS session; the exposure is limited to the proxy negotiation and proxy credentials.\n\nApplications that do not configure an `https://` proxy are not affected. Installations running libcurl 7.52.0 or newer built with HTTPS-proxy support are not affected because HTTPS proxies work as intended. Installations running libcurl 7.50.2 through 7.51.x, or libcurl 7.52.0 or newer built without HTTPS-proxy support, are not exposed to the silent cleartext downgrade, but Guzzle now rejects those unsupported configurations up front as well. The built-in stream handler is not affected; the issue is specific to the cURL handlers\u0027 proxy handling. Low-level cURL options under the `curl` request option, such as `CURLOPT_PROXY` or `CURLOPT_PROXYTYPE`, are advanced custom configuration and remain the caller\u0027s responsibility.\n\n### Patches\n\nThe issue is patched in `7.12.1` and later. Starting in that release, the built-in cURL handlers detect whether the installed libcurl supports HTTPS proxies \u2014 requiring both libcurl 7.52.0 or newer and the `CURL_VERSION_HTTPS_PROXY` feature bit \u2014 and reject a request configured through Guzzle\u0027s first-class proxy handling with an `https://` proxy up front by throwing a `GuzzleHttp\\Exception\\RequestException`. No request bytes reach the network when the proxy cannot be used securely. Versions before `7.12.1` are affected by the silent downgrade when run against libcurl older than 7.50.2.\n\n### Workarounds\n\nIf you cannot upgrade immediately, do not configure an `https://` proxy on an installation whose libcurl lacks HTTPS-proxy support, and verify the capability in application code before using one. Remember to check proxy environment variables as well as any explicit `proxy` option:\n\n```php\n$curl = \\curl_version();\n$httpsProxyBit = \\defined(\u0027CURL_VERSION_HTTPS_PROXY\u0027) ? \\CURL_VERSION_HTTPS_PROXY : (1 \u003c\u003c 21);\n\nif (\\version_compare($curl[\u0027version\u0027], \u00277.52.0\u0027, \u0027\u003c\u0027) || 0 === ($curl[\u0027features\u0027] \u0026 $httpsProxyBit)) {\n    throw new \\RuntimeException(\u0027Installed libcurl does not support HTTPS proxies.\u0027);\n}\n```\n\nUpgrading the system libcurl to 7.52.0 or newer built with HTTPS-proxy support also resolves the underlying unsupported-proxy behavior.",
  "id": "GHSA-wpwq-4j6v-78m3",
  "modified": "2026-06-19T14:17:59Z",
  "published": "2026-06-19T14:17:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/security/advisories/GHSA-wpwq-4j6v-78m3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/guzzle/guzzle"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "guzzlehttp/guzzle: Silent HTTPS-Proxy Downgrade to Cleartext"
}

GHSA-WQ9Q-JVPH-86FJ

Vulnerability from github – Published: 2025-06-24 21:30 – Updated: 2025-06-24 21:30
VLAI
Details

Kaleris NAVIS N4 ULC (Ultra Light Client) communicates insecurely using zlib-compressed data over HTTP. An attacker capable of observing network traffic between Ultra Light Clients and N4 servers can extract sensitive information, including plaintext credentials.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-5087"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-319"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-24T19:15:23Z",
    "severity": "MODERATE"
  },
  "details": "Kaleris NAVIS N4 ULC (Ultra Light Client) communicates insecurely using zlib-compressed data over HTTP. An attacker capable of observing network traffic between Ultra Light Clients and N4 servers can extract sensitive information, including plaintext credentials.",
  "id": "GHSA-wq9q-jvph-86fj",
  "modified": "2025-06-24T21:30:28Z",
  "published": "2025-06-24T21:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5087"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-175-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-WQFC-CR59-H64P

Vulnerability from github – Published: 2019-07-31 04:22 – Updated: 2021-08-17 19:40
VLAI
Summary
Missing Encryption of Sensitive Data in yarn
Details

Yarn before 1.17.3 is vulnerable to Missing Encryption of Sensitive Data due to HTTP URLs in lockfile causing unencrypted authentication data to be sent over the network.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "yarn"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.17.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-5448"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-311",
      "CWE-319"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2019-07-31T03:41:57Z",
    "nvd_published_at": "2019-07-30T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Yarn before 1.17.3 is vulnerable to Missing Encryption of Sensitive Data due to HTTP URLs in lockfile causing unencrypted authentication data to be sent over the network.",
  "id": "GHSA-wqfc-cr59-h64p",
  "modified": "2021-08-17T19:40:44Z",
  "published": "2019-07-31T04:22:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5448"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/640904"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ChALkeR/notes/blob/master/Yarn-vuln.md"
    },
    {
      "type": "WEB",
      "url": "https://yarnpkg.com/blog/2019/07/12/recommended-security-update"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Missing Encryption of Sensitive Data in yarn"
}

Mitigation
Architecture and Design

Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.

Mitigation
Implementation

When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.

Mitigation
Implementation

When designing hardware platforms, ensure that approved encryption algorithms (such as those recommended by NIST) protect paths from security critical data to trusted user applications.

Mitigation
Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Mitigation
Operation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.

CAPEC-102: Session Sidejacking

Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.

CAPEC-117: Interception

An adversary monitors data streams to or from the target for information gathering purposes. This attack may be undertaken to solely gather sensitive information or to support a further attack against the target. This attack pattern can involve sniffing network traffic as well as other types of data streams (e.g. radio). The adversary can attempt to initiate the establishment of a data stream or passively observe the communications as they unfold. In all variants of this attack, the adversary is not the intended recipient of the data stream. In contrast to other means of gathering information (e.g., targeting data leaks), the adversary must actively position themself so as to observe explicit data channels (e.g. network traffic) and read the content. However, this attack differs from a Adversary-In-the-Middle (CAPEC-94) attack, as the adversary does not alter the content of the communications nor forward data to the intended recipient.

CAPEC-383: Harvesting Information via API Event Monitoring

An adversary hosts an event within an application framework and then monitors the data exchanged during the course of the event for the purpose of harvesting any important data leaked during the transactions. One example could be harvesting lists of usernames or userIDs for the purpose of sending spam messages to those users. One example of this type of attack involves the adversary creating an event within the sub-application. Assume the adversary hosts a "virtual sale" of rare items. As other users enter the event, the attacker records via AiTM (CAPEC-94) proxy the user_ids and usernames of everyone who attends. The adversary would then be able to spam those users within the application using an automated script.

CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content

An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.

CAPEC-65: Sniff Application Code

An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.