hitoshura25/cvefixes huggingface dataset:
CVE-2018-25075 (Java, published 2023-01-15T20:15Z)
Description: value: A vulnerability classified as critical has been found in karsany OBridge up to 1.3. Affected is the function getAllStandaloneProcedureAndFunction of the file obridge-main/src/main/java/org/obridge/dao/ProcedureDao.java. The manipulation leads to sql injection. The complexity of an attack is rather high. The exploitability is told to be difficult. Upgrading to version 1.4 is able to address this issue. The name of the patch is 52eca4ad05f3c292aed3178b2f58977686ffa376. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-218376.
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/karsany/obridge
Files changed:
obridge-main/src/main/java/org/obridge/dao/ProcedureDao.java
Commit message: sql injection fix.


Vulnerable code:
        String query = "select object_name from user_objects where object_type = 'PACKAGE' and object_name like '" + c.getPackagesLike() + "'";
        });

Fixed code:
        String query = "select object_name from user_objects where object_type = 'PACKAGE' and object_name like ?";
        }, c.getPackagesLike());
CVE-2020-15153 (PHP, published 2021-04-30T16:15Z)
Description: value: Ampache before version 4.2.2 allows unauthenticated users to perform SQL injection. Refer to the referenced GitHub Security Advisory for details and a workaround. This is fixed in version 4.2.2 and the development branch.
Severity: HIGH (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/ampache/ampache
Files changed:
lib/class/database_object.abstract.php
Commit message: Update database_object.abstract.php

cast int for object_id


Vulnerable code:
        $table_name = $table_name ? Dba::escape($table_name) : Dba::escape(strtolower(get_class($this)));
        if (self::is_cached($table_name, $object_id)) {
            return self::get_from_cache($table_name, $object_id);
        $sql        = "SELECT * FROM `$table_name` WHERE `id`='$object_id'";
        $db_results = Dba::read($sql);
        self::add_to_cache($table_name, $object_id, $row);

Fixed code:
        $table     = $table_name ? Dba::escape($table_name) : Dba::escape(strtolower(get_class($this)));
        $object_id = (int) $object_id;
        if (self::is_cached($table, $object_id)) {
            return self::get_from_cache($table, $object_id);
        $params     = array($object_id);
        $sql        = "SELECT * FROM `$table` WHERE `id`= ?";
        $db_results = Dba::read($sql, $params);
        self::add_to_cache($table, $object_id, $row);
CVE-2023-42821 (Go, published 2023-09-22T17:15Z)
Description: value: The package `github.com/gomarkdown/markdown` is a Go library for parsing Markdown text and rendering as HTML. Prior to pseudoversion `0.0.0-20230922105210-14b16010c2ee`, which corresponds with commit `14b16010c2ee7ff33a940a541d993bd043a88940`, parsing malformed markdown input with parser that uses parser.Mmark extension could result in out-of-bounds read vulnerability. To exploit the vulnerability, parser needs to have `parser.Mmark` extension set. The panic occurs inside the `citation.go` file on the line 69 when the parser tries to access the element past its length. This can result in a denial of service. Commit `14b16010c2ee7ff33a940a541d993bd043a88940`/pseudoversion `0.0.0-20230922105210-14b16010c2ee` contains a patch for this issue.
Severity: nan (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/gomarkdown/markdown
Files changed:
parser/block.go
parser/citation.go
Commit message: fix out-of-bounds read


Vulnerable code:
	if data[0] != '#' {

Fixed code:

		if len(data) == 0 {
			continue
		}

	if len(data) > 0 && data[0] != '#' {

		if len(citation) < 2 {
			continue
		}
CVE-2022-41938 (PHP, published 2022-11-19T01:15Z)
Description: value: Flarum is an open source discussion platform. Flarum's page title system allowed for page titles to be converted into HTML DOM nodes when pages were rendered. The change was made after `v1.5` and was not noticed. This allowed an attacker to inject malicious HTML markup using a discussion title input, either by creating a new discussion or renaming one. The XSS attack occurs after a visitor opens the relevant discussion page. All communities running Flarum from `v1.5.0` to `v1.6.1` are impacted. The vulnerability has been fixed and published as flarum/core `v1.6.2`. All communities running Flarum from `v1.5.0` to `v1.6.1` have to upgrade as soon as possible to v1.6.2. There are no known workarounds for this issue.
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/flarum/framework
Files changed:
framework/core/js/src/common/Application.tsx
framework/core/views/frontend/app.blade.php
Commit message: fix: evaluated page title content (#3684)

* fix: evaluated page title content
* chore: add comment
* chore: use DOMParser instead
* fix: use `innerHTML` for the actual value

Signed-off-by: Sami Mazouz <sychocouldy@gmail.com>
Co-authored-by: David Wheatley <hi@davwheat.dev>

Vulnerable code:
    const title =
    const tempEl = document.createElement('div');
    tempEl.innerHTML = title;
    const decodedTitle = tempEl.innerText;
    document.title = count + decodedTitle;
        <title>{!! $title !!}</title>

Fixed code:
    let title =
    title = count + title;
    // We pass the title through a DOMParser to allow HTML entities
    // to be rendered correctly, while still preventing XSS attacks
    // from user input by using a script-disabled environment.
    // https://github.com/flarum/framework/issues/3514
    // https://github.com/flarum/framework/pull/3684
    const parser = new DOMParser();
    const safeTitle = parser.parseFromString(title, 'text/html').body.innerHTML;

    document.title = safeTitle;
        <title>{{ $title }}</title>
CVE-2023-27577 (PHP, published 2023-03-10T21:15Z)
Description: value: flarum is a forum software package for building communities. In versions prior to 1.7.0 an admin account which has already been compromised by an attacker may use a vulnerability in the `LESS` parser which can be exploited to read sensitive files on the server through the use of path traversal techniques. An attacker can achieve this by providing an absolute path to a sensitive file in the custom `LESS` setting, which the `LESS` parser will then read. For example, an attacker could use the following code to read the contents of the `/etc/passwd` file on a linux machine. The scope of what files are vulnerable will depend on the permissions given to the running flarum process. The vulnerability has been addressed in version `1.7`. Users should upgrade to this version to mitigate the vulnerability. Users unable to upgrade may mitigate the vulnerability by ensuring that their admin accounts are secured with strong passwords and follow other best practices for account security. Additionally, users can limit the exposure of sensitive files on the server by implementing appropriate file permissions and access controls at the operating system level.

Severity: nan (CVSS v3 base score: 4.9)
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/flarum/framework
Files changed:
framework/core/locale/core.yml
framework/core/src/Forum/ValidateCustomLess.php
Commit message: fix: disallow certain dangerous LESS features

Signed-off-by: Sami Mazouz <sychocouldy@gmail.com>


Vulnerable code:

Fixed code:
      custom_styles_cannot_use_less_features: "The @import and data-uri features are not allowed in custom LESS."
use Symfony\Contracts\Translation\TranslatorInterface;
        // Restrict what features can be used in custom LESS
        if (preg_match('/@import|data-uri\s*\(/i', $event->settings['custom_less'])) {
            $translator = $this->container->make(TranslatorInterface::class);

            throw new ValidationException([
                'custom_less' => $translator->trans('core.admin.appearance.custom_styles_cannot_use_less_features')
            ]);
        }
CVE-2023-40033 (PHP, published 2023-08-16T21:15Z)
Description: value: Flarum is an open source forum software. Flarum is affected by a vulnerability that allows an attacker to conduct a Blind Server-Side Request Forgery (SSRF) attack or disclose any file on the server, even with a basic user account on any Flarum forum. By uploading a file containing a URL and spoofing the MIME type, an attacker can manipulate the application to execute unintended actions. The vulnerability is due to the behavior of the `intervention/image` package, which attempts to interpret the supplied file contents as a URL, which then fetches its contents. This allows an attacker to exploit the vulnerability to perform SSRF attacks, disclose local file contents, or conduct a blind oracle attack. This has been patched in Flarum version 1.8.0. Users are advised to upgrade. Users unable to upgrade may disable PHP's `allow_url_fopen` which will prevent the fetching of external files via URLs as a temporary workaround for the SSRF aspect of the vulnerability.
Severity: nan (CVSS v3 base score: 7.1)
Weakness: CWE-918 \u2014 Server-Side Request Forgery (SSRF)
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
Repository: https://github.com/flarum/framework
Files changed:
framework/core/js/src/forum/components/AvatarEditor.js
framework/core/src/Api/Controller/UploadFaviconController.php
framework/core/src/Api/Controller/UploadLogoController.php
framework/core/src/User/AvatarValidator.php
framework/core/src/User/Command/UploadAvatarHandler.php
Commit message: fix: improve avatar upload functionality

Signed-off-by: Sami Mazouz <sychocouldy@gmail.com>


Vulnerable code:
   * store, and force a recomputation of the user's avatar color.
        $encodedImage = $this->imageManager->make($file->getStream())->resize(64, 64, function ($constraint) {
        $encodedImage = $this->imageManager->make($file->getStream())->heighten(60, function ($constraint) {
            $this->imageManager->make($file->getStream());
        $image = $this->imageManager->make($command->file->getStream());

Fixed code:
   * store, and force a re-computation of the user's avatar color.
        $encodedImage = $this->imageManager->make($file->getStream()->getMetadata('uri'))->resize(64, 64, function ($constraint) {
        $encodedImage = $this->imageManager->make($file->getStream()->getMetadata('uri'))->heighten(60, function ($constraint) {
            $this->imageManager->make($file->getStream()->getMetadata('uri'));
        $image = $this->imageManager->make($command->file->getStream()->getMetadata('uri'));
CVE-2016-10554 (JavaScript, published 2018-05-31T20:29Z)
Description: value: sequelize is an Object-relational mapping, or a middleman to convert things from Postgres, MySQL, MariaDB, SQLite and Microsoft SQL Server into usable data for NodeJS. Before version 1.7.0-alpha3, sequelize defaulted SQLite to use MySQL backslash escaping, even though SQLite uses Postgres escaping.
Severity: HIGH (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/sequelize/sequelize
Files changed:
lib/sql-string.js
Commit message: Fix string escaping for sqlite

SQLite was defaulting to the MySQL backslash-escaped style, but it uses
postgres-style escaping. This is a SQL-injection vulnerability, and
shouldn't be taken lightly (although SQLite is mostly for testing).


Vulnerable code:
  if (dialect == "postgres") {

Fixed code:
  if (dialect === "postgres" || dialect === "sqlite") {
    // http://stackoverflow.com/q/603572/130598
CVE-2019-11069 (JavaScript, published 2019-04-10T21:29Z)
Description: value: Sequelize version 5 before 5.3.0 does not properly ensure that standard conforming strings are used.
Severity: MEDIUM (CVSS v3 base score: 7.5)
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/sequelize/sequelize
Files changed:
lib/dialects/abstract/connection-manager.js
lib/dialects/postgres/connection-manager.js
Commit message: feat(postgres): enable standard conforming strings when required (#10746)



Vulnerable code:
                this.sequelize.options.databaseVersion = semver.valid(version) ? version : this.defaultVersion;
      if (
        this.sequelize.options.databaseVersion !== 0
        && semver.gte(this.sequelize.options.databaseVersion, '8.2.0')
        && semver.lt(this.sequelize.options.databaseVersion, '9.1.0')
      ) {

Fixed code:
                const parsedVersion = _.get(semver.coerce(version), 'version') || version;
                this.sequelize.options.databaseVersion = semver.valid(parsedVersion)
                  ? parsedVersion
                  : this.defaultVersion;

      const parameterHandler = message => {
        switch (message.parameterName) {
          case 'server_version':
            if (this.sequelize.options.databaseVersion === 0) {
              const version = semver.coerce(message.parameterValue).version;
              this.sequelize.options.databaseVersion = semver.valid(version)
                ? version
                : this.defaultVersion;
            }
            break;
          case 'standard_conforming_strings':
            connection['standard_conforming_strings'] = message.parameterValue;
            break;
        }
      };

      if (!this.sequelize.config.native) {
        // Receive various server parameters for further configuration
        connection.connection.on('parameterStatus', parameterHandler);
      }


        if (!this.sequelize.config.native) {
          // remove parameter handler
          connection.connection.removeListener('parameterStatus', parameterHandler);
        }

      if (connection['standard_conforming_strings'] !== 'on') {
CVE-2013-7299 (C++, published 2014-01-26T20:55Z)
Description: value: framework/common/messageheaderparser.cpp in Tntnet before 2.2.1 allows remote attackers to obtain sensitive information via a header that ends in \n instead of \r\n, which prevents a null terminator from being added and causes Tntnet to include headers from other requests.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-200 \u2014 Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Repository: https://github.com/maekitalo/tntnet
Files changed:
framework/common/messageheaderparser.cpp
Commit message: fix possible information leak


Vulnerable code:

Fixed code:
      *headerdataPtr = '\0';
    {
      header.rawdata[sizeof(header.rawdata) - 1] = '\0';
    }
CVE-2022-4399 (C, published 2022-12-10T22:15Z)
Description: value: A vulnerability was found in TicklishHoneyBee nodau. It has been rated as critical. Affected by this issue is some unknown functionality of the file src/db.c. The manipulation of the argument value/name leads to sql injection. The name of the patch is 7a7d737a3929f335b9717ddbd31db91151b69ad2. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-215252.
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/TicklishHoneyBee/nodau
Files changed:
CHANGELOG
src/db.c
src/edit.c
Commit message: Use parametetrized SQL statement

Move to parametetrized SQL statement allows using chars like "'" in
notes and also avoid sql injection


Vulnerable code:
		r = asprintf(&sql, "UPDATE nodau set text='%s' , encrypted='true' WHERE name='%s'", value, name);
		free(value);
		if (r < 0)
		if (asprintf(&sql, "UPDATE nodau set text='%s' , encrypted='false' WHERE name='%s'", value, name) < 0)
	r = sqlite3_exec(db_data.db, sql, NULL, 0, &db_data.error_msg);
					if (db_update(name,l))

Fixed code:
0.3.10
    - Move to parametetrized SQL statement allows using chars like "'"
     in notes, and also avoid sql injection
		if (asprintf(&sql, "UPDATE nodau set text=?, encrypted='true' WHERE name=?") < 0)
		if (asprintf(&sql, "UPDATE nodau set text=?, encrypted='false' WHERE name=?") < 0)
	sqlite3_stmt *compiled_statement;
	r = sqlite3_prepare_v2(db_data.db, sql, -1, &compiled_statement, NULL);
	if (r != SQLITE_OK)
		return 1;

	r= sqlite3_bind_text(compiled_statement, 1, value, -1, NULL);
	r= sqlite3_bind_text(compiled_statement, 2, name, -1, NULL);
	if (r != SQLITE_OK)
		return 1;

	r = sqlite3_step(compiled_statement);
	if (r != SQLITE_DONE) {
		fprintf(stderr, "Error #%d: %s\n", r, db_err());
		return 1;
	}
	r = sqlite3_finalize(compiled_statement);
	if (r != SQLITE_OK)
		fprintf(stderr, "Error #%d: %s\n", r, db_err());

	if (crypt_key)
		free(value);
					int r = db_update(name,l);
					if (r != SQLITE_DONE && r != SQLITE_OK)
CVE-2024-22196 (Go, published 2024-01-11T20:15Z)
Description: value: Nginx-UI is an online statistics for Server Indicators?? Monitor CPU usage, memory usage, load average, and disk usage in real-time. This issue may lead to information disclosure. By using `DefaultQuery`, the `"desc"` and `"id"` values are used as default values if the query parameters are not set. Thus, the `order` and `sort_by` query parameter are user-controlled and are being appended to the `order` variable without any sanitization. This issue has been patched in version 2.0.0.beta.9.


Severity: nan (CVSS v3 base score: 6.5)
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/0xJacky/nginx-ui
Files changed:
api/cosy/sort.go
model/model.go
Commit message: fix: ensure the list sort query is validated to prevent SQL injection

Credits to @jorgectf for the advisories.


Vulnerable code:
		order := fmt.Sprintf("%s %s", DefaultQuery(c.ctx, "sort_by", c.itemKey), sort)
		return db.Order(order)
		sort := c.ctx.DefaultQuery("order", "desc")

		order := fmt.Sprintf("%s %s", DefaultQuery(c.ctx, "sort_by", c.itemKey), sort)
		db = db.Order(order)


		order := fmt.Sprintf("`%s` %s", DefaultQuery(c, "sort_by", "id"), sort)
		db = db.Order(order)

Fixed code:
	"github.com/0xJacky/Nginx-UI/internal/logger"
	"gorm.io/gorm/schema"
	"sync"
		if sort != "desc" && sort != "asc" {
			sort = "desc"
		}

		// check if the order field is valid
		// todo: maybe we can use more generic way to check if the sort_by is valid
		order := DefaultQuery(c.ctx, "sort_by", c.itemKey)
		s, _ := schema.Parse(c.Model, &sync.Map{}, schema.NamingStrategy{})
		if _, ok := s.FieldsByDBName[order]; ok {
			order = fmt.Sprintf("%s %s", order, sort)
			return db.Order(order)
		} else {
			logger.Error("invalid order field:", order)
		}

		return db
		db = c.SortOrder()(db)
	"gorm.io/gorm/schema"
	"sync"
		if sort != "desc" && sort != "asc" {
			sort = "desc"
		}
		// check if the order field is valid
		order := c.DefaultQuery("sort_by", "id")
		s, _ := schema.Parse(db.Model, &sync.Map{}, schema.NamingStrategy{})
		if _, ok := s.FieldsByName[order]; ok {
			order = fmt.Sprintf("%s %s", order, sort)
			db = db.Order(order)
		} else {
			logger.Error("invalid order field: ", order)
		}