hitoshura25/cvefixes huggingface dataset:
CVE-2022-4869 (Python, published 2023-01-05T09:15Z)
Description: value: A vulnerability was found in Evolution Events Artaxerxes. It has been declared as problematic. This vulnerability affects unknown code of the file arta/common/middleware.py of the component POST Parameter Handler. The manipulation of the argument password leads to information disclosure. The attack can be initiated remotely. The patch is identified as 022111407d34815c16c6eada2de69ca34084dc0d. It is recommended to apply a patch to fix this issue. VDB-217438 is the identifier assigned to this vulnerability.
Severity: nan (CVSS v3 base score: 7.5)
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/evolution-events/Artaxerxes
Files changed:
arta/common/middleware.py
arta/settings/production.py
Commit message: HideSensitiveMiddleware: Hide passwords on middleware errors

It turns out that an exception in middleware (such as a CSRF failure)
can bypass the hiding of sensitive post parameters (e.g. passwords in
the login form).

This adds a middleware that ensures that (unless the view specifies
differently), the 'password' parameter is always hidden from error
output (and for views that *do* specify differently, it is hidden also
before the view is executed).

Part of this (view middleware) could be fixed in Django
https://code.djangoproject.com/ticket/33090, but this new middleware
adds a bit more protection for exceptions before the view is even known.


Vulnerable code:

Fixed code:
from django.utils.deprecation import MiddlewareMixin


class HideSensitiveMiddleware(MiddlewareMixin):
    """
    Hide sensitive post variables.

    Django has a mechanism to hide these on a per-view basis, but this makes sure that the variables listed here are
    hidden even on errors in middleware (i.e. before the view is ran).

    In part, this is a workaround around https://code.djangoproject.com/ticket/33090, but even with that fixed, this
    middleware adds a bit extra security for exceptions that are triggered before the view is even known.

    Note that this value is overwritten once a view that has its own sensitive_post_variables specified is ran, but
    that should be ok, the view should then know better.
    """

    def __call__(self, request):
        request.sensitive_post_parameters = ['password']
        return super().__call__(request)

# Add extra protection for passwords, partially to work around https://code.djangoproject.com/ticket/33090 but also to
# add even a bit more protection. Must be first to maximise coverage.
MIDDLEWARE.append(0, 'arta.common.middleware.HideSensitiveMiddleware')
CVE-2021-39169 (Other, published 2021-08-27T13:15Z)
Description: value: Misskey is a decentralized microblogging platform. In versions of Misskey prior to 12.51.0, malicious actors can use the web client built-in dialog to display a malicious string, leading to cross-site scripting (XSS). XSS could compromise the API request token. This issue has been fixed in version 12.51.0. There are no known workarounds aside from upgrading.
Severity: LOW (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/misskey-dev/misskey
Files changed:
src/client/components/dialog.vue
Commit message: Use MFM instead of v-html to avoid XSS


Vulnerable code:
		<header v-if="title" v-html="title"></header>
		<div class="body" v-if="text" v-html="text"></div>

Fixed code:
		<header v-if="title"><Mfm :text="title"/></header>
		<div class="body" v-if="text"><Mfm :text="text"/></div>
CVE-2023-24811 (Other, published 2023-02-22T20:15Z)
Description: value: Misskey is an open source, decentralized social media platform. In versions prior to 13.3.2 the URL preview function is subject to a cross site scripting vulnerability due to insufficient URL validation. Arbitrary JavaScript is executed when a malicious URL is loaded in the `View in Player` or `View in Window` preview. This has been fixed in version 13.3.2. Users are advised to upgrade. Users unable to upgrade should avoid usage of the `View in Player` or `View in Window` functions.

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/misskey-dev/misskey
Files changed:
CHANGELOG.md
packages/backend/src/server/web/UrlPreviewService.ts
packages/frontend/src/components/MkUrlPreview.vue
packages/frontend/src/components/MkYoutubePlayer.vue
Commit message: fix(client): validate urls to improve security


Vulnerable code:
	<iframe :class="$style.playerIframe" :src="player.url + (player.url.match(/\?/) ? '&autoplay=1&auto_play=1' : '?autoplay=1&auto_play=1')" :width="player.width || '100%'" :heigth="player.height || 250" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen/>
			<div v-if="player.url" class="player">

Fixed code:
## 13.x.x (unreleased)

### Improvements

### Bugfixes
- Client: validate urls to improve security


			if (summary.url && !(summary.url.startsWith('http://') || summary.url.startsWith('https://'))) {
				throw new Error('unsupported schema included');
			}

			if (summary.player?.url && !(summary.player.url.startsWith('http://') || summary.player.url.startsWith('https://'))) {
				throw new Error('unsupported schema included');
			}
	<iframe v-if="player.url.startsWith('http://') || player.url.startsWith('https://')" :class="$style.playerIframe" :src="player.url + (player.url.match(/\?/) ? '&autoplay=1&auto_play=1' : '?autoplay=1&auto_play=1')" :width="player.width || '100%'" :heigth="player.height || 250" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen/>
	<span v-else>invalid url</span>
			<div v-if="player.url && (player.url.startsWith('http://') || player.url.startsWith('https://'))" class="player">
			<span v-else>invalid url</span>
CVE-2023-24812 (TypeScript, published 2023-02-22T20:15Z)
Description: value: Misskey is an open source, decentralized social media platform. In versions prior to 13.3.3 SQL injection is possible due to insufficient parameter validation in the note search API by tag (notes/search-by-tag). This has been fixed in version 13.3.3. Users are advised to upgrade. Users unable to upgrade should block access to the `api/notes/search-by-tag` endpoint.
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/misskey-dev/misskey
Files changed:
packages/backend/src/server/api/endpoints/notes/search-by-tag.ts
Commit message: fix(server): improve security


Vulnerable code:
					if (!safeForSql(ps.tag)) throw 'Injection';
									if (!safeForSql(tag)) throw 'Injection';

Fixed code:
					if (!safeForSql(normalizeForSearch(ps.tag))) throw 'Injection';
									if (!safeForSql(normalizeForSearch(tag))) throw 'Injection';
CVE-2023-43793 (Markdown, published 2023-10-04T21:15Z)
Description: value: Misskey is an open source, decentralized social media platform. Prior to version 2023.9.0, by editing the URL, a user can bypass the authentication of the Bull dashboard, which is the job queue management UI, and access it. Version 2023.9.0 contains a fix. There are no known workarounds.
Severity: nan (CVSS v3 base score: 7.5)
Weakness: CWE-287 \u2014 Improper Authentication
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
Repository: https://github.com/misskey-dev/misskey
Files changed:
CHANGELOG.md
packages/backend/src/server/web/ClientServerService.ts
Commit message: fix(backend): ジョブキュー管理画面の認証を回避できる問題を修正


Vulnerable code:
			if (request.url === bullBoardPath || request.url.startsWith(bullBoardPath + '/')) {

Fixed code:
- Fix: ジョブキュー管理画面の認証を回避できる問題を修正
			// %71ueueとかでリクエストされたら困るため
			const url = decodeURI(request.url);
			if (url === bullBoardPath || url.startsWith(bullBoardPath + '/')) {
CVE-2022-0645 (Python, published 2022-04-19T12:15Z)
Description: value: Open redirect vulnerability via endpoint authorize_and_redirect/?redirect= in GitHub repository posthog/posthog prior to 1.34.1.
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-601 \u2014 URL Redirection to Untrusted Site ('Open Redirect')
A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.
Repository: https://github.com/posthog/posthog
Files changed:
posthog/api/decide.py
posthog/test/test_urls.py
posthog/urls.py
Commit message: fix(toolbar): only redirect to hosts in app_urls (#9268)

* fix(toolbar): only redirect to hosts in app_urls

* fix mypy and regex

Vulnerable code:
        hostname = parse_domain(url)
        if hostname:
            permitted_domains.append(hostname)
    origin = parse_domain(request.headers.get("Origin"))
    referer = parse_domain(request.headers.get("Referer"))
            pattern = "^{}$".format(permitted_domain.replace(".", "\\.").replace("*", "(.*)"))
            if (origin and re.search(pattern, origin)) or (referer and re.search(pattern, referer)):
                return True
        else:
            if permitted_domain == origin or permitted_domain == referer:
from typing import Any, Callable, List, Optional
from django.http import HttpResponse
def authorize_and_redirect(request):

Fixed code:
    origin = parse_domain(request.headers.get("Origin"))
    referer = parse_domain(request.headers.get("Referer"))
    return hostname_in_app_urls(team, origin) or hostname_in_app_urls(team, referer)


def hostname_in_app_urls(team: Team, hostname: Optional[str]) -> bool:
    if not hostname:
        return False

        host = parse_domain(url)
        if host:
            permitted_domains.append(host)
            pattern = "^{}$".format(re.escape(permitted_domain).replace("\\*", "(.*)"))
            if re.search(pattern, hostname):
        elif permitted_domain == hostname:
            return True

        self.team.app_urls = ["https://domain.com", "https://not.com"]
        self.team.save()

        response = self.client.get(
            "/authorize_and_redirect/?redirect=https://not-permitted.com", HTTP_REFERER="https://not-permitted.com"
        )
        self.assertEqual(response.status_code, status.HTTP_400_BAD_REQUEST)
        self.assertTrue("Can only redirect to a permitted domain." in str(response.content))

from typing import Any, Callable, List, Optional, cast
from django.http import HttpRequest, HttpResponse
from posthog.api.decide import hostname_in_app_urls
from posthog.models import User
def authorize_and_redirect(request: HttpRequest) -> HttpResponse:
    current_team = cast(User, request.user).team
    if not current_team or not hostname_in_app_urls(current_team, redirect_url.hostname):
        return HttpResponse(f"Can only redirect to a permitted domain.", status=400)
CVE-2016-6663 (C, published 2016-12-13T21:59Z)
Description: value: Race condition in Oracle MySQL before 5.5.52, 5.6.x before 5.6.33, 5.7.x before 5.7.15, and 8.x before 8.0.1; MariaDB before 5.5.52, 10.0.x before 10.0.28, and 10.1.x before 10.1.18; Percona Server before 5.5.51-38.2, 5.6.x before 5.6.32-78-1, and 5.7.x before 5.7.14-8; and Percona XtraDB Cluster before 5.5.41-37.0, 5.6.x before 5.6.32-25.17, and 5.7.x before 5.7.14-26.17 allows local users with certain permissions to gain privileges by leveraging use of my_copystat by REPAIR TABLE to repair a MyISAM table.
Severity: MEDIUM (CVSS v3 base score: 7)
Weakness: CWE-362 \u2014 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
Repository: https://github.com/MariaDB/server
Files changed:
include/my_sys.h
mysys/my_redel.c
mysys/my_static.c
sql/mysqld.cc
Commit message: don't use my_copystat in the server

it was supposed to be used in command-line tools only.
Different fix for 4e5473862e:

Bug#24388746: PRIVILEGE ESCALATION AND RACE CONDITION USING CREATE TABLE


Vulnerable code:
   Copyright (c) 2010, 2013, Monty Program Ab.
extern my_bool my_disable_sync;
/*
   Copyright (c) 2000, 2010, Oracle and/or its affiliates
  if (my_copystat(org_name,tmp_name,MyFlags) < 0)

Fixed code:
   Copyright (c) 2010, 2016, Monty Program Ab.
extern my_bool my_disable_sync, my_disable_copystat_in_redel;
/* Copyright (c) 2000, 2010, Oracle and/or its affiliates
   Copyright (c) 2009, 2016, MariaDB
  if (!my_disable_copystat_in_redel &&
      my_copystat(org_name,tmp_name,MyFlags) < 0)
my_bool my_disable_copystat_in_redel=0;
  my_disable_copystat_in_redel= 1;
CVE-2017-15365 (C++, published 2018-01-25T16:29Z)
Description: value: sql/event_data_objects.cc in MariaDB before 10.1.30 and 10.2.x before 10.2.10 and Percona XtraDB Cluster before 5.6.37-26.21-3 and 5.7.x before 5.7.19-29.22-3 allows remote authenticated users with SQL access to bypass intended access restrictions and replicate data definition language (DDL) statements to cluster nodes by leveraging incorrect ordering of DDL replication and ACL checking.
Severity: MEDIUM (CVSS v3 base score: 8.8)
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/MariaDB/server
Files changed:
sql/event_data_objects.cc
Commit message: MW-416 DDL replication moved after acl checking

galera_events test shows a regression with the original fix for MW-416
Reason was that Events::drop_event() can be called also from inside event
execution, and there we have a speacial treatment for event, which executes
"DROP EVENT" statement, and runs TOI replication inside the event processing body.
This resulted in executing WSREP_TO_ISOLATION two times for such DROP EVENT statement.
Fix is to call WSREP_TO_ISOLATION_BEGIN only in Events::drop_event()


Vulnerable code:
      if (WSREP(thd))
      {
        WSREP_TO_ISOLATION_BEGIN(WSREP_MYSQL_DB, NULL, NULL);
      }
      WSREP_TO_ISOLATION_END;
#ifdef WITH_WSREP
  error:
#endif

Fixed code:
      /*
         This code is processing event execution and does not have client
         connection. Here, event execution will now execute a prepared
         DROP EVENT statement, but thd->lex->sql_command is set to
         SQLCOM_CREATE_PROCEDURE
         DROP EVENT will be logged in binlog, and we have to
         replicate it to make all nodes have consistent event definitions
         Wsrep DDL replication is triggered inside Events::drop_event(),
         and here we need to prepare the THD so that DDL replication is
         possible, essentially it requires setting sql_command to
         SQLCOMM_DROP_EVENT, we will switch sql_command for the duration
         of DDL replication only.
      */
      const enum_sql_command sql_command_save= thd->lex->sql_command;
      const bool sql_command_set= WSREP(thd);

      if (sql_command_set)
      if (sql_command_set)
      {
        WSREP_TO_ISOLATION_END;
        thd->lex->sql_command = sql_command_save;
      }
CVE-2020-7221 (Shell, published 2020-02-04T17:15Z)
Description: value: mysql_install_db in MariaDB 10.4.7 through 10.4.11 allows privilege escalation from the mysql user account to root because chown and chmod are performed unsafely, as demonstrated by a symlink attack on a chmod 04755 of auth_pam_tool_dir/auth_pam_tool. NOTE: this does not affect the Oracle MySQL product, which implements mysql_install_db differently.
Severity: HIGH (CVSS v3 base score: 7.8)
Weakness: CWE-59 \u2014 Improper Link Resolution Before File Access ('Link Following')
The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.
Repository: https://github.com/MariaDB/server
Files changed:
debian/mariadb-server-10.4.postinst
debian/rules
scripts/mysql_install_db.sh
support-files/rpm/server-postin.sh
Commit message: rpm/deb and auth_pam_tool_dir/auth_pam_tool

don't let mysql_install_db set SUID bit for auth_pam_tool in rpm/deb
packages - instead package files with correct permissions and
only fix the ownership of auth_pam_tool_dir (which can only be done
after mysql user is created, so in post-install).

keep old mysql_install_db behavior for bintars


Vulnerable code:
if test -n "$user"
  chown $user "$pamtooldir/auth_pam_tool_dir" && \
  chmod 0700 "$pamtooldir/auth_pam_tool_dir"
  if test $? -ne 0
  then
      echo "Cannot change ownership of the '$pamtooldir/auth_pam_tool_dir' directory"
      echo " to the '$user' user. Check that you have the necessary permissions and try again."
      exit 1
  fi
# Set correct filesystem ownership/permissions for the PAM v2 plugin
chown %{mysqld_group} /usr/lib*/mysql/plugin/auth_pam_tool_dir
chmod 0700            /usr/lib*/mysql/plugin/auth_pam_tool_dir
chown 0               /usr/lib*/mysql/plugin/auth_pam_tool_dir/auth_pam_tool
chmod 04755           /usr/lib*/mysql/plugin/auth_pam_tool_dir/auth_pam_tool

Fixed code:
    # Set the correct filesystem ownership for the PAM v2 plugin
    chown mysql /usr/lib/mysql/plugin/auth_pam_tool_dir

override_dh_fixperms:
	dh_fixperms
	chmod 04755 debian/mariadb-server-10.4/usr/lib/mysql/plugin/auth_pam_tool_dir/auth_pam_tool
	chmod  0700 debian/mariadb-server-10.4/usr/lib/mysql/plugin/auth_pam_tool_dir
if test -n "$user" -a "$in_rpm" -eq 0
  chown $user "$pamtooldir/auth_pam_tool_dir" && \
  chmod 0700 "$pamtooldir/auth_pam_tool_dir"
  if test $? -ne 0
  then
      echo "Cannot change ownership of the '$pamtooldir/auth_pam_tool_dir' directory"
      echo " to the '$user' user. Check that you have the necessary permissions and try again."
      exit 1
  fi
# Set the correct filesystem ownership for the PAM v2 plugin
chown %{mysqld_user} /usr/lib*/mysql/plugin/auth_pam_tool_dir
CVE-2022-31621 (C++, published 2022-05-25T21:15Z)
Description: value: MariaDB Server before 10.7 is vulnerable to Denial of Service. In extra/mariabackup/ds_xbstream.cc, when an error occurs (stream_ctxt->dest_file == NULL) while executing the method xbstream_open, the held lock is not released correctly, which allows local users to trigger a denial of service due to the deadlock. Note: The vendor argues this is just an improper locking bug and not a vulnerability with adverse effects.
Severity: LOW (CVSS v3 base score: 5.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/MariaDB/server
Files changed:
extra/mariabackup/ds_xbstream.cc
Commit message: MDEV-26574 An improper locking bug due to unreleased lock in the ds_xbstream.cc

release lock in all as cases n xbstream_open, also fix the case where malloc would return NULL.


Vulnerable code:
		if (stream_ctxt->dest_file == NULL) {
			return NULL;
		}

Fixed code:
	if (stream_ctxt->dest_file == NULL) {
		return NULL;
	}
	if (!file) {
		msg("my_malloc() failed.");
		goto err;
	}
CVE-2022-31622 (C++, published 2022-05-25T21:15Z)
Description: value: MariaDB Server before 10.7 is vulnerable to Denial of Service. In extra/mariabackup/ds_compress.cc, when an error occurs (pthread_create returns a nonzero value) while executing the method create_worker_threads, the held lock is not released correctly, which allows local users to trigger a denial of service due to the deadlock. Note: The vendor argues this is just an improper locking bug and not a vulnerability with adverse effects.
Severity: LOW (CVSS v3 base score: 5.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/MariaDB/server
Files changed:
extra/mariabackup/ds_compress.cc
Commit message: MDEV-26561 Fix a bug due to unreleased lock

Fix a bug of unreleased lock ctrl_mutex in the method create_worker_threads


Vulnerable code:

Fixed code:
			pthread_mutex_unlock(&thd->ctrl_mutex);
CVE-2022-31623 (C++, published 2022-05-25T21:15Z)
Description: value: MariaDB Server before 10.7 is vulnerable to Denial of Service. In extra/mariabackup/ds_compress.cc, when an error occurs (i.e., going to the err label) while executing the method create_worker_threads, the held lock thd->ctrl_mutex is not released correctly, which allows local users to trigger a denial of service due to the deadlock. Note: The vendor argues this is just an improper locking bug and not a vulnerability with adverse effects.
Severity: LOW (CVSS v3 base score: 5.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/MariaDB/server
Files changed:
extra/mariabackup/ds_compress.cc
Commit message: MDEV-26561 mariabackup release locks

The previous threads locked need to be released too.

This occurs if the initialization of any of the non-first
mutex/conditition variables errors occurs.


Vulnerable code:

Fixed code:
	while (i > 0) {
		comp_thread_ctxt_t *thd;
		i--;
		thd = threads + i;
		pthread_mutex_unlock(&thd->ctrl_mutex);
	}
CVE-2021-42362 (PHP, published 2021-11-17T18:15Z)
Description: value: The WordPress Popular Posts WordPress plugin is vulnerable to arbitrary file uploads due to insufficient input file type validation found in the ~/src/Image.php file which makes it possible for attackers with contributor level access and above to upload malicious files that can be used to obtain remote code execution, in versions up to and including 5.3.2.


Severity: MEDIUM (CVSS v3 base score: 8.8)
Weakness: CWE-434 \u2014 Unrestricted Upload of File with Dangerous Type
The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.
Repository: https://github.com/cabrerahector/wordpress-popular-posts
Files changed:
src/Image.php
Commit message: Image: verifies that URLs are images


Vulnerable code:

Fixed code:
        if ( ! $this->is_image_url($url) )
            return false;

        // Check extension
        $file_name = basename($path);
        $file_name = sanitize_file_name($file_name);
        $ext = strtolower(pathinfo($file_name, PATHINFO_EXTENSION));
        $allowed_ext = ['jpg', 'jpeg', 'png', 'gif'];

        if ( ! in_array($ext, $allowed_ext) )
            return false;