Publish Advisories

GHSA-h452-7996-h45h
GHSA-rc47-6667-2j5j
GHSA-29xx-hcv2-c4cp
GHSA-3gv2-29qc-v67m
GHSA-h7vf-5wrv-9fhv
GHSA-p52g-cm5j-mjv4
GHSA-r7jw-wp68-3xch
GHSA-v5w6-wcm8-jm4q
GHSA-x4qr-2fvf-3mr5
This commit is contained in:
advisory-database[bot]
2025-02-13 18:37:56 +00:00
parent c2e5346926
commit b658211573
9 changed files with 23 additions and 15 deletions
@@ -1,7 +1,7 @@
{
"schema_version": "1.4.0",
"id": "GHSA-h452-7996-h45h",
"modified": "2023-01-23T16:59:52Z",
"modified": "2025-02-13T18:36:34Z",
"published": "2023-01-18T06:31:03Z",
"aliases": [
"CVE-2022-25901"
@@ -75,6 +75,14 @@
"type": "WEB",
"url": "https://github.com/bmeck/node-cookiejar/blob/master/cookiejar.js#23L73"
},
{
"type": "WEB",
"url": "https://github.com/bmeck/node-cookiejar/blob/master/cookiejar.js%23L73"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/09/msg00008.html"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-3176681"
@@ -1,7 +1,7 @@
{
"schema_version": "1.4.0",
"id": "GHSA-rc47-6667-2j5j",
"modified": "2023-02-07T21:16:56Z",
"modified": "2025-02-13T18:36:37Z",
"published": "2023-01-31T06:30:26Z",
"aliases": [
"CVE-2022-25881"
@@ -1,13 +1,13 @@
{
"schema_version": "1.4.0",
"id": "GHSA-29xx-hcv2-c4cp",
"modified": "2023-02-21T20:00:22Z",
"modified": "2025-02-13T18:36:46Z",
"published": "2023-02-08T22:23:39Z",
"aliases": [
"CVE-2023-0216"
],
"summary": "openssl-src subject to Invalid pointer dereference in `d2i_PKCS7` functions",
"details": "An invalid pointer dereference on read can be triggered when an application tries to load malformed PKCS7 data with the `d2i_PKCS7()`, `d2i_PKCS7_bio()` or `d2i_PKCS7_fp()` functions.\n\nThe result of the dereference is an application crash which could lead to a denial of service attack. The TLS implementation in OpenSSL does not call this function however third party applications might call these functions on untrusted data.\n",
"details": "An invalid pointer dereference on read can be triggered when an application tries to load malformed PKCS7 data with the `d2i_PKCS7()`, `d2i_PKCS7_bio()` or `d2i_PKCS7_fp()` functions.\n\nThe result of the dereference is an application crash which could lead to a denial of service attack. The TLS implementation in OpenSSL does not call this function however third party applications might call these functions on untrusted data.",
"severity": [
{
"type": "CVSS_V3",
@@ -1,7 +1,7 @@
{
"schema_version": "1.4.0",
"id": "GHSA-3gv2-29qc-v67m",
"modified": "2023-02-15T17:39:12Z",
"modified": "2025-02-13T18:36:42Z",
"published": "2023-02-01T18:48:06Z",
"aliases": [
"CVE-2022-24895"
@@ -1,13 +1,13 @@
{
"schema_version": "1.4.0",
"id": "GHSA-h7vf-5wrv-9fhv",
"modified": "2023-02-14T19:25:20Z",
"modified": "2025-02-13T18:36:40Z",
"published": "2023-02-01T18:48:09Z",
"aliases": [
"CVE-2022-24894"
],
"summary": "Symfony storing cookie headers in HttpCache",
"details": "Description\n-----------\n\nThe Symfony HTTP cache system acts as a reverse proxy: it caches HTTP responses (including headers) and returns them to clients.\n\nIn a recent `AbstractSessionListener` change, the response might now contain a `Set-Cookie` header. If the Symfony HTTP cache system is enabled, this header might be stored and returned to some other clients. An attacker can use this vulnerability to retrieve the victim's session.\n\nResolution\n----------\n\nThe `HttpStore` constructor now takes a parameter containing a list of private headers that are removed from the HTTP response headers.\nThe default value for this parameter is `Set-Cookie`, but it can be overridden or extended by the application.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/d2f6322af9444ac5cd1ef3ac6f280dbef7f9d1fb) for branch 4.4.\n\nCredits\n-------\n\nWe would like to thank Soner Sayakci for reporting the issue and Nicolas Grekas for fixing it.\n",
"details": "Description\n-----------\n\nThe Symfony HTTP cache system acts as a reverse proxy: it caches HTTP responses (including headers) and returns them to clients.\n\nIn a recent `AbstractSessionListener` change, the response might now contain a `Set-Cookie` header. If the Symfony HTTP cache system is enabled, this header might be stored and returned to some other clients. An attacker can use this vulnerability to retrieve the victim's session.\n\nResolution\n----------\n\nThe `HttpStore` constructor now takes a parameter containing a list of private headers that are removed from the HTTP response headers.\nThe default value for this parameter is `Set-Cookie`, but it can be overridden or extended by the application.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/d2f6322af9444ac5cd1ef3ac6f280dbef7f9d1fb) for branch 4.4.\n\nCredits\n-------\n\nWe would like to thank Soner Sayakci for reporting the issue and Nicolas Grekas for fixing it.",
"severity": [
{
"type": "CVSS_V3",
@@ -1,13 +1,13 @@
{
"schema_version": "1.4.0",
"id": "GHSA-p52g-cm5j-mjv4",
"modified": "2023-02-24T19:03:43Z",
"modified": "2025-02-13T18:36:48Z",
"published": "2023-02-08T22:31:42Z",
"aliases": [
"CVE-2022-4304"
],
"summary": "openssl-src subject to Timing Oracle in RSA Decryption",
"details": "A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.\n\nFor example, in a TLS connection, RSA is commonly used by a client to send an encrypted pre-master secret to the server. An attacker that had observed a genuine connection between a client and a server could use this flaw to send trial messages to the server and record the time taken to process them. After a sufficiently large number of messages the attacker could recover the pre-master secret used for the original connection and thus be able to decrypt the application data sent over that connection.\n",
"details": "A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.\n\nFor example, in a TLS connection, RSA is commonly used by a client to send an encrypted pre-master secret to the server. An attacker that had observed a genuine connection between a client and a server could use this flaw to send trial messages to the server and record the time taken to process them. After a sufficiently large number of messages the attacker could recover the pre-master secret used for the original connection and thus be able to decrypt the application data sent over that connection.",
"severity": [
{
"type": "CVSS_V3",
@@ -1,13 +1,13 @@
{
"schema_version": "1.4.0",
"id": "GHSA-r7jw-wp68-3xch",
"modified": "2024-06-24T21:24:19Z",
"modified": "2025-02-13T18:36:47Z",
"published": "2023-02-08T22:28:34Z",
"aliases": [
"CVE-2023-0215"
],
"summary": "openssl-src vulnerable to Use-after-free following `BIO_new_NDEF`",
"details": "The public API function `BIO_new_NDEF` is a helper function used for streaming ASN.1 data via a `BIO`. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications.\n\nThe function receives a `BIO` from the caller, prepends a new `BIO_f_asn1` filter `BIO` onto the front of it to form a `BIO` chain, and then returns the new head of the `BIO` chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter `BIO` is freed and the function returns a `NULL` result indicating a failure. However, in this case, the `BIO` chain is not properly cleaned up and the `BIO` passed by the caller still retains internal pointers to the previously freed filter `BIO`. If the caller then goes on to call `BIO_pop()` on the `BIO` then a use-after-free will occur. This will most likely result in a crash.\n\nThis scenario occurs directly in the internal function `B64_write_ASN1()` which may cause `BIO_new_NDEF()` to be called and will subsequently call `BIO_pop()` on the `BIO`. This internal function is in turn called by the public API functions `PEM_write_bio_ASN1_stream`, `PEM_write_bio_CMS_stream`, `PEM_write_bio_PKCS7_stream`, `SMIME_write_ASN1`, `SMIME_write_CMS` and `SMIME_write_PKCS7`.\n\nOther public API functions that may be impacted by this include `i2d_ASN1_bio_stream`, `BIO_new_CMS`, `BIO_new_PKCS7`, `i2d_CMS_bio_stream` and `i2d_PKCS7_bio_stream`.\n",
"details": "The public API function `BIO_new_NDEF` is a helper function used for streaming ASN.1 data via a `BIO`. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications.\n\nThe function receives a `BIO` from the caller, prepends a new `BIO_f_asn1` filter `BIO` onto the front of it to form a `BIO` chain, and then returns the new head of the `BIO` chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter `BIO` is freed and the function returns a `NULL` result indicating a failure. However, in this case, the `BIO` chain is not properly cleaned up and the `BIO` passed by the caller still retains internal pointers to the previously freed filter `BIO`. If the caller then goes on to call `BIO_pop()` on the `BIO` then a use-after-free will occur. This will most likely result in a crash.\n\nThis scenario occurs directly in the internal function `B64_write_ASN1()` which may cause `BIO_new_NDEF()` to be called and will subsequently call `BIO_pop()` on the `BIO`. This internal function is in turn called by the public API functions `PEM_write_bio_ASN1_stream`, `PEM_write_bio_CMS_stream`, `PEM_write_bio_PKCS7_stream`, `SMIME_write_ASN1`, `SMIME_write_CMS` and `SMIME_write_PKCS7`.\n\nOther public API functions that may be impacted by this include `i2d_ASN1_bio_stream`, `BIO_new_CMS`, `BIO_new_PKCS7`, `i2d_CMS_bio_stream` and `i2d_PKCS7_bio_stream`.",
"severity": [
{
"type": "CVSS_V3",
@@ -1,13 +1,13 @@
{
"schema_version": "1.4.0",
"id": "GHSA-v5w6-wcm8-jm4q",
"modified": "2023-02-21T19:59:57Z",
"modified": "2025-02-13T18:36:45Z",
"published": "2023-02-08T22:22:58Z",
"aliases": [
"CVE-2022-4450"
],
"summary": "openssl-src contains Double free after calling `PEM_read_bio_ex`",
"details": "The function `PEM_read_bio_ex()` reads a PEM file from a BIO and parses and decodes the \"name\" (e.g. \"CERTIFICATE\"), any header data and the payload data. If the function succeeds then the \"name_out\", \"header\" and \"data\" arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case `PEM_read_bio_ex()` will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. This could be exploited by an attacker who has the ability to supply malicious PEM files for parsing to achieve a denial of service attack.\n\nThe functions `PEM_read_bio()` and `PEM_read()` are simple wrappers around `PEM_read_bio_ex()` and therefore these functions are also directly affected.\n\nThese functions are also called indirectly by a number of other OpenSSL functions including `PEM_X509_INFO_read_bio_ex()` and\n`SSL_CTX_use_serverinfo_file()` which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if `PEM_read_bio_ex()` returns a failure code. These locations include the `PEM_read_bio_TYPE()` functions as well as the decoders introduced in OpenSSL 3.0.\n",
"details": "The function `PEM_read_bio_ex()` reads a PEM file from a BIO and parses and decodes the \"name\" (e.g. \"CERTIFICATE\"), any header data and the payload data. If the function succeeds then the \"name_out\", \"header\" and \"data\" arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case `PEM_read_bio_ex()` will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. This could be exploited by an attacker who has the ability to supply malicious PEM files for parsing to achieve a denial of service attack.\n\nThe functions `PEM_read_bio()` and `PEM_read()` are simple wrappers around `PEM_read_bio_ex()` and therefore these functions are also directly affected.\n\nThese functions are also called indirectly by a number of other OpenSSL functions including `PEM_X509_INFO_read_bio_ex()` and\n`SSL_CTX_use_serverinfo_file()` which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if `PEM_read_bio_ex()` returns a failure code. These locations include the `PEM_read_bio_TYPE()` functions as well as the decoders introduced in OpenSSL 3.0.",
"severity": [
{
"type": "CVSS_V3",
@@ -1,13 +1,13 @@
{
"schema_version": "1.4.0",
"id": "GHSA-x4qr-2fvf-3mr5",
"modified": "2023-03-01T01:47:38Z",
"modified": "2025-02-13T18:36:43Z",
"published": "2023-02-08T22:17:06Z",
"aliases": [
"CVE-2023-0286"
],
"summary": "Vulnerable OpenSSL included in cryptography wheels",
"details": "pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 0.8.1-39.0.0 are vulnerable to a security issue. More details about the vulnerabilities themselves can be found in https://www.openssl.org/news/secadv/20221213.txt and https://www.openssl.org/news/secadv/20230207.txt.\n\nIf you are building cryptography source (\"sdist\") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.\n\n",
"details": "pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 0.8.1-39.0.0 are vulnerable to a security issue. More details about the vulnerabilities themselves can be found in https://www.openssl.org/news/secadv/20221213.txt and https://www.openssl.org/news/secadv/20230207.txt.\n\nIf you are building cryptography source (\"sdist\") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.",
"severity": [
{
"type": "CVSS_V3",