hitoshura25/cvefixes huggingface dataset:
CVE-2020-11071 (TypeScript, published 2020-05-12T01:15Z)
Description: value: SLPJS (npm package slpjs) before version 0.27.2, has a vulnerability where users could experience false-negative validation outcomes for MINT transaction operations. A poorly implemented SLP wallet could allow spending of the affected tokens which would result in the destruction of a user's minting baton. This is fixed in version 0.27.2.
Severity: MEDIUM (CVSS v3 base score: 8.6)
Weakness: CWE-697 \u2014 Incorrect Comparison
The product compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.
Repository: https://github.com/simpleledger/slpjs
Files changed:
lib/localvalidator.ts
Commit message: fix false negative case for MINT transactions

See the newly added unit test case for this issue.
Currently there are 151 unit tests.


Vulnerable code:
            if (this.cachedValidations[txid].parents.length !== 1) {
                this.cachedValidations[txid].invalidReason = "MINT transaction must have 1 valid baton parent.";
        for (let i = 0; i < parentTxids.length; i++) {
            const valid = await this.isValidSlpTxid(parentTxids[i]);
            this.cachedValidations[txid].parents.filter(p => p.txid === parentTxids[i]).map(p => p.valid = valid);
            if (this.cachedValidations[txid].details!.transactionType === SlpTransactionType.MINT && !valid) {

Fixed code:
            if (this.cachedValidations[txid].parents.length < 1) {
                this.cachedValidations[txid].invalidReason = "MINT transaction must have at least 1 candidate baton parent input.";
        for (const id of parentTxids) {
            const valid = await this.isValidSlpTxid(id);
            this.cachedValidations[txid].parents.filter(p => p.txid === id).map(p => p.valid = valid);
        }

        // Check MINT for exactly 1 valid MINT baton
        if (this.cachedValidations[txid].details!.transactionType === SlpTransactionType.MINT) {
            if (this.cachedValidations[txid].parents.filter(p => p.valid && p.inputQty === null).length !== 1) {
CVE-2022-4735 (JavaScript, published 2022-12-25T16:15Z)
Description: value: A vulnerability classified as problematic was found in asrashley dash-live. This vulnerability affects the function ready of the file static/js/media.js of the component DOM Node Handler. The manipulation leads to cross site scripting. The attack can be initiated remotely. The name of the patch is 24d01757a5319cc14c4aa1d8b53d1ab24d48e451. It is recommended to apply a patch to fix this issue. VDB-216766 is the identifier assigned to this vulnerability.
Severity: nan (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
Repository: https://github.com/asrashley/dash-live
Files changed:
static/js/media.js
Commit message: escape strings before using them in HTML tags

Extracting text from a DOM node and interpreting it as HTML can lead
to a cross-site scripting vulnerability.


Vulnerable code:
        dialog.find(".modal-body").html('<p>Indexing ' + filename + '</p><div class="error"></div>');
                dialog.find(".modal-body").html('<p>Indexing ' + filename + ' complete</p>');
                          $row.find('td.kid').append('<p>'+result.representation.kids[i]+'</p>');
        dialog.find(".modal-body").html('<p>Uploading ' + filename + '</p><div class="error"></div>');
            dialog.find(".modal-body").html('<p>Finished uploading ' + filename+ '<span class="bool-yes ">&check;</span>');

Fixed code:
        dialog.find(".modal-body").html('<p>Indexing ' + encodeURIComponent(filename) +
                                        '</p><div class="error"></div>');
                dialog.find(".modal-body").html('<p>Indexing ' +
                                                encodeURIComponent(filename) +
                                                ' complete</p>');
                            $row.find('td.kid').append(
                                '<p>' +
                                encodeURIComponent(result.representation.kids[i]) +
                                '</p>');
        dialog.find(".modal-body").html('<p>Uploading ' +
                                        encodeURIComponent(filename) +
                                        '</p><div class="error"></div>');
            dialog.find(".modal-body").html('<p>Finished uploading ' +
                                            encodeURIComponent(filename) +
                                            '<span class="bool-yes ">&check;</span>');
CVE-2024-27284 (Unknown, published 2024-02-29T01:44Z)
Description: value: cassandra-rs is a Cassandra (CQL) driver for Rust. Code that attempts to use an item (e.g., a row) returned by an iterator after the iterator has advanced to the next item will be accessing freed memory and experience undefined behaviour.  The problem has been fixed in version 3.0.0.

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/Metaswitch/cassandra-rs
Files changed:
Commit message: Merge pull request from GHSA-x9xc-63hg-vcfq

Make `ResultIterator` a `LendingIterator`

Vulnerable code:

Fixed code:
CVE-2020-28270 (JavaScript, published 2020-11-12T18:15Z)
Description: value: Prototype pollution vulnerability in 'object-hierarchy-access' versions 0.2.0 through 0.32.0 allows attacker to cause a denial of service and may lead to remote code execution.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-1321 \u2014 Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
The product receives input from an upstream component that specifies attributes that are to be initialized or updated in an object, but it does not properly control modifications of attributes of the object prototype.
Repository: https://github.com/mjpclab/object-hierarchy-access
Files changed:
built/setup.js
src/setup.ts
test/set/7-no-proto-polution.js
test/set/index.js
Commit message: fix(setup): prevent assigning value to `__proto__`

Assigning value to `__proto__` polutes `Object.prototype`.

Reported by Daniel Elkabes from White Source Software.


Vulnerable code:
        if (forceOverride || override || !current[name] || typeof current[name] !== 'object') {
		if (forceOverride || override || !current[name] || typeof current[name] !== 'object') {

Fixed code:
const propProto = '__proto__';
        if (forceOverride ||
            override ||
            !current[name] ||
            typeof current[name] !== 'object' ||
            (name === propProto && current[name] === Object.prototype)) {
const propProto = '__proto__';

		if (
			forceOverride ||
			override ||
			!current[name] ||
			typeof current[name] !== 'object' ||
			(name === propProto && current[name] === Object.prototype)
		) {
const assert = require('assert').strict;
const {set} = require('../../');

const obj1 = {};
const obj2 = {};
set(obj1, '__proto__', 'admin', true);
assert.notEqual(obj1.__proto__, Object.prototype);
assert.equal(obj1.__proto__.admin, true);
assert.strictEqual(obj2.admin, undefined);
require('./7-no-proto-polution');
CVE-2010-1152 (C, published 2010-04-12T18:30Z)
Description: value: memcached.c in memcached before 1.4.3 allows remote attackers to cause a denial of service (daemon hang or crash) via a long line that triggers excessive memory allocation.  NOTE: some of these details are obtained from third party information.
Severity: MEDIUM (CVSS v3 base score: )
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/memcached/memcached
Files changed:
memcached.c
Commit message: Use strncmp when checking for large ascii multigets.


Vulnerable code:
                if (strcmp(ptr, "get ") && strcmp(ptr, "gets ")) {

Fixed code:
                if (ptr - c->rcurr > 100 ||
                    (strncmp(ptr, "get ", 4) && strncmp(ptr, "gets ", 5))) {
CVE-2010-1152 (C, published 2010-04-12T18:30Z)
Description: value: memcached.c in memcached before 1.4.3 allows remote attackers to cause a denial of service (daemon hang or crash) via a long line that triggers excessive memory allocation.  NOTE: some of these details are obtained from third party information.
Severity: MEDIUM (CVSS v3 base score: )
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/memcached/memcached
Files changed:
memcached.c
testapp.c
Commit message: Issue 102: Piping null to the server will crash it


Vulnerable code:
        if (!el)


Fixed code:

        if (!el) {
            if (c->rbytes > 1024) {
                /*
                 * We didn't have a '\n' in the first k. This _has_ to be a
                 * large multiget, if not we should just nuke the connection.
                 */
                char *ptr = c->rcurr;
                while (*ptr == ' ') { /* ignore leading whitespaces */
                    ++ptr;
                }

                if (strcmp(ptr, "get ") && strcmp(ptr, "gets ")) {
                    conn_set_state(c, conn_closing);
                    return 1;
                }
            }

        }
 *
 * To protect us from someone flooding a connection with bogus data causing
 * the connection to eat up all available memory, break out and start looking
 * at the data I've got after a number of reallocs...
 *
    int num_allocs = 0;
            if (num_allocs == 4) {
                return gotdata;
            }
            ++num_allocs;
static enum test_return test_issue_102(void) {
    char buffer[4096];
    memset(buffer, ' ', sizeof(buffer));
    buffer[sizeof(buffer) - 1] = '\0';

    close(sock);
    sock = connect_server("127.0.0.1", port, false);

    send_ascii_command(buffer);
    /* verify that the server closed the connection */
    assert(read(sock, buffer, sizeof(buffer)) == 0);
    close(sock);
    sock = connect_server("127.0.0.1", port, false);
    return TEST_PASS;
}

    { "issue_102", test_issue_102 },
CVE-2018-1000115 (Other, published 2018-03-05T14:29Z)
Description: value: Memcached version 1.5.5 contains an Insufficient Control of Network Message Volume (Network Amplification, CWE-406) vulnerability in the UDP support of the memcached server that can result in denial of service via network flood (traffic amplification of 1:50,000 has been reported by reliable sources). This attack appear to be exploitable via network connectivity to port 11211 UDP. This vulnerability appears to have been fixed in 1.5.6 due to the disabling of the UDP protocol by default.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-400 \u2014 Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.
Repository: https://github.com/memcached/memcached
Files changed:
memcached.c
t/issue_67.t
Commit message: disable UDP port by default

As reported, UDP amplification attacks have started to use insecure
internet-exposed memcached instances. UDP used to be a lot more popular as a
transport for memcached many years ago, but I'm not aware of many recent
users.

Ten years ago, the TCP connection overhead from many clients was relatively
high (dozens or hundreds per client server), but these days many clients are
batched, or user fewer processes, or simply anre't worried about it.

While changing the default to listen on localhost only would also help, the
true culprit is UDP. There are many more use cases for using memcached over
the network than there are for using the UDP protocol.


Vulnerable code:
    settings.udpport = 11211;
    if (tcp_specified && settings.port != 0 && !udp_specified) {
        settings.udpport = settings.port;
    } else if (udp_specified && settings.udpport != 0 && !tcp_specified) {
when('specifying tcp port', '-p 11212', 11212, 11212);
when('tcp port disabled', '-p 0', -1, 11211);

Fixed code:
    settings.udpport = 0;
    if (udp_specified && settings.udpport != 0 && !tcp_specified) {
when('specifying tcp port', '-p 11212', 11212, -1);
when('tcp port disabled', '-p 0', -1, -1);
CVE-2018-1000127 (C, published 2018-03-13T21:29Z)
Description: value: memcached version prior to 1.4.37 contains an Integer Overflow vulnerability in items.c:item_free() that can result in data corruption and deadlocks due to items existing in hash table being reused from free list. This attack appear to be exploitable via network connectivity to the memcached service. This vulnerability appears to have been fixed in 1.4.37 and later.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/memcached/memcached
Files changed:
memcached.c
Commit message: Don't overflow item refcount on get

Counts as a miss if the refcount is too high. ASCII multigets are the only
time refcounts can be held for so long.

doing a dirty read of refcount. is aligned.

trying to avoid adding an extra refcount branch for all calls of item_get due
to performance. might be able to move it in there after logging refactoring
simplifies some of the branches.


Vulnerable code:
            it = item_get(key, nkey, c, DO_UPDATE);

Fixed code:
#define IT_REFCOUNT_LIMIT 60000
static inline item* limited_get(char *key, size_t nkey, conn *c) {
    item *it = item_get(key, nkey, c, DO_UPDATE);
    if (it && it->refcount > IT_REFCOUNT_LIMIT) {
        item_remove(it);
        it = NULL;
    }
    return it;
}

            it = limited_get(key, nkey, c);
CVE-2018-1000127 (C, published 2018-03-13T21:29Z)
Description: value: memcached version prior to 1.4.37 contains an Integer Overflow vulnerability in items.c:item_free() that can result in data corruption and deadlocks due to items existing in hash table being reused from free list. This attack appear to be exploitable via network connectivity to the memcached service. This vulnerability appears to have been fixed in 1.4.37 and later.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-667 \u2014 Improper Locking
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
Repository: https://github.com/memcached/memcached
Files changed:
memcached.c
Commit message: Don't overflow item refcount on get

Counts as a miss if the refcount is too high. ASCII multigets are the only
time refcounts can be held for so long.

doing a dirty read of refcount. is aligned.

trying to avoid adding an extra refcount branch for all calls of item_get due
to performance. might be able to move it in there after logging refactoring
simplifies some of the branches.


Vulnerable code:
            it = item_get(key, nkey, c, DO_UPDATE);

Fixed code:
#define IT_REFCOUNT_LIMIT 60000
static inline item* limited_get(char *key, size_t nkey, conn *c) {
    item *it = item_get(key, nkey, c, DO_UPDATE);
    if (it && it->refcount > IT_REFCOUNT_LIMIT) {
        item_remove(it);
        it = NULL;
    }
    return it;
}

            it = limited_get(key, nkey, c);
CVE-2019-11596 (C, published 2019-04-29T15:29Z)
Description: value: In memcached before 1.5.14, a NULL pointer dereference was found in the "lru mode" and "lru temp_ttl" commands. This causes a denial of service when parsing crafted lru command messages in process_lru_command in memcached.c.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-476 \u2014 NULL Pointer Dereference
The product dereferences a pointer that it expects to be valid but is NULL.
Repository: https://github.com/memcached/memcached
Files changed:
memcached.c
Commit message: fix segfault in "lru" command

fixes #474 - off by one in token count.


Vulnerable code:
    } else if (strcmp(tokens[1].value, "mode") == 0 && ntokens >= 3 &&
    } else if (strcmp(tokens[1].value, "temp_ttl") == 0 && ntokens >= 3 &&

Fixed code:
    } else if (strcmp(tokens[1].value, "mode") == 0 && ntokens >= 4 &&
    } else if (strcmp(tokens[1].value, "temp_ttl") == 0 && ntokens >= 4 &&
CVE-2019-15026 (C, published 2019-08-30T15:15Z)
Description: value: memcached 1.5.16, when UNIX sockets are used, has a stack-based buffer over-read in conn_to_str in memcached.c.
Severity: MEDIUM (CVSS v3 base score: 7.5)
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/memcached/memcached
Files changed:
memcached.c
Commit message: fix strncpy call to avoid ASAN violation

Ensure we're only reading to the size of the smallest buffer, since
they're both on the stack and could potentially overlap. Overlapping is
defined as ... undefined behavior. I've looked through all available
implementations of strncpy and they still only copy from the first \0
found.

We'll also never read past the end of sun_path since we _supply_
sun_path with a proper null terminator.


Vulnerable code:
                    sizeof(addr_text) - 1);
            addr_text[sizeof(addr_text)-1] = '\0';

Fixed code:
    size_t pathlen = 0;
            // this strncpy call originally could piss off an address
            // sanitizer; we supplied the size of the dest buf as a limiter,
            // but optimized versions of strncpy could read past the end of
            // *src while looking for a null terminator. Since buf and
            // sun_path here are both on the stack they could even overlap,
            // which is "undefined". In all OSS versions of strncpy I could
            // find this has no effect; it'll still only copy until the first null
            // terminator is found. Thus it's possible to get the OS to
            // examine past the end of sun_path but it's unclear to me if this
            // can cause any actual problem.
            //
            // We need a safe_strncpy util function but I'll punt on figuring
            // that out for now.
            pathlen = sizeof(((struct sockaddr_un *)sock_addr)->sun_path);
            if (MAXPATHLEN <= pathlen) {
                pathlen = MAXPATHLEN - 1;
            }
                    pathlen);
            addr_text[pathlen] = '\0';
CVE-2020-10931 (C, published 2020-03-24T15:15Z)
Description: value: Memcached 1.6.x before 1.6.2 allows remote attackers to cause a denial of service (daemon crash) via a crafted binary protocol header to try_read_command_binary in memcached.c.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-120 \u2014 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
Repository: https://github.com/memcached/memcached
Files changed:
memcached.c
Commit message: Fix security issue reported by someone.

someone will get their name attributed for future issues if they bother
following procedure.


Vulnerable code:
        char extbuf[sizeof(c->binary_header) + BIN_MAX_EXTLEN];
        memcpy(extbuf + sizeof(c->binary_header), c->rcurr + sizeof(c->binary_header), extlen);

Fixed code:
        char extbuf[sizeof(c->binary_header) + BIN_MAX_EXTLEN+1];
        memcpy(extbuf + sizeof(c->binary_header), c->rcurr + sizeof(c->binary_header),
                extlen > BIN_MAX_EXTLEN ? BIN_MAX_EXTLEN : extlen);
CVE-2022-48571 (C, published 2023-08-22T19:16Z)
Description: value: memcached 1.6.7 allows a Denial of Service via multi-packet uploads in UDP.
Severity: nan (CVSS v3 base score: 7.5)
Weakness: CWE-400 \u2014 Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.
Repository: https://github.com/memcached/memcached
Files changed:
memcached.c
Commit message: udp: crash fix when receiving multi-packet uploads

multi-packet sets aren't supported in UDP. It was trying to write an
error message in response, but no mc_resp object was initialized at the
time, leading to a null reference crash.

Instead drop the packet quietly since that's a pretty fatal bug anyway
and keeps the parser simplified.

For credits see accompanying release notes.


Vulnerable code:
    assert(c != NULL);
            out_string(c, "SERVER_ERROR multi-packet request not supported");

Fixed code:
    assert(c != NULL);
CVE-2023-46852 (Other, published 2023-10-27T20:15Z)
Description: value: In Memcached before 1.6.22, a buffer overflow exists when processing multiget requests in proxy mode, if there are many spaces after the "get" substring.
Severity: nan (CVSS v3 base score: 7.5)
Weakness: CWE-120 \u2014 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
Repository: https://github.com/memcached/memcached
Files changed:
proto_proxy.c
t/proxyunits.t
Commit message: proxy: fix buffer overflow with multiget syntax

"get[200 spaces]key1 key2\r\n" would overflow a temporary buffer used to
process multiget syntax.

To exploit this you must first pass the check in try_read_command_proxy:
- The request before the first newline must be less than 1024 bytes.
- If it is more than 1024 bytes there is a limit of 100 spaces.
- The key length is still checked at 250 bytes
- Meaning you have up to 772 spaces and then the key to create stack
  corruption.

So the amount of data you can shove in here isn't unlimited.

The fix caps the amount of data pre-key to be reasonable. Something like
GAT needs space for a 32bit TTL which is at most going to be 15 bytes +
spaces, so we limit it to 20 bytes.

I hate hate hate hate hate the multiget syntax. hate it.


Vulnerable code:
            char temp[KEY_MAX_LENGTH + 30];
            if (pr.klen > KEY_MAX_LENGTH) {

Fixed code:
// basically any data before the first key.
// max is like 15ish plus spaces. we can be more strict about how many spaces
// to expect because any client spamming space is being deliberately stupid
// anyway.
#define MAX_CMD_PREFIX 20

            char temp[KEY_MAX_LENGTH + MAX_CMD_PREFIX + 30];
            if (pr.tokens[pr.keytoken] > MAX_CMD_PREFIX) {
                if (!resp_start(c)) {
                    conn_set_state(c, conn_closing);
                    return;
                }
                proxy_out_errstring(c->resp, PROXY_CLIENT_ERROR, "malformed request");
            } else if (pr.klen > KEY_MAX_LENGTH) {

    my $space = ' ' x 200;
    print $ps "get$space key key\r\n";
    is(scalar <$ps>, "CLIENT_ERROR malformed request\r\n");
    is(scalar <$ps>, "CLIENT_ERROR malformed request\r\n");
    is(scalar <$ps>, "END\r\n"); # god damn multiget syntax.