deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-8hfj-xrj2-pm22
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.4)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 111.11.0, < 111.15.0
Patched in: 111.15.0

Summary: Certificate check bypass in openssl-src

Details:
The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose. OpenSSL versions 1.1.1h and newer are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1h-1.1.1j).
GitHub Security Advisory: GHSA-f3fg-5j9p-vchc
Package: pleaser (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-668: Exposure of Resource to Wrong Sphere
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: File exposure in pleaser

Details:
pleaser before 0.4.0 allows a local unprivileged attacker to gain knowledge about the existence of files or directories in privileged locations via the search_path function, the --check option, or the -d option.
GitHub Security Advisory: GHSA-mc52-jpm2-cqh6
Package: deno (RUST)
Severity: HIGH (CVSS 8.8)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: >= 1.9.0, < 1.29.3
Patched in: 1.29.3

Summary: Deno is vulnerable to race condition via interactive permission prompt spoofing

Details:
### Impact

Multi-threaded programs were able to spoof interactive permission prompt by rewriting the prompt to suggest that program is waiting on user confirmation to unrelated action. 

A malicious program could clear the terminal screen after permission prompt was shown and write a generic message like so:
```
// Expected prompt
⚠️  ┌ Deno requests read access to "./log.txt".
   ├ Requested by `Deno.open()` API
   ├ Run again with --allow-read to bypass this prompt.
   └ Allow? [y/n] (y = yes, allow; n = no, deny) >

// Prompt that users would see
Do you want to continue?
```

This situation impacts users who use Web Worker API and relied on interactive permission prompt. The reproduction is very timing sensitive and can’t be reliably reproduced on every try.

This problem can not be exploited on systems that do not attach an interactive prompt (for example headless servers). 

### Patches

The problem has been fixed in Deno v1.29.3; it is recommended all users update to this version.

### Workarounds

Run with `--no-prompt` flag to disable interactive permission prompts.
GitHub Security Advisory: GHSA-x3mh-jvjw-3xwx
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: < 111.18.0
Patched in: 111.18.0

Summary: openssl-src's infinite loop in `BN_mod_sqrt()` reachable when parsing certificates

Details:
The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).
GitHub Security Advisory: GHSA-x3mh-jvjw-3xwx
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: >= 300.0.0, < 300.0.5
Patched in: 300.0.5

Summary: openssl-src's infinite loop in `BN_mod_sqrt()` reachable when parsing certificates

Details:
The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).
GitHub Security Advisory: GHSA-p52g-cm5j-mjv4
Package: openssl-src (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-203: Observable Discrepancy
Vulnerable versions: >= 300.0.0, < 300.0.12
Patched in: 300.0.12

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.

For 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.
GitHub Security Advisory: GHSA-p52g-cm5j-mjv4
Package: openssl-src (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-203: Observable Discrepancy
Vulnerable versions: < 111.25.0
Patched in: 111.25.0

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.

For 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.
GitHub Security Advisory: GHSA-pp74-39w2-v4w9
Package: pleaser (RUST)
Severity: HIGH (CVSS 7.8)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following'), CWE-340: Generation of Predictable Numbers or Identifiers
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: Permissions bypass in pleaser

Details:
pleaseedit in pleaser before 0.4.0 uses predictable temporary filenames in /tmp and the target directory. This allows a local attacker to gain full root privileges by staging a symlink attack.
GitHub Security Advisory: GHSA-q9wj-f4qw-6vfj
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.4)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: < 111.16.0
Patched in: 111.16.0

Summary: Read buffer overruns processing ASN.1 strings

Details:
ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).
GitHub Security Advisory: GHSA-qgm6-9472-pwq7
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 111.14.0
Patched in: 111.14.0

Summary: Integer Overflow in openssl-src

Details:
Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).
GitHub Security Advisory: GHSA-r7jw-wp68-3xch
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 300.0.0, < 300.0.12
Patched in: 300.0.12

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.

The 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.

This 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`.

Other 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`.
GitHub Security Advisory: GHSA-r7jw-wp68-3xch
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: < 111.25.0
Patched in: 111.25.0

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.

The 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.

This 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`.

Other 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`.
GitHub Security Advisory: GHSA-jc97-h3h9-7xh6
Package: deno (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 1.12.0, < 1.31.0
Patched in: 1.31.0

Summary: Regular Expression Denial of Service in Deno.upgradeWebSocket API

Details:
### Impact
Versions of the package deno before 1.31.0 are vulnerable to Regular Expression Denial of Service (ReDoS) due to the upgradeWebSocket function, which contains regexes in the form of /s*,s*/, used for splitting the Connection/Upgrade header. A specially crafted Connection/Upgrade header can be used to significantly slow down a web socket server. 

### Patches
It is recommended that users upgrade to Deno 1.31.0.
GitHub Security Advisory: GHSA-p9gf-gmfv-398m
Package: slice-deque (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-415: Double Free
Vulnerable versions: <= 0.3.0
Patched in: unpatched

Summary: Double free in slice-deque

Details:
An issue was discovered in the slice-deque crate through 2021-02-19 for Rust. A double drop can occur in SliceDeque::drain_filter upon a panic in a predicate function.
GitHub Security Advisory: GHSA-5r3x-p7xx-x6q5
Package: comrak (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-755: Improper Handling of Exceptional Conditions
Vulnerable versions: < 0.17.0
Patched in: 0.17.0

Summary: Comrak AST node data is not validated (GHSL-2023-049)

Details:
### Impact
A Comrak AST can be constructed manually by a program instead of parsing a Markdown document with `parse_document`. This AST can then be converted to HTML via `html::format_document_with_plugins`. However, the HTML formatting code assumes that the AST is well-formed. For example, many AST notes contain `[u8]` fields which the formatting code assumes is valid UTF-8 data. Several bugs can be triggered if this is not the case.

### Patches

0.17.0 contains adjustments to the AST, storing strings instead of unvalidated byte arrays.

### Workarounds

* Validate UTF-8 correctness of all data when assigning to `&[u8]` and `Vec<u8>` fields in the AST.

### References
n/a
GitHub Security Advisory: GHSA-xxmq-4vph-956w
Package: comrak (RUST)
Severity: MODERATE (CVSS 5.3)
Vulnerable versions: < 0.17.0
Patched in: 0.17.0

Summary: Comrak vulnerable to production of excessive output when parsing Markdown (GHSL-2023-048)

Details:
### Impact

comrak is vulnerable to the upstream cmark issue, ["Issue revealed by fuzzer"](https://github.com/commonmark/cmark/issues/354). A large number of references in a markdown document can trigger an overly large response.

### Patches

0.17.0 contains https://github.com/kivikakk/comrak/commit/70f97f3ea4eae30ffbd1b94c764a3de2f1c41d2a, which limits reference output to a 100Kb maximum.

### Workarounds

n/a

### References

* https://github.com/commonmark/cmark/issues/354
GitHub Security Advisory: GHSA-8hqf-xjwp-p67v
Package: comrak (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 0.17.0
Patched in: 0.17.0

Summary: Comrak vulnerable to quadratic runtime issues when parsing Markdown (GHSL-2023-047)

Details:
### Impact
A range of quadratic parsing issues from `cmark`/`cmark-gfm` are also present in Comrak. These can be used to craft denial-of-service attacks on services that use Comrak to parse Markdown.

### Patches
0.17.0 contains fixes to known quadratic parsing issues.

### Workarounds

n/a

### References

* https://github.com/commonmark/cmark/issues/255
* https://github.com/commonmark/cmark/issues/389
* https://github.com/commonmark/cmark/issues/373
* https://github.com/commonmark/cmark/issues/299
* https://github.com/commonmark/cmark/issues/388
* https://github.com/commonmark/cmark/issues/284
* https://github.com/commonmark/cmark/issues/218
* https://github.com/commonmark/cmark/pull/232
* https://github.com/github/cmark-gfm/blob/c32ef78bae851cb83b7ad52d0fbff880acdcd44a/test/pathological_tests.py#L63-L65
* https://github.com/github/cmark-gfm/blob/c32ef78bae851cb83b7ad52d0fbff880acdcd44a/test/pathological_tests.py#L87-L89
GitHub Security Advisory: GHSA-x4qr-2fvf-3mr5
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.4)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: >= 300.0.0, < 300.0.12
Patched in: 300.0.12

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.

If 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.
GitHub Security Advisory: GHSA-x4qr-2fvf-3mr5
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.4)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: < 111.25.0
Patched in: 111.25.0

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.

If 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.