hitoshura25/cvefixes huggingface dataset:
CVE-2021-29433 (Python, published 2021-04-15T18:15Z)
Description: value: Sydent is a reference Matrix identity server. In Sydent versions 2.2.0 and prior, sissing input validation of some parameters on the endpoints used to confirm third-party identifiers could cause excessive use of disk space and memory leading to resource exhaustion. A patch for the vulnerability is in version 2.3.0. No workarounds are known to exist.
Severity: MEDIUM (CVSS v3 base score: 4.3)
Weakness: CWE-20 \u2014 Improper Input Validation
The product receives input or data, but it does
        not validate or incorrectly validates that the input has the
        properties that are required to process the data safely and
        correctly.
Repository: https://github.com/matrix-org/sydent
Files changed:
sydent/http/servlets/emailservlet.py
sydent/http/servlets/store_invite_servlet.py
sydent/util/stringutils.py
Commit message: Validation improvements

Add some more validation to `client_secret` and `email` parameters.


Vulnerable code:
from sydent.util.stringutils import is_valid_client_secret
client_secret_regex = re.compile(r"^[0-9a-zA-Z\.\=\_\-]+$")
    return client_secret_regex.match(client_secret) is not None

Fixed code:
from sydent.util.stringutils import is_valid_client_secret, MAX_EMAIL_ADDRESS_LENGTH
        if not (0 < len(email) <= MAX_EMAIL_ADDRESS_LENGTH):
            request.setResponseCode(400)
            return {
                'errcode': 'M_INVALID_PARAM',
                'error': 'Invalid email provided'
            }

from sydent.util.stringutils import MAX_EMAIL_ADDRESS_LENGTH

        if not (0 < len(address) <= MAX_EMAIL_ADDRESS_LENGTH):
            request.setResponseCode(400)
            return {
                'errcode': 'M_INVALID_PARAM',
                'error': 'Invalid email provided'
            }

CLIENT_SECRET_REGEX = re.compile(r"^[0-9a-zA-Z\.=_\-]+$")
# it's unclear what the maximum length of an email address is. RFC3696 (as corrected
# by errata) says:
#    the upper limit on address lengths should normally be considered to be 254.
#
# In practice, mail servers appear to be more tolerant and allow 400 characters
# or so. Let's allow 500, which should be plenty for everyone.
#
MAX_EMAIL_ADDRESS_LENGTH = 500

    return (
        0 < len(client_secret) <= 255
        and CLIENT_SECRET_REGEX.match(client_secret) is not None
    )
CVE-2023-38686 (Python, published 2023-08-04T16:15Z)
Description: value: Sydent is an identity server for the Matrix communications protocol. Prior to version 2.5.6, if configured to send emails using TLS, Sydent does not verify SMTP servers' certificates. This makes  Sydent's emails vulnerable to interception via a man-in-the-middle (MITM) attack. Attackers with privileged access to the network can intercept room invitations and address confirmation emails. This is patched in Sydent 2.5.6. When patching, make sure that Sydent trusts the certificate of the server it is connecting to. This should happen automatically when using properly issued certificates. Those who use self-signed certificates should make sure to copy their Certification Authority certificate, or their self signed certificate if using only one, to the trust store of your operating system. As a workaround, one can ensure Sydent's emails fail to send by setting the configured SMTP server to a loopback or non-routable address under one's control which does not have a listening SMTP server.
Severity: nan (CVSS v3 base score: 5.3)
Weakness: CWE-295 \u2014 Improper Certificate Validation
The product does not validate, or incorrectly validates, a certificate.
Repository: https://github.com/matrix-org/sydent
Files changed:
changelog.d/574.bugfix
sydent/util/emailutils.py
Commit message: Explicitly create an SSL context when emailing (#574)



Vulnerable code:
            smtp = smtplib.SMTP_SSL(mailServer, mailPort, myHostname)
            smtp.starttls()

Fixed code:
Fix a long-standing issue where Sydent would not verify the configured SMTP server's certificates. See [GHSA-p6hw-wm59-3q5q](https://github.com/matrix-org/sydent/security/advisories/GHSA-p6hw-wm59-3g5g) and [CVE-2023-38686](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38686). Reported by Martin Schobert, [Pentagrid AG](https://pentagrid.ch).
import ssl
        # Explicitly create a context, to ensure we verify the server's certificate
        # and hostname.
        ctx = ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH)
            smtp = smtplib.SMTP_SSL(mailServer, mailPort, myHostname, context=ctx)
            smtp.starttls(context=ctx)
CVE-2018-25098 (Other, published 2024-02-04T17:15Z)
Description: value: ** UNSUPPORTED WHEN ASSIGNED ** A vulnerability was found in blockmason credit-protocol. It has been declared as problematic. Affected by this vulnerability is the function executeUcacTx of the file contracts/CreditProtocol.sol of the component UCAC Handler. The manipulation leads to denial of service. This product does not use versioning. This is why information about affected and unaffected releases are unavailable. The patch is named 082e01f18707ef995e80ebe97fcedb229a55efc5. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-252799. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
Severity: nan (CVSS v3 base score: 7.5)
Weakness: CWE-672 \u2014 Operation on a Resource after Expiration or Release
The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
Repository: https://github.com/blockmason/credit-protocol
Files changed:
contracts/CreditProtocol.sol
Commit message: 🔒 Fix DoS vulnerability in Credit Protocol contract

`#executeUcacTx` is an inexpensive and unauthenticated function that
increases the transaction counter for a UCAC without actually
performing a transaction, up to that UCAC's transaction limit.

A motivated attacker can call this function continuously to perform
a denial-of-service (DoS) attack on a UCAC, preventing legitimate
transactions using that UCAC from being processed.

Once started, this attack can be maintained indefinitely.

Potential mitigations/effects on a live contract include:

 * An attack on a UCAC may incentivize its stakeholders to unstake
   their tokens.

 * The fewer tokens staked in a UCAC, the less expensive the attack
   becomes to perform and maintain.

 * Staking more tokens in the UCAC will increase the transaction limit,
   thus increasing the cost to perform and maintain the attack.

The best mitigation for this attack, then, for a live contract, would
be for token holders to stake enough tokens in the affected UCAC to
make the attack too expensive for the attacker to maintain.


Vulnerable code:
    function executeUcacTx(address _ucacContractAddr) public {

Fixed code:
    function executeUcacTx(address _ucacContractAddr) private {
CVE-2022-23470 (Python, published 2022-12-06T18:15Z)
Description: value: Galaxy is an open-source platform for data analysis. An arbitrary file read exists in Galaxy 22.01 and Galaxy 22.05 due to the switch to Gunicorn, which can be used to read any file accessible to the operating system user under which Galaxy is running. This vulnerability affects Galaxy 22.01 and higher, after the switch to gunicorn, which serve static contents directly.  Additionally, the vulnerability is mitigated when using Nginx or Apache to serve /static/* contents, instead of Galaxy's internal middleware. This issue has been patched in commit `e5e6bda4f` and will be included in future releases. Users are advised to manually patch their installations. There are no known workarounds for this vulnerability.
Severity: nan (CVSS v3 base score: 7.5)
Weakness: CWE-22 \u2014 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
Repository: https://github.com/galaxyproject/galaxy
Files changed:
lib/galaxy/web/framework/middleware/static.py
Commit message: Contain directory traversal for static files to host static root.


Vulnerable code:
        full = os.path.join(directory, filename)

Fixed code:
        full = self.normpath(os.path.join(directory, filename))
        if not full.startswith(directory):
            # Out of bounds
            return self.not_found(environ, start_response)
CVE-2019-15075 (PHP, published 2020-03-20T18:15Z)
Description: value: An issue was discovered in iNextrix ASTPP before 4.0.1. web_interface/astpp/application/config/config.php does not have strong random keys, as demonstrated by use of the 8YSDaBtDHAB3EQkxPAyTz2I5DttzA9uR private key and the r)fddEw232f encryption key.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-327 \u2014 Use of a Broken or Risky Cryptographic Algorithm
The product uses a broken or risky cryptographic algorithm or protocol.
Repository: https://github.com/iNextrix/ASTPP
Files changed:
config/astpp-config.conf
install.sh
web_interface/astpp/application/config/config.php
Commit message: [IMP] Generating random strong keys


Vulnerable code:

$config ['private_key'] = '8YSDaBtDHAB3EQkxPAyTz2I5DttzA9uR';
$config ['encryption_key'] = 'r)fddEw232f';


Fixed code:
PRIVATE_KEY = <PR_KEY>
ENCRYPTION_KEY = <EN_KEY>
PR_KEY=`echo "$(genpasswd 32)"`
EN_KEY=`echo "$(genpasswd 12)"`
        sed -i "s#<PR_KEY>#${PR_KEY}#g" ${ASTPPDIR}astpp-config.conf
        sed -i "s#<EN_KEY>#${EN_KEY}#g" ${ASTPPDIR}astpp-config.conf
$config ['private_key'] = $astpp_config ['PRIVATE_KEY'];
$config ['encryption_key'] = $astpp_config ['ENCRYPTION_KEY'];
CVE-2019-15075 (PHP, published 2020-03-20T18:15Z)
Description: value: An issue was discovered in iNextrix ASTPP before 4.0.1. web_interface/astpp/application/config/config.php does not have strong random keys, as demonstrated by use of the 8YSDaBtDHAB3EQkxPAyTz2I5DttzA9uR private key and the r)fddEw232f encryption key.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-798 \u2014 Use of Hard-coded Credentials
The product contains hard-coded credentials, such as a password or cryptographic key.
Repository: https://github.com/iNextrix/ASTPP
Files changed:
config/astpp-config.conf
install.sh
web_interface/astpp/application/config/config.php
Commit message: [IMP] Generating random strong keys


Vulnerable code:

$config ['private_key'] = '8YSDaBtDHAB3EQkxPAyTz2I5DttzA9uR';
$config ['encryption_key'] = 'r)fddEw232f';


Fixed code:
PRIVATE_KEY = <PR_KEY>
ENCRYPTION_KEY = <EN_KEY>
PR_KEY=`echo "$(genpasswd 32)"`
EN_KEY=`echo "$(genpasswd 12)"`
        sed -i "s#<PR_KEY>#${PR_KEY}#g" ${ASTPPDIR}astpp-config.conf
        sed -i "s#<EN_KEY>#${EN_KEY}#g" ${ASTPPDIR}astpp-config.conf
$config ['private_key'] = $astpp_config ['PRIVATE_KEY'];
$config ['encryption_key'] = $astpp_config ['ENCRYPTION_KEY'];
CVE-2024-28854 (Unknown, published 2024-03-15T19:15Z)
Description: value: tls-listener is a rust lang wrapper around a connection listener to support TLS. With the default configuration of tls-listener, a malicious user can open 6.4 `TcpStream`s a second, sending 0 bytes, and can trigger a DoS. The default configuration options make any public service using `TlsListener::new()` vulnerable to a slow-loris DoS attack. This impacts any publicly accessible service using the default configuration of tls-listener in versions prior to 0.10.0. Users are advised to upgrade. Users unable to upgrade may mitigate this by passing a large value, such as `usize::MAX` as the parameter to `Builder::max_handshakes`.


Severity: nan (CVSS v3 base score: )
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/tmccombs/tls-listener
Files changed:
Commit message: Merge pull request from GHSA-2qph-qpvm-2qf7

Continue accepting incoming connections if no TLS connection is ready.

Vulnerable code:

Fixed code:
CVE-2022-36038 (Ruby, published 2022-09-06T19:15Z)
Description: value: CircuitVerse is an open-source platform which allows users to construct digital logic circuits online. A remote code execution (RCE) vulnerability in CircuitVerse allows authenticated attackers to execute arbitrary code via specially crafted JSON payloads. This issue may lead to Remote Code Execution (RCE). A patch is available in commit number 7b3023a99499a7675f10f2c1d9effdf10c35fb6e. There are currently no known workarounds.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-502 \u2014 Deserialization of Untrusted Data
The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid.
Repository: https://github.com/CircuitVerse/CircuitVerse
Files changed:
app/helpers/simulator_helper.rb
Commit message: security: use Oj.safe_load to process json payload

`Oj#load` method is not safe for processing user input and can have serious impacts.

Vulnerable code:
    data = Oj.load(data)
    saved_restricted_elements = Oj.load(project.assignment.restrictions)

Fixed code:
    data = Oj.safe_load(data)
    saved_restricted_elements = Oj.safe_load(project.assignment.restrictions)
CVE-2022-4604 (PHP, published 2022-12-18T11:15Z)
Description: value: A vulnerability classified as problematic was found in wp-english-wp-admin Plugin up to 1.5.1. Affected by this vulnerability is the function register_endpoints of the file english-wp-admin.php. The manipulation leads to cross-site request forgery. The attack can be launched remotely. Upgrading to version 1.5.2 is able to address this issue. The name of the patch is ad4ba171c974c65c3456e7c6228f59f40783b33d. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-216199.
Severity: nan (CVSS v3 base score: 8.8)
Weakness: CWE-352 \u2014 Cross-Site Request Forgery (CSRF)
The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.
Repository: https://github.com/khromov/wp-english-wp-admin
Files changed:
english-wp-admin.php
readme.txt
Commit message: Fix vulnerability


Vulnerable code:
Version: 1.5.1
			//Is the GET variable set?
			if(isset($_GET['admin_custom_language_toggle'])) {
				if(isset($_GET['admin_custom_language_return_url'])) {
				$toggle_href = admin_url('?admin_custom_language_toggle=' . ($this->english_admin_enabled() ? '0' : '1') . '&admin_custom_language_return_url=' . urlencode((is_ssl() ? 'https' : 'http') . '://' . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"]));
Stable tag: 1.5.1

Fixed code:
Version: 1.5.2
			
			//Is the GET variables required set?
			if(isset($_GET['admin_custom_language_toggle']) && isset($_GET['nonce'])) {

				if(isset($_GET['admin_custom_language_return_url']) && wp_verify_nonce( $_GET['nonce'], 'english_wordpress_admin_redirect')) {
			
			$toggle_nonce = wp_create_nonce('english_wordpress_admin_redirect');

				$toggle_href = admin_url('?admin_custom_language_toggle=' . ($this->english_admin_enabled() ? '0' : '1') . '&nonce=' . $toggle_nonce . '&admin_custom_language_return_url=' . urlencode((is_ssl() ? 'https' : 'http') . '://' . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"]));
Stable tag: 1.5.2
= 1.5.2 =

* Fix for unauthenticated open redirect vulnerability
CVE-2021-39216 (Unknown, published 2021-09-17T20:15Z)
Description: value: Wasmtime is an open source runtime for WebAssembly & WASI. In Wasmtime from version 0.19.0 and before version 0.30.0 there was a use-after-free bug when passing `externref`s from the host to guest Wasm content. To trigger the bug, you have to explicitly pass multiple `externref`s from the host to a Wasm instance at the same time, either by passing multiple `externref`s as arguments from host code to a Wasm function, or returning multiple `externref`s to Wasm from a multi-value return function defined in the host. If you do not have host code that matches one of these shapes, then you are not impacted. If Wasmtime's `VMExternRefActivationsTable` became filled to capacity after passing the first `externref` in, then passing in the second `externref` could trigger a garbage collection. However the first `externref` is not rooted until we pass control to Wasm, and therefore could be reclaimed by the collector if nothing else was holding a reference to it or otherwise keeping it alive. Then, when control was passed to Wasm after the garbage collection, Wasm could use the first `externref`, which at this point has already been freed. We have reason to believe that the effective impact of this bug is relatively small because usage of `externref` is currently quite rare. The bug has been fixed, and users should upgrade to Wasmtime 0.30.0. If you cannot upgrade Wasmtime yet, you can avoid the bug by disabling reference types support in Wasmtime by passing `false` to `wasmtime::Config::wasm_reference_types`.
Severity: LOW (CVSS v3 base score: 6.3)
Weakness: CWE-416 \u2014 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Repository: https://github.com/bytecodealliance/wasmtime
Files changed:
Commit message: Merge pull request from GHSA-v4cp-h94r-m7xf

Fix a use-after-free bug when passing `ExternRef`s to Wasm

Vulnerable code:

Fixed code:
CVE-2021-39218 (Unknown, published 2021-09-17T21:15Z)
Description: value: Wasmtime is an open source runtime for WebAssembly & WASI. In Wasmtime from version 0.26.0 and before version 0.30.0 is affected by a memory unsoundness vulnerability. There was an invalid free and out-of-bounds read and write bug when running Wasm that uses `externref`s in Wasmtime. To trigger this bug, Wasmtime needs to be running Wasm that uses `externref`s, the host creates non-null `externrefs`, Wasmtime performs a garbage collection (GC), and there has to be a Wasm frame on the stack that is at a GC safepoint where there are no live references at this safepoint, and there is a safepoint with live references earlier in this frame's function. Under this scenario, Wasmtime would incorrectly use the GC stack map for the safepoint from earlier in the function instead of the empty safepoint. This would result in Wasmtime treating arbitrary stack slots as `externref`s that needed to be rooted for GC. At the *next* GC, it would be determined that nothing was referencing these bogus `externref`s (because nothing could ever reference them, because they are not really `externref`s) and then Wasmtime would deallocate them and run `<ExternRef as Drop>::drop` on them. This results in a free of memory that is not necessarily on the heap (and shouldn't be freed at this moment even if it was), as well as potential out-of-bounds reads and writes. Even though support for `externref`s (via the reference types proposal) is enabled by default, unless you are creating non-null `externref`s in your host code or explicitly triggering GCs, you cannot be affected by this bug. We have reason to believe that the effective impact of this bug is relatively small because usage of `externref` is currently quite rare. This bug has been patched and users should upgrade to Wasmtime version 0.30.0. If you cannot upgrade Wasmtime at this time, you can avoid this bug by disabling the reference types proposal by passing `false` to `wasmtime::Config::wasm_reference_types`.
Severity: LOW (CVSS v3 base score: 6.3)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/bytecodealliance/wasmtime
Files changed:
Commit message: Merge pull request from GHSA-4873-36h9-wv49

Stop doing fuzzy search for stack maps

Vulnerable code:

Fixed code:
CVE-2021-39218 (Unknown, published 2021-09-17T21:15Z)
Description: value: Wasmtime is an open source runtime for WebAssembly & WASI. In Wasmtime from version 0.26.0 and before version 0.30.0 is affected by a memory unsoundness vulnerability. There was an invalid free and out-of-bounds read and write bug when running Wasm that uses `externref`s in Wasmtime. To trigger this bug, Wasmtime needs to be running Wasm that uses `externref`s, the host creates non-null `externrefs`, Wasmtime performs a garbage collection (GC), and there has to be a Wasm frame on the stack that is at a GC safepoint where there are no live references at this safepoint, and there is a safepoint with live references earlier in this frame's function. Under this scenario, Wasmtime would incorrectly use the GC stack map for the safepoint from earlier in the function instead of the empty safepoint. This would result in Wasmtime treating arbitrary stack slots as `externref`s that needed to be rooted for GC. At the *next* GC, it would be determined that nothing was referencing these bogus `externref`s (because nothing could ever reference them, because they are not really `externref`s) and then Wasmtime would deallocate them and run `<ExternRef as Drop>::drop` on them. This results in a free of memory that is not necessarily on the heap (and shouldn't be freed at this moment even if it was), as well as potential out-of-bounds reads and writes. Even though support for `externref`s (via the reference types proposal) is enabled by default, unless you are creating non-null `externref`s in your host code or explicitly triggering GCs, you cannot be affected by this bug. We have reason to believe that the effective impact of this bug is relatively small because usage of `externref` is currently quite rare. This bug has been patched and users should upgrade to Wasmtime version 0.30.0. If you cannot upgrade Wasmtime at this time, you can avoid this bug by disabling the reference types proposal by passing `false` to `wasmtime::Config::wasm_reference_types`.
Severity: LOW (CVSS v3 base score: 6.3)
Weakness: CWE-590 \u2014 Free of Memory not on the Heap
The product calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().
Repository: https://github.com/bytecodealliance/wasmtime
Files changed:
Commit message: Merge pull request from GHSA-4873-36h9-wv49

Stop doing fuzzy search for stack maps

Vulnerable code:

Fixed code: