hitoshura25/cvefixes huggingface dataset:
CVE-2023-52076 (C, published 2024-01-25T16:15Z)
Description: value: Atril Document Viewer is the default document reader of the MATE desktop environment for Linux. A path traversal and arbitrary file write vulnerability exists in versions of Atril prior to 1.26.2. This vulnerability is capable of writing arbitrary files anywhere on the filesystem to which the user opening a crafted document has access. The only limitation is that this vulnerability cannot be exploited to overwrite existing files, but that doesn't stop an attacker from achieving Remote Command Execution on the target system. Version 1.26.2 of Atril contains a patch for this vulnerability.
Severity: nan (CVSS v3 base score: 7.8)
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/mate-desktop/atril
Files changed:
backend/epub/epub-document.c
Commit message: epub: Prevent path traversal when extracting files

Test each file's resolved path against the temporary directory
before extracting.


Vulnerable code:
	}
extract_one_file(EpubDocument* epub_document,GError ** error)
    outfile = g_file_new_for_path(gfilepath->str);
    g_object_unref(outfile) ;
    g_object_unref(outstream) ;
        if ( extract_one_file(epub_document,&err) == FALSE )

Fixed code:
        }
extract_one_file(EpubDocument* epub_document, GFile *tmp_gfile, GError ** error)
    outfile = g_file_new_for_path (gfilepath->str);
    g_autofree gchar *rpath = g_file_get_relative_path (tmp_gfile, outfile);

    if (rpath == NULL)
    {
        g_set_error_literal (error,
                             EV_DOCUMENT_ERROR,
                             EV_DOCUMENT_ERROR_INVALID,
                             _("epub file is invalid or corrupt"));
        g_critical ("Invalid filename in Epub container - '%s'", (gchar *) currentfilename);
        result = FALSE;
        goto out;
    }

    g_object_unref(outstream);
    g_object_unref(outfile);
    GFile *tmp_gfile = NULL;
    tmp_gfile = g_file_new_for_path (epub_document->tmp_archive_dir);
        if ( extract_one_file(epub_document, tmp_gfile, &err) == FALSE )
    g_clear_object (&tmp_gfile);
CVE-2020-27638 (C, published 2020-10-22T13:15Z)
Description: value: receive.c in fastd before v21 allows denial of service (assertion failure) when receiving packets with an invalid type code.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-617 \u2014 Reachable Assertion
The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
Repository: https://github.com/NeoRaider/fastd
Files changed:
src/receive.c
Commit message: receive: fix buffer leak when receiving invalid packets

For fastd versions before v20, this was just a memory leak (which could
still be used for DoS, as it's remotely triggerable). With the new
buffer management of fastd v20, this will trigger an assertion failure
instead as soon as the buffer pool is empty.


Vulnerable code:

Fixed code:
		break;

	default:
		fastd_buffer_free(buffer);
		pr_debug("received packet with invalid type from %P[%I]", peer, remote_addr);
		break;

	default:
		fastd_buffer_free(buffer);
		pr_debug("received packet with invalid type from unknown address %I", remote_addr);
CVE-2013-6044 (Python, published 2013-10-04T17:55Z)
Description: value: The is_safe_url function in utils/http.py in Django 1.4.x before 1.4.6, 1.5.x before 1.5.2, and 1.6 before beta 2 treats a URL's scheme as safe even if it is not HTTP or HTTPS, which might introduce cross-site scripting (XSS) or other vulnerabilities into Django applications that use this function, as demonstrated by "the login view in django.contrib.auth.views" and the javascript: scheme.
Severity: MEDIUM (CVSS v3 base score: )
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/django/django
Files changed:
django/contrib/auth/tests/test_views.py
django/utils/http.py
Commit message: Fixed is_safe_url() to reject URLs that use a scheme other than HTTP/S.

This is a security fix; disclosure to follow shortly.


Vulnerable code:
                        '//example.com'):
                        '//example.com'):
    a different host).
    netloc = urllib_parse.urlparse(url)[1]
    return not netloc or netloc == host

