hitoshura25/cvefixes huggingface dataset:
CVE-2023-25805 (JavaScript, published 2023-02-20T16:15Z)
Description: value: versionn, software for changing version information across multiple files, has a command injection vulnerability in all versions prior to version 1.1.0. This issue is patched in version 1.1.0.
Severity: nan (CVSS v3 base score: 9.8)
Weakness: CWE-77 \u2014 Improper Neutralization of Special Elements used in a Command ('Command Injection')
The product constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component.
Repository: https://github.com/commenthol/versionn
Files changed:
lib/gitfn.js
test/test.js
Commit message: fix: Command Injection Vuln


Vulnerable code:
var child = require('child_process')

function GitFn (version, options) {
  this._version = version
  this._options = {
    cwd: options.dir,
    env: process.env,
    setsid: false,
    stdio: [0, 1, 2]
module.exports = GitFn
GitFn.prototype = {
  tag: function (cb) {
    var cmd = ['git', 'tag', 'v' + this._version].join(' ')
    this._exec(cmd, cb)
  },
  untag: function (cb) {
    var cmd = ['git', 'tag', '-d', 'v' + this._version].join(' ')
    this._exec(cmd, cb)
  },
  commit: function (cb) {
    var cmd = ['git', 'commit', '-am', '"' + this._version + '"'].join(' ')
    this._exec(cmd, cb)
  },
  _exec: function (cmd, cb) {
    child.exec(cmd, this._options, cb)

Fixed code:
const child = require('child_process')
const semver = require('semver')

const assertVersionValid = version => {
  if (!semver.valid(version)) {
    throw new Error('version is invalid')
const exec = (cmd, options, cb) => child.exec(cmd, options, cb)

class GitFn {
  constructor (version, options) {
    this._version = version
    this._options = {
      cwd: options.dir,
      env: process.env,
      setsid: false,
      stdio: [0, 1, 2]
    }
  }

  tag (cb) {
    assertVersionValid(this._version)
    const cmd = ['git', 'tag', 'v' + this._version].join(' ')
    exec(cmd, this._options, cb)
  }

  untag (cb) {
    assertVersionValid(this._version)
    const cmd = ['git', 'tag', '-d', 'v' + this._version].join(' ')
    exec(cmd, this._options, cb)
  }

  commit (cb) {
    assertVersionValid(this._version)
    const cmd = ['git', 'commit', '-am', '"' + this._version + '"'].join(' ')
    exec(cmd, this._options, cb)

module.exports = GitFn

  it('shall throw if not a valid version', function (done) {
    const gitFn = new Version._.GitFn('& touch newFile', { dir: './' })
    try {
      gitFn.tag(done)
    } catch (e) {
      assert.strictEqual(e.message, 'version is invalid')
      done()
    }
  })
CVE-2010-3844 (C, published 2019-11-12T22:15Z)
Description: value: An unchecked sscanf() call in ettercap before 0.7.5 allows an insecure temporary settings file to overflow a static-sized buffer on the stack.
Severity: MEDIUM (CVSS v3 base score: 8.8)
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/Ettercap/ettercap
Files changed:
src/interfaces/gtk/ec_gtk_conf.c
src/interfaces/gtk/ec_gtk_mitm.c
Commit message: More changes to mitigate:
CVE-2010-3843
CVE-2010-3844


Vulnerable code:
   /* TODO: get the dopped privs home dir instead of "/root" */
   /* path = g_get_home_dir(); */
   path = g_get_tmp_dir();
      strncat(params, gtk_entry_get_text(GTK_ENTRY(entry1)), PARAMS_LEN);
      strncat(params, "/", PARAMS_LEN);
      strncat(params, gtk_entry_get_text(GTK_ENTRY(entry2)), PARAMS_LEN);

Fixed code:
   path = g_get_home_dir();
      strncat(params, gtk_entry_get_text(GTK_ENTRY(entry1)), ETH_ASCII_ADDR_LEN);
      strncat(params, "/", 1);
      strncat(params, gtk_entry_get_text(GTK_ENTRY(entry2)), IP6_ASCII_ADDR_LEN);
CVE-2014-6395 (C, published 2014-12-19T15:59Z)
Description: value: Heap-based buffer overflow in the dissector_postgresql function in dissectors/ec_postgresql.c in Ettercap before 0.8.1 allows remote attackers to cause a denial of service or possibly execute arbitrary code via a crafted password length value that is inconsistent with the actual length of the password.
Severity: HIGH (CVSS v3 base score: )
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/Ettercap/ettercap
Files changed:
src/dissectors/ec_postgresql.c
Commit message: Fixed heap overflow caused by length


Vulnerable code:
   u_char password[65];
               strncpy((char*)conn_status->password, (char*)(ptr + 5), length - 4);
               conn_status->password[length - 4] = 0;

Fixed code:
   u_char password[66];
               length -= 4;
               if (length < 0 || length > 65 || PACKET->DATA.len < length+5) {
                   dissect_wipe_session(PACKET, DISSECT_CODE(dissector_postgresql));
                   return NULL;
               }
               snprintf((char*)conn_status->password, length+1, "%s", (char*)(ptr + 5));
CVE-2014-6396 (C, published 2014-12-19T15:59Z)
Description: value: The dissector_postgresql function in dissectors/ec_postgresql.c in Ettercap before 0.8.1 allows remote attackers to cause a denial of service and possibly execute arbitrary code via a crafted password length, which triggers a 0 character to be written to an arbitrary memory location.
Severity: HIGH (CVSS v3 base score: )
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/Ettercap/ettercap
Files changed:
src/dissectors/ec_postgresql.c
Commit message: Fixed heap overflow caused by length


Vulnerable code:
   u_char password[65];
               strncpy((char*)conn_status->password, (char*)(ptr + 5), length - 4);
               conn_status->password[length - 4] = 0;

Fixed code:
   u_char password[66];
               length -= 4;
               if (length < 0 || length > 65 || PACKET->DATA.len < length+5) {
                   dissect_wipe_session(PACKET, DISSECT_CODE(dissector_postgresql));
                   return NULL;
               }
               snprintf((char*)conn_status->password, length+1, "%s", (char*)(ptr + 5));
CVE-2019-25048 (C, published 2021-07-01T03:15Z)
Description: value: LibreSSL 2.9.1 through 3.2.1 has a heap-based buffer over-read in do_print_ex (called from asn1_item_print_ctx and ASN1_item_print).
Severity: MEDIUM (CVSS v3 base score: 7.1)
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/libressl-portable/portable
Files changed:
include/compat/pthread.h
Commit message: Make pthread_mutex static initialisation work on Windows.

This takes the dynamic initialisation code added to CRYPTO_lock() in e5081719
and applies it to the Window's pthread_mutex implementation. This allows for
PTHREAD_MUTEX_INITIALIZER to be used on Windows.

bcook has agreed to place this code in the public domain (as per the rest of
the code in pthread.h).


Vulnerable code:
#define PTHREAD_MUTEX_INITIALIZER	{ 0, 0, 0, 0, 0, 0 }
typedef CRITICAL_SECTION pthread_mutex_t;
	InitializeCriticalSection(mutex);
	EnterCriticalSection(mutex);
	LeaveCriticalSection(mutex);

Fixed code:
#include <malloc.h>
#include <stdlib.h>
#define PTHREAD_MUTEX_INITIALIZER	{ .lock = NULL }
struct pthread_mutex {
	volatile LPCRITICAL_SECTION lock;
};
typedef struct pthread_mutex pthread_mutex_t;
	if ((mutex->lock = malloc(sizeof(CRITICAL_SECTION))) == NULL)
		exit(ENOMEM);
	InitializeCriticalSection(mutex->lock);
	if (mutex->lock == NULL) {
		LPCRITICAL_SECTION lcs;

		if ((lcs = malloc(sizeof(CRITICAL_SECTION))) == NULL)
			exit(ENOMEM);
		InitializeCriticalSection(lcs);
		if (InterlockedCompareExchangePointer((PVOID*)&mutex->lock, (PVOID)lcs, NULL) != NULL) {
			DeleteCriticalSection(lcs);
			free(lcs);
		}
	}
	EnterCriticalSection(mutex->lock);
	LeaveCriticalSection(mutex->lock);
CVE-2019-25049 (C, published 2021-07-01T03:15Z)
Description: value: LibreSSL 2.9.1 through 3.2.1 has an out-of-bounds read in asn1_item_print_ctx (called from asn1_template_print_ctx).
Severity: MEDIUM (CVSS v3 base score: 7.1)
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/libressl-portable/portable
Files changed:
include/compat/pthread.h
Commit message: Make pthread_mutex static initialisation work on Windows.

This takes the dynamic initialisation code added to CRYPTO_lock() in e5081719
and applies it to the Window's pthread_mutex implementation. This allows for
PTHREAD_MUTEX_INITIALIZER to be used on Windows.

bcook has agreed to place this code in the public domain (as per the rest of
the code in pthread.h).


Vulnerable code:
#define PTHREAD_MUTEX_INITIALIZER	{ 0, 0, 0, 0, 0, 0 }
typedef CRITICAL_SECTION pthread_mutex_t;
	InitializeCriticalSection(mutex);
	EnterCriticalSection(mutex);
	LeaveCriticalSection(mutex);

Fixed code:
#include <malloc.h>
#include <stdlib.h>
#define PTHREAD_MUTEX_INITIALIZER	{ .lock = NULL }
struct pthread_mutex {
	volatile LPCRITICAL_SECTION lock;
};
typedef struct pthread_mutex pthread_mutex_t;
	if ((mutex->lock = malloc(sizeof(CRITICAL_SECTION))) == NULL)
		exit(ENOMEM);
	InitializeCriticalSection(mutex->lock);
	if (mutex->lock == NULL) {
		LPCRITICAL_SECTION lcs;

		if ((lcs = malloc(sizeof(CRITICAL_SECTION))) == NULL)
			exit(ENOMEM);
		InitializeCriticalSection(lcs);
		if (InterlockedCompareExchangePointer((PVOID*)&mutex->lock, (PVOID)lcs, NULL) != NULL) {
			DeleteCriticalSection(lcs);
			free(lcs);
		}
	}
	EnterCriticalSection(mutex->lock);
	LeaveCriticalSection(mutex->lock);
CVE-2019-16058 (C, published 2019-09-06T18:15Z)
Description: value: An issue was discovered in the pam_p11 component 0.2.0 and 0.3.0 for OpenSC. If a smart card creates a signature with a length longer than 256 bytes, this triggers a buffer overflow. This may be the case for RSA keys with 4096 bits depending on the signature scheme.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/OpenSC/pam_p11
Files changed:
src/pam_p11.c
Commit message: Use EVP_PKEY_size() to allocate correct size of signature buffer. (#18)

Do not use fixed buffer size for signature, EVP_SignFinal() requires
buffer for signature at least  EVP_PKEY_size(pkey) bytes in size.

Fixes crash when using 4K RSA signatures (https://github.com/OpenSC/pam_p11/issues/16, https://github.com/OpenSC/pam_p11/issues/15)

Vulnerable code:
	unsigned char signature[256];
	unsigned int siglen = sizeof signature;

Fixed code:
#include <stdlib.h>
	unsigned char *signature = NULL;
	unsigned int siglen;
	if (NULL == privkey)
		goto err;
	siglen = EVP_PKEY_size(privkey);
	if (siglen <= 0)
		goto err;
	signature = malloc(siglen);
	if (NULL == signature)
		goto err;

	free(signature);
CVE-2023-3620 (JavaScript, published 2023-07-11T15:15Z)
Description: value: Cross-site Scripting (XSS) - Stored in GitHub repository amauric/tarteaucitron.js prior to v1.13.1.
Severity: nan (CVSS v3 base score: 5.4)
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/amauric/tarteaucitron.js
Files changed:
tarteaucitron.js
Commit message: Filter the attr to avoid possible XSS vulnerability Fix #1132


Vulnerable code:
        return elem.getAttribute('data-' + attr) || elem.getAttribute(attr);

Fixed code:
        var attribute = elem.getAttribute('data-' + attr) || elem.getAttribute(attr);

        if (typeof attribute === 'string') {
            return tarteaucitron.fixSelfXSS(attribute);
        }

        return "";
CVE-2014-125084 (PHP, published 2023-02-06T00:15Z)
Description: value: A vulnerability, which was classified as critical, has been found in Gimmie Plugin 1.2.2 on vBulletin. This issue affects some unknown processing of the file trigger_referral.php. The manipulation of the argument referrername leads to sql injection. Upgrading to version 1.3.0 is able to address this issue. The identifier of the patch is 7194a09353dd24a274678383a4418f2fd3fce6f7. It is recommended to upgrade the affected component. The identifier VDB-220205 was assigned to this vulnerability.
Severity: nan (CVSS v3 base score: 9.8)
Weakness: CWE-89 \u2014 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
Repository: https://github.com/gimmie/vbulletin-v4
Files changed:
Upload/plugins/gimmie/trigger_referral.php
Commit message: Update trigger_referral.php to prevent SQL Injection

Vulnerable code:
$usersql  = $vbulletin->db->query_read("SELECT `userid`, `username`, `email` FROM " . TABLE_PREFIX . "user WHERE `username` = '" . $_POST['referrername'] . "'");
?>

Fixed code:
$usersql  = $vbulletin->db->query_read("SELECT `userid`, `username`, `email` FROM " . TABLE_PREFIX . "user WHERE `username` = " . $vbulletin->db->escape_string($_POST['referrername']));
?>
CVE-2014-125085 (PHP, published 2023-02-06T00:15Z)
Description: value: A vulnerability, which was classified as critical, was found in Gimmie Plugin 1.2.2 on vBulletin. Affected is an unknown function of the file trigger_ratethread.php. The manipulation of the argument t/postusername leads to sql injection. Upgrading to version 1.3.0 is able to address this issue. The patch is identified as f11a136e9cbd24997354965178728dc22a2aa2ed. It is recommended to upgrade the affected component. VDB-220206 is the identifier assigned to this vulnerability.
Severity: nan (CVSS v3 base score: 9.8)
Weakness: CWE-89 \u2014 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
Repository: https://github.com/gimmie/vbulletin-v4
Files changed:
Upload/plugins/gimmie/trigger_ratethread.php
Commit message: Update trigger_ratethread.php to prevent SQL Injection

Vulnerable code:
    $threadsql  = $vbulletin->db->query_read("SELECT * FROM " . TABLE_PREFIX . "thread WHERE `threadid` = '" . $_POST['t'] . "'");
    $usersql  = $vbulletin->db->query_read("SELECT `userid`, `username`, `email` FROM " . TABLE_PREFIX . "user WHERE `username` = '" . $thread['postusername'] . "'");
?>

Fixed code:
    $threadsql  = $vbulletin->db->query_read("SELECT * FROM " . TABLE_PREFIX . "thread WHERE `threadid` = " . $vbulletin->db->escape_string($_POST['t']));
    $usersql  = $vbulletin->db->query_read("SELECT `userid`, `username`, `email` FROM " . TABLE_PREFIX . "user WHERE `username` = " . $vbulletin->db->escape_string($thread['postusername']));
?>
CVE-2014-125086 (PHP, published 2023-02-06T04:15Z)
Description: value: A vulnerability has been found in Gimmie Plugin 1.2.2 on vBulletin and classified as critical. Affected by this vulnerability is an unknown functionality of the file trigger_login.php. The manipulation of the argument userid leads to sql injection. Upgrading to version 1.3.0 is able to address this issue. The patch is named fe851002d20a8d6196a5abb68bafec4102964d5b. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-220207.
Severity: nan (CVSS v3 base score: 9.8)
Weakness: CWE-89 \u2014 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
Repository: https://github.com/gimmie/vbulletin-v4
Files changed:
Upload/plugins/gimmie/trigger_login.php
Commit message: Update trigger_login.php to prevent SQL injection

Vulnerable code:
$usersql  = $vbulletin->db->query_read("SELECT `userid`, `username`, `email` FROM " . TABLE_PREFIX . "user WHERE `userid` = '" . $vbulletin->userinfo['userid'] . "'");
?>

Fixed code:
$usersql  = $vbulletin->db->query_read("SELECT `userid`, `username`, `email` FROM " . TABLE_PREFIX . "user WHERE `userid` = " . $vbulletin->db->escape_string($vbulletin->userinfo['userid']));
?>
CVE-2024-28243 (JavaScript, published 2024-03-25T20:15Z)
Description: value: KaTeX is a JavaScript library for TeX math rendering on the web. KaTeX users who render untrusted mathematical expressions could encounter malicious input using `\edef` that causes a near-infinite loop, despite setting `maxExpand` to avoid such loops. This can be used as an availability attack, where e.g. a client rendering another user's KaTeX input will be unable to use the site due to memory overflow, tying up the main thread, or stack overflow. Upgrade to KaTeX v0.16.10 to remove this vulnerability.
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/KaTeX/KaTeX
Files changed:
docs/options.md
src/MacroExpander.js
test/katex-spec.js
Commit message: fix: \edef bypassing maxExpand via exponential blowup

Modify `\edef`, and `expandTokens` more generally, to count the number
of tokens in the entire expansion instead of just 1.  This prevents
exponential blowup in the expanded tokens via a linear number of `\edef`
and apparent expansions.


Vulnerable code:
- `maxExpand`: `number`. Limit the number of macro expansions to the specified number, to prevent e.g. infinite macro loops. If set to `Infinity`, the macro expander will try to fully expand as in LaTeX. (default: 1000)
        this.expansionCount++;
        if (this.expansionCount > this.settings.maxExpand) {
            throw new ParseError("Too many expansions: infinite loop or " +
                "need to increase maxExpand setting");
        }

Fixed code:
- `maxExpand`: `number`. Limit the number of macro expansions to the specified number, to prevent e.g. infinite macro loops. `\edef` expansion counts all expanded tokens. If set to `Infinity`, the macro expander will try to fully expand as in LaTeX. (default: 1000)
    /**
     * Increment `expansionCount` by the specified amount.
     * Throw an error if it exceeds `maxExpand`.
     */
    countExpansion(amount: number): void {
        this.expansionCount += amount;
        if (this.expansionCount > this.settings.maxExpand) {
            throw new ParseError("Too many expansions: infinite loop or " +
                "need to increase maxExpand setting");
        }
    }

        this.countExpansion(1);
        // Count all of these tokens as additional expansions, to prevent
        // exponential blowup from linearly many \edef's.
        this.countExpansion(output.length);

    it("should prevent exponential blowup via \\edef", () => {
        expect`\edef0{x}\edef0{00}\edef0{00}\edef0{00}\edef0{00}`.not.toParse(
            new Settings({maxExpand: 10}));
    });
CVE-2024-28244 (JavaScript, published 2024-03-25T20:15Z)
Description: value: KaTeX is a JavaScript library for TeX math rendering on the web. KaTeX users who render untrusted mathematical expressions could encounter malicious input using `\def` or `\newcommand` that causes a near-infinite loop, despite setting `maxExpand` to avoid such loops. KaTeX supports an option named maxExpand which aims to prevent infinitely recursive macros from consuming all available memory and/or triggering a stack overflow error. Unfortunately, support for "Unicode (sub|super)script characters" allows an attacker to bypass this limit. Each sub/superscript group instantiated a separate Parser with its own limit on macro executions, without inheriting the current count of macro executions from its parent. This has been corrected in KaTeX v0.16.10.
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/KaTeX/KaTeX
Files changed:
src/Parser.js
test/katex-spec.js
Commit message: fix: maxExpand limit with Unicode sub/superscripts

* Prevent recursive parser calls from over-expansion

* Use this.subparse instead of a recursive parser.

* Add maxExpand tests

* Lint fix

---------

Co-authored-by: Ron Kok <ronkok55@outlook.com>


Vulnerable code:
                let str = uSubsAndSups[lex.text];
                    str += uSubsAndSups[token];
                const body = (new Parser(str, this.settings)).parse();

Fixed code:
                const subsupTokens = [];
                subsupTokens.push(new Token(uSubsAndSups[lex.text]));
                    subsupTokens.unshift(new Token(uSubsAndSups[token]));
                const body = this.subparse(subsupTokens);

    const exp32 = r`
        \def\a#1{\b{#1}\b{#1}}
        \def\b#1{\c{#1}\c{#1}}
        \def\c#1{\d{#1}\d{#1}}
        \def\d#1{\e{#1}\e{#1}}
        \def\e#1{\f{#1}\f{#1}}
        \def\f#1{#1}
    `;

    it("should count correctly", () => {
        const example = exp32 + r`\a{1}`;
        const count = 1 + 2 + 4 + 8 + 16 + 32;
        expect(example).toParse(new Settings({maxExpand: count}));
        expect(example).not.toParse(new Settings({maxExpand: count - 1}));
    });

    it("should count correctly with Unicode sub/superscripts", () => {
        const example = exp32 + r`\def+{\a{1}}x⁺x⁺x⁺x⁺`;
        const count = (1 + 2 + 4 + 8 + 16 + 32) * 4 + 4;
        expect(example).toParse(new Settings({maxExpand: count}));
        expect(example).not.toParse(new Settings({maxExpand: count - 1}));
    });