Fixed code:
                        '//example.com',
                        'javascript:alert("XSS")'):
                         'HTTPS:///',
                        '//example.com',
                        'javascript:alert("XSS")'):
                         'HTTPS:///',
    a different host and uses a safe scheme).
    url_info = urllib_parse.urlparse(url)
    return (not url_info.netloc or url_info.netloc == host) and \
        (not url_info.scheme or url_info.scheme in ['http', 'https'])
CVE-2015-8213 (Python, published 2015-12-07T20:59Z)
Description: value: The get_format function in utils/formats.py in Django before 1.7.x before 1.7.11, 1.8.x before 1.8.7, and 1.9.x before 1.9rc2 might allow remote attackers to obtain sensitive application secrets via a settings key in place of a date/time format setting, as demonstrated by SECRET_KEY.
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/django/django
Files changed:
django/utils/formats.py
docs/releases/1.7.11.txt
docs/releases/1.8.7.txt
tests/i18n/tests.py
Commit message: Fixed a settings leak possibility in the date template filter.

This is a security fix.


Vulnerable code:
Django 1.7.11 fixes a data loss bug in 1.7.10.
Django 1.8.7 fixes several bugs in 1.8.6.

Fixed code:
FORMAT_SETTINGS = frozenset([
    'DECIMAL_SEPARATOR',
    'THOUSAND_SEPARATOR',
    'NUMBER_GROUPING',
    'FIRST_DAY_OF_WEEK',
    'MONTH_DAY_FORMAT',
    'TIME_FORMAT',
    'DATE_FORMAT',
    'DATETIME_FORMAT',
    'SHORT_DATE_FORMAT',
    'SHORT_DATETIME_FORMAT',
    'YEAR_MONTH_FORMAT',
    'DATE_INPUT_FORMATS',
    'TIME_INPUT_FORMATS',
    'DATETIME_INPUT_FORMATS',
])


    if format_type not in FORMAT_SETTINGS:
        return format_type
Django 1.7.11 fixes a security issue and a data loss bug in 1.7.10.

Fixed settings leak possibility in ``date`` template filter
===========================================================

If an application allows users to specify an unvalidated format for dates and
passes this format to the :tfilter:`date` filter, e.g.
``{{ last_updated|date:user_date_format }}``, then a malicious user could
obtain any secret in the application's settings by specifying a settings key
instead of a date format. e.g. ``"SECRET_KEY"`` instead of ``"j/m/Y"``.

To remedy this, the underlying function used by the ``date`` template filter,
``django.utils.formats.get_format()``, now only allows accessing the date/time
formatting settings.
Django 1.8.7 fixes a security issue and several bugs in 1.8.6.
Fixed settings leak possibility in ``date`` template filter
===========================================================

If an application allows users to specify an unvalidated format for dates and
passes this format to the :tfilter:`date` filter, e.g.
``{{ last_updated|date:user_date_format }}``, then a malicious user could
obtain any secret in the application's settings by specifying a settings key
instead of a date format. e.g. ``"SECRET_KEY"`` instead of ``"j/m/Y"``.

To remedy this, the underlying function used by the ``date`` template filter,
``django.utils.formats.get_format()``, now only allows accessing the date/time
formatting settings.

    def test_format_arbitrary_settings(self):
        self.assertEqual(get_format('DEBUG'), 'DEBUG')
CVE-2020-5224 (Python, published 2020-01-24T20:15Z)
Description: value: In Django User Sessions (django-user-sessions) before 1.7.1, the views provided allow users to terminate specific sessions. The session key is used to identify sessions, and thus included in the rendered HTML. In itself this is not a problem. However if the website has an XSS vulnerability, the session key could be extracted by the attacker and a session takeover could happen.
Severity: MEDIUM (CVSS v3 base score: 8.8)
Weakness: CWE-326 \u2014 Inadequate Encryption Strength
The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.
Repository: https://github.com/jazzband/django-user-sessions
Files changed:
tests/tests.py
user_sessions/templates/user_sessions/session_list.html
Commit message: Don't expose session keys in views


Vulnerable code:
        self.assertContains(response, 'End Session', 3)
        <th>{% trans "End Session" %}</th>
        <td>
          <form method="post" action="{% url 'user_sessions:session_delete' object.pk %}">
            {% csrf_token %}
            {% if object.session_key == session_key %}
              <button type="submit" class="btn btn-xs btn-link">{% trans "End Session" %}</button>
            {% else %}
              <button type="submit" class="btn btn-xs btn-warning">{% trans "End Session" %}</button>
            {% endif %}
          </form>
        </td>

Fixed code:
        self.assertNotContains(response, 'ABC123')
CVE-2024-26131 (Other, published 2024-02-29T01:44Z)
Description: value: Element Android is an Android Matrix Client. Element Android version 1.4.3 through 1.6.10 is vulnerable to intent redirection, allowing a third-party malicious application to start any internal activity by passing some extra parameters. Possible impact includes making Element Android display an arbitrary web page, executing arbitrary JavaScript; bypassing PIN code protection; and account takeover by spawning a login screen to send credentials to an arbitrary home server. This issue is fixed in Element Android 1.6.12. There is no known workaround to mitigate the issue.
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/element-hq/element-android
Files changed:
changelog.d/+check-intent.bugfix
vector/src/main/java/im/vector/app/features/MainActivity.kt
Commit message: Add a check on incoming intent.


Vulnerable code:

Fixed code:
Add a check on incoming intent.
import im.vector.app.features.home.room.detail.RoomDetailActivity
import im.vector.app.features.home.room.threads.ThreadsActivity
import im.vector.app.features.location.live.map.LiveLocationMapViewActivity

        val allowList = listOf(
                HomeActivity::class.java.name,
                MainActivity::class.java.name,
                RoomDetailActivity::class.java.name,
                ThreadsActivity::class.java.name,
                LiveLocationMapViewActivity::class.java.name,
        )
                    ?.takeIf { it.isValid() }

    private fun Intent.isValid(): Boolean {
        val componentName = resolveActivity(packageManager) ?: return false
        val packageName = componentName.packageName
        val className = componentName.className
        return packageName == buildMeta.applicationId && className in allowList
    }
CVE-2024-26132 (Other, published 2024-02-29T01:44Z)
Description: value: Element Android is an Android Matrix Client. A third-party malicious application installed on the same phone can force Element Android, version 0.91.0 through 1.6.12, to share files stored under the `files` directory in the application's private data directory to an arbitrary room. The impact of the attack is reduced by the fact that the databases stored in this folder are encrypted. However, it contains some other potentially sensitive information, such as the FCM token. Forks of Element Android which have set `android:exported="false"` in the `AndroidManifest.xml` file for the `IncomingShareActivity` activity are not impacted. This issue is fixed in Element Android 1.6.12. There is no known workaround to mitigate the issue.
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/element-hq/element-android
Files changed:
changelog.d/+picker.bugfix
library/multipicker/src/main/java/im/vector/lib/multipicker/utils/MediaFileUtils.kt
library/multipicker/src/main/res/xml/multipicker_provider_paths.xml
Commit message: Store temporary files created for Camera in the media folder.


Vulnerable code:
    val storageDir: File = context.filesDir.also { it.mkdirs() }
        path="." />
</paths>

Fixed code:
Store temporary files created for Camera in the media folder.
    val storageDir: File = File(context.filesDir, "media").also { it.mkdirs() }
        path="media" />
</paths>
CVE-2012-2674 (C, published 2012-07-25T19:55Z)
Description: value: Multiple integer overflows in the (1) chk_malloc, (2) leak_malloc, and (3) leak_memalign functions in libc/bionic/malloc_debug_leak.c in Bionic (libc) for Android, when libc.debug.malloc is set, make it easier for context-dependent attackers to perform memory-related attacks such as buffer overflows via a large size value, which causes less memory to be allocated than expected.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-189 \u2014 Numeric Errors
Weaknesses in this category are related to improper calculation or conversion of numbers.
Repository: https://github.com/android/platform_bionic
Files changed:
libc/bionic/malloc_debug_leak.c
Commit message: bionic: fix integer overflows in chk_malloc(), leak_malloc(), and leak_memalign()

The allocation size in chk_malloc(), leak_malloc(), and leak_memalign()
functions may be rounded up to a small value, leading to buffer overflows.
The code only runs in debugging mode.

This patch complements commit 6f04a0f4 (CVE-2009-0607).

Change-Id: Id899bcd2bcd2ea2205e5753c433390710032dc83
Signed-off-by: Xi Wang <xi.wang@gmail.com>


Vulnerable code:
#include <arpa/inet.h>
#include <sys/socket.h>
#include <errno.h>
#include <stddef.h>
#include <stdarg.h>
#include <fcntl.h>
#include <dlfcn.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <sys/types.h>
    char* buffer = (char*)dlmalloc(bytes + CHK_OVERHEAD_SIZE);
    void* base = dlmalloc(bytes + sizeof(AllocationEntry));

Fixed code:

#include <dlfcn.h>
#include <fcntl.h>
#include <stdarg.h>
#include <stddef.h>
#include <stdint.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <sys/un.h>
    size_t size = bytes + CHK_OVERHEAD_SIZE;
    if (size < bytes) { // Overflow.
        return NULL;
    }
    uint8_t* buffer = (uint8_t*) dlmalloc(size);
    size_t size = bytes + sizeof(AllocationEntry);
    if (size < bytes) { // Overflow.
        return NULL;
    }

    void* base = dlmalloc(size);
    if (size < bytes) { // Overflow.
        return NULL;
    }
CVE-2020-15105 (Unknown, published 2020-07-10T21:15Z)
Description: value: Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authentication code. This means that the password is stored in clear text in the session for an arbitrary amount of time, and potentially forever if the user begins the login process by entering their username and password and then leaves before entering their two-factor authentication code. The severity of this issue depends on which type of session storage you have configured: in the worst case, if you're using Django's default database session storage, then users' passwords are stored in clear text in your database. In the best case, if you're using Django's signed cookie session, then users' passwords are only stored in clear text within their browser's cookie store. In the common case of using Django's cache session store, the users' passwords are stored in clear text in whatever cache storage you have configured (typically Memcached or Redis). This has been fixed in 1.12. After upgrading, users should be sure to delete any clear text passwords that have been stored. For example, if you're using the database session backend, you'll likely want to delete any session record from the database and purge that data from any database backups or replicas. In addition, affected organizations who have suffered a database breach while using an affected version should inform their users that their clear text passwords have been compromised. All organizations should encourage users whose passwords were insecurely stored to change these passwords on any sites where they were used. As a workaround, wwitching Django's session storage to use signed cookies instead of the database or cache lessens the impact of this issue, but should not be done without a thorough understanding of the security tradeoffs of using signed cookies rather than a server-side session storage. There is no way to fully mitigate the issue without upgrading.
Severity: LOW (CVSS v3 base score: 5.4)
Weakness: CWE-312 \u2014 Cleartext Storage of Sensitive Information
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
Repository: https://github.com/Bouke/django-two-factor-auth
Files changed:
Commit message: Merge pull request from GHSA-vhr6-pvjm-9qwf

Discontinue storing credentials in the session store

Vulnerable code:

Fixed code:
CVE-2024-28186 (Unknown, published 2024-03-12T20:15Z)
Description: value: FreeScout is an open source help desk and shared inbox built with PHP.

A vulnerability has been identified in the Free Scout Application, which exposes SMTP server credentials used by an organization in the application to users of the application. This issue arises from the application storing complete stack traces of exceptions in its database. The sensitive information is then inadvertently disclosed to users via the `/conversation/ajax-html/send_log?folder_id=&thread_id={id}` endpoint. The stack trace reveals value of parameters, including the username and password, passed to the `Swift_Transport_Esmtp_Auth_LoginAuthenticator->authenticate()` function. Exploiting this vulnerability allows an attacker to gain unauthorized access to SMTP server credentials. With this sensitive information in hand, the attacker can potentially send unauthorized emails from the compromised SMTP server, posing a severe threat to the confidentiality and integrity of email communications. This could lead to targeted attacks on both the application users and the organization itself, compromising the security of email exchange servers. This issue has been addressed in version 1.8.124. Users are advised to upgrade. Users unable to upgrade should adopt the following measures: 1. Avoid Storing Complete Stack Traces, 2. Implement redaction mechanisms to filter and exclude sensitive information, and 3. Review and enhance the application's logging practices.
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/freescout-helpdesk/freescout
Files changed:
Commit message: Merge branch 'master' of github.com:freescout-helpdesk/freescout into dist


Vulnerable code:

Fixed code:
CVE-2024-34697 (PHP, published 2024-05-14T15:39Z)
Description: value: FreeScout is a free, self-hosted help desk and shared mailbox. A stored HTML Injection vulnerability has been identified in the Email Receival Module of the Freescout Application. The vulnerability allows attackers to inject malicious HTML content into emails sent to the application's mailbox. This vulnerability arises from improper handling of HTML content within incoming emails, allowing attackers to embed malicious HTML code in the context of the application's domain. Unauthenticated attackers can exploit this vulnerability to inject malicious HTML content into emails. This could lead to various attacks such as form hijacking, application defacement, or data exfiltration via CSS injection. Although unauthenticated attackers are limited to HTML injection, the consequences can still be severe. Version 1.8.139 implements strict input validation and sanitization mechanisms to ensure that any HTML content received via emails is properly sanitized to prevent malicious HTML injections.
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/freescout-helpdesk/freescout
Files changed:
app/Http/Controllers/ConversationsController.php
Commit message: Remove unwanted tags from HTML when editing threads - GHSA-985r-6qfc-hg8m


Vulnerable code:
                    $response['html'] = \Helper::stripDangerousTags($response['html']);

Fixed code:
                    $thread->body = \Helper::stripDangerousTags($thread->body);
CVE-2024-34698 (JavaScript, published 2024-05-14T15:39Z)
Description: value: FreeScout is a free, self-hosted help desk and shared mailbox. Versions of FreeScout prior to 1.8.139 contain a Prototype Pollution vulnerability in the `/public/js/main.js` source file. The Prototype Pollution arises because the `getQueryParam` Function recursively merges an object containing user-controllable properties into an existing object (For URL Query Parameters Parsing), without first sanitizing the keys. This can allow an attacker to inject a property with a key `__proto__`, along with arbitrarily nested properties. The merge operation assigns the nested properties to the `params` object's prototype instead of the target object itself. As a result, the attacker can pollute the prototype with properties containing harmful values, which are then inherited by user-defined objects and subsequently used by the application dangerously. The vulnerability lets an attacker control properties of objects that would otherwise be inaccessible. If the application subsequently handles an attacker-controlled property in an unsafe way, this can potentially be chained with other vulnerabilities like DOM-based XSS, Open Redirection, Cookie Manipulation, Link Manipulation, HTML Injection, etc. Version 1.8.139 contains a patch for the issue.
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/freescout-helpdesk/freescout
Files changed:
public/js/main.js
Commit message: Do not allow Prototype Pollution via getQueryParam() function - GHSA-rx6j-4c33-9h3r


Vulnerable code:

Fixed code:

    	// Skip __proto__
    	// https://github.com/freescout-helpdesk/freescout/security/advisories/GHSA-rx6j-4c33-9h3r
    	if (param.match(/^__proto__\[/i)) {
    		continue;
    	}