hitoshura25/cvefixes huggingface dataset:
CVE-2016-10197 (C, published 2017-03-15T15:59Z)
Description: value: The search_make_new function in evdns.c in libevent before 2.1.6-beta allows attackers to cause a denial of service (out-of-bounds read) via an empty hostname.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/libevent/libevent
Files changed:
evdns.c
Commit message: evdns: fix searching empty hostnames

From #332:
  Here follows a bug report by **Guido Vranken** via the _Tor bug bounty program_. Please credit Guido accordingly.

  ## Bug report

  The DNS code of Libevent contains this rather obvious OOB read:

  ```c
  static char *
  search_make_new(const struct search_state *const state, int n, const char *const base_name) {
      const size_t base_len = strlen(base_name);
      const char need_to_append_dot = base_name[base_len - 1] == '.' ? 0 : 1;
  ```

  If the length of ```base_name``` is 0, then line 3125 reads 1 byte before the buffer. This will trigger a crash on ASAN-protected builds.

  To reproduce:

  Build libevent with ASAN:
  ```
  $ CFLAGS='-fomit-frame-pointer -fsanitize=address' ./configure && make -j4
  ```
  Put the attached ```resolv.conf``` and ```poc.c``` in the source directory and then do:

  ```
  $ gcc -fsanitize=address -fomit-frame-pointer poc.c .libs/libevent.a
  $ ./a.out
  =================================================================
  ==22201== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60060000efdf at pc 0x4429da bp 0x7ffe1ed47300 sp 0x7ffe1ed472f8
  READ of size 1 at 0x60060000efdf thread T0
  ```

P.S. we can add a check earlier, but since this is very uncommon, I didn't add it.

Fixes: #332


Vulnerable code:
	const char need_to_append_dot = base_name[base_len - 1] == '.' ? 0 : 1;

Fixed code:
	char need_to_append_dot;
	if (!base_len) return NULL;
	need_to_append_dot = base_name[base_len - 1] == '.' ? 0 : 1;
CVE-2023-30847 (Unknown, published 2023-04-27T15:15Z)
Description: value: H2O is an HTTP server. In versions 2.3.0-beta2 and prior, when the reverse proxy handler tries to processes a certain type of invalid HTTP request, it tries to build an upstream URL by reading from uninitialized pointer. This behavior can lead to crashes or leak of information to back end HTTP servers. Pull request  number 3229 fixes the issue. The pull request has been merged to the `master` branch in commit f010336. Users should upgrade to commit f010336 or later.
Severity: nan (CVSS v3 base score: 8.2)
Weakness: CWE-824 \u2014 Access of Uninitialized Pointer
The product accesses or uses a pointer that has not been initialized.
Repository: https://github.com/h2o/h2o
Files changed:
Commit message: Merge pull request #3229 from h2o/kazuho/reverse-proxy-invalid-read

[reverse proxy] invalid memory read

Vulnerable code:

Fixed code:
CVE-2023-41337 (Unknown, published 2023-12-12T20:15Z)
Description: value: h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. In version 2.3.0-beta2 and prior, when h2o is configured to listen to multiple addresses or ports with each of them using different backend servers managed by multiple entities, a malicious backend entity that also has the opportunity to observe or inject packets exchanged between the client and h2o may misdirect HTTPS requests going to other backends and observe the contents of that HTTPS request being sent.

The attack involves a victim client trying to resume a TLS connection and an attacker redirecting the packets to a different address or port than that intended by the client. The attacker must already have been configured by the administrator of h2o to act as a backend to one of the addresses or ports that the h2o instance listens to. Session IDs and tickets generated by h2o are not bound to information specific to the server address, port, or the X.509 certificate, and therefore it is possible for an attacker to force the victim connection to wrongfully resume against a different server address or port on which the same h2o instance is listening.

Once a TLS session is misdirected to resume to a server address / port that is configured to use an attacker-controlled server as the backend, depending on the configuration, HTTPS requests from the victim client may be forwarded to the attacker's server.

An H2O instance is vulnerable to this attack only if the instance is configured to listen to different addresses or ports using the listen directive at the host level and the instance is configured to connect to backend servers managed by multiple entities.

A patch is available at commit 35760540337a47e5150da0f4a66a609fad2ef0ab. As a workaround, one may stop using using host-level listen directives in favor of global-level ones.
Severity: nan (CVSS v3 base score: 6.7)
Weakness: CWE-347 \u2014 Improper Verification of Cryptographic Signature
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
Repository: https://github.com/h2o/h2o
Files changed:
Commit message: Merge pull request from GHSA-5v5r-rghf-rm6q

block cross-certificate session resumption

Vulnerable code:

Fixed code:
CVE-2023-50247 (Unknown, published 2023-12-12T20:15Z)
Description: value: h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. The QUIC stack (quicly), as used by H2O up to commit 43f86e5 (in version 2.3.0-beta and prior), is susceptible to a state exhaustion attack. When H2O is serving HTTP/3, a remote attacker can exploit this vulnerability to progressively increase the memory retained by the QUIC stack. This can eventually cause H2O to abort due to memory exhaustion. The vulnerability has been resolved in commit d67e81d03be12a9d53dc8271af6530f40164cd35. HTTP/1 and HTTP/2 are not affected by this vulnerability as they do not use QUIC. Administrators looking to mitigate this issue without upgrading can disable HTTP/3 support.
Severity: nan (CVSS v3 base score: 7.5)
Weakness: CWE-770 \u2014 Allocation of Resources Without Limits or Throttling
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
Repository: https://github.com/h2o/h2o
Files changed:
Commit message: Merge pull request from GHSA-2ch5-p59c-7mv6

QUIC state exhaustion DoS

Vulnerable code:

Fixed code:
CVE-2024-2952 (Unknown, published 2024-04-10T17:15Z)
Description: value: BerriAI/litellm is vulnerable to Server-Side Template Injection (SSTI) via the `/completions` endpoint. The vulnerability arises from the `hf_chat_template` method processing the `chat_template` parameter from the `tokenizer_config.json` file through the Jinja template engine without proper sanitization. Attackers can exploit this by crafting malicious `tokenizer_config.json` files that execute arbitrary code on the server.
Severity: nan (CVSS v3 base score: )
Weakness: CWE-76 \u2014 Improper Neutralization of Equivalent Special Elements
The product correctly neutralizes certain special elements, but it improperly neutralizes equivalent special elements.
Repository: https://github.com/berriai/litellm
Files changed:
Commit message: Merge pull request #2941 from BerriAI/litellm_fix_sec_report

[FIX] -  Security issue Server-Side Template Injection in /completions endpoint in

Vulnerable code:

Fixed code:
CVE-2021-43829 (Python, published 2021-12-14T20:15Z)
Description: value: PatrOwl is a free and open-source solution for orchestrating Security Operations. In versions prior to 1.7.7 PatrowlManager unrestrictly handle upload files in the findings import feature. This vulnerability is capable of uploading dangerous type of file to server leading to XSS attacks and potentially other forms of code injection. Users are advised to update to 1.7.7 as soon as possible. There are no known workarounds for this issue.
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/Patrowl/PatrowlManager
Files changed:
app/urls.py
findings/forms.py
Commit message: Fix Unrestricted Upload of File with Dangerous Type (from Huntr bug bounty report)


Vulnerable code:
api_schema_view = get_swagger_view(title='PatrOwl Manager REST-API')
    file = forms.FileField()
        fields = ['title', 'type', 'severity', 'status', 'description', 'tags',
            'solution', 'risk_info', 'vuln_refs', 'links', 'comments', 'asset']

Fixed code:
api_schema_view = get_swagger_view(title='PatrowlManager REST-API')
import os
def validate_file_extension(value):
    ext = os.path.splitext(value.name)[1]
    valid_extensions = ['.xml', '.nessus', '.json']
    if ext not in valid_extensions:
        raise ValidationError(u'File not supported!')


    file = forms.FileField(widget=forms.FileInput(
        attrs={'accept': 'text/xml,application/json'}),
        validators=[validate_file_extension]
    )
        fields = [
            'title', 'type', 'severity', 'status', 'description', 'tags',
            'solution', 'risk_info', 'vuln_refs', 'links', 'comments', 'asset'
        ]
CVE-2016-10189 (C, published 2017-03-14T14:59Z)
Description: value: BitlBee before 3.5 allows remote attackers to cause a denial of service (NULL pointer dereference and crash) and possibly execute arbitrary code via a file transfer request for a contact that is not in the contact list.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-476 \u2014 NULL Pointer Dereference
The product dereferences a pointer that it expects to be valid but is NULL.
Repository: https://github.com/bitlbee/bitlbee
Files changed:
protocols/bee_ft.c
Commit message: imcb_file_send_start: handle ft attempts from non-existing users


Vulnerable code:
	if (bee->ui->ft_in_start) {

Fixed code:
	if (bee->ui->ft_in_start && bu) {
CVE-2017-5668 (C, published 2017-03-14T14:59Z)
Description: value: bitlbee-libpurple before 3.5.1 allows remote attackers to cause a denial of service (NULL pointer dereference and crash) and possibly execute arbitrary code via a file transfer request for a contact that is not in the contact list.  NOTE: this vulnerability exists because of an incomplete fix for CVE-2016-10189.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-476 \u2014 NULL Pointer Dereference
The product dereferences a pointer that it expects to be valid but is NULL.
Repository: https://github.com/bitlbee/bitlbee
Files changed:
protocols/purple/ft.c
Commit message: purple: Fix crash on ft requests from unknown contacts

Followup to 701ab81 (included in 3.5) which was a partial fix which only
improved things for non-libpurple file transfers (that is, just jabber)


Vulnerable code:

Fixed code:

	if (!px->ft) {
		return FALSE;
	}
CVE-2024-23332 (Markdown, published 2024-01-19T23:15Z)
Description: value: The Notary Project is a set of specifications and tools intended to provide a cross-industry standard for securing software supply chains by using authentic container images and other OCI artifacts. An external actor with control of a compromised container registry can provide outdated versions of OCI artifacts, such as Images. This could lead artifact consumers with relaxed trust policies (such as `permissive` instead of `strict`) to potentially use artifacts with signatures that are no longer valid, making them susceptible to any exploits those artifacts may contain. In Notary Project, an artifact publisher can control the validity period of artifact by specifying signature expiry during the signing process. Using shorter signature validity periods along with processes to periodically resign artifacts, allows artifact producers to ensure that their consumers will only receive up-to-date artifacts. Artifact consumers should correspondingly use a `strict` or equivalent trust policy that enforces signature expiry. Together these steps enable use of up-to-date artifacts and safeguard against rollback attack in the event of registry compromise. The Notary Project offers various signature validation options such as `permissive`, `audit` and `skip` to support various scenarios. These scenarios includes 1) situations demanding urgent workload deployment, necessitating the bypassing of expired or revoked signatures; 2) auditing of artifacts lacking signatures without interrupting workload; and 3) skipping of verification for specific images that might have undergone validation through alternative mechanisms. Additionally, the Notary Project supports revocation to ensure the signature freshness. Artifact publishers can sign with short-lived certificates and revoke older certificates when necessary. This revocation serves as a signal to inform artifact consumers that the corresponding unexpired artifact is no longer approved by the publisher. This enables the artifact publisher to control the validity of the signature independently of their ability to manage artifacts in a compromised registry.
Severity: nan (CVSS v3 base score: 6.8)
Weakness: CWE-672 \u2014 Operation on a Resource after Expiration or Release
The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
Repository: https://github.com/notaryproject/specifications
Files changed:
threatmodels/notation-threatmodel.md
Commit message: Update threat model to include rollback attack (#285)

* Update threat model to add rollback attack

Signed-off-by: Pritesh Bandi <priteshbandi@gmail.com>

Vulnerable code:

Fixed code:
| Rollback Attack                              | Tampering              | Mitigated | High     | Notation       | Attacker can exploit a compromised repository to return outdated vulnerable artifacts | Signer can employ short signature expiration periods (and periodically re-sign artifacts) or revoke outdated vulnerable artifacts |
CVE-2016-10536 (JavaScript, published 2018-05-31T20:29Z)
Description: value: engine.io-client is the client for engine.io, the implementation of a transport-based cross-browser/cross-device bi-directional communication layer for Socket.IO. The vulnerability is related to the way that node.js handles the `rejectUnauthorized` setting. If the value is something that evaluates to false, certificate verification will be disabled. This is problematic as engine.io-client 1.6.8 and earlier passes in an object for settings that includes the rejectUnauthorized property, whether it has been set or not. If the value has not been explicitly changed, it will be passed in as `null`, resulting in certificate verification being turned off.
Severity: MEDIUM (CVSS v3 base score: 5.9)
Weakness: CWE-295 \u2014 Improper Certificate Validation
The product does not validate, or incorrectly validates, a certificate.
Repository: https://github.com/socketio/engine.io-client
Files changed:
lib/socket.js
Commit message: default `rejectUnauthorized` to `true`


Vulnerable code:
  this.rejectUnauthorized = opts.rejectUnauthorized === undefined ? null : opts.rejectUnauthorized;

Fixed code:
  this.rejectUnauthorized = opts.rejectUnauthorized === undefined ? true : opts.rejectUnauthorized;
CVE-2011-0766 (Unknown, published 2011-05-31T20:55Z)
Description: value: The random number generator in the Crypto application before 2.0.2.2, and SSH before 2.0.5, as used in the Erlang/OTP ssh library before R14B03, uses predictable seeds based on the current time, which makes it easier for remote attackers to guess DSA host and SSH session keys.
Severity: HIGH (CVSS v3 base score: )
Weakness: CWE-310 \u2014 Cryptographic Issues
Weaknesses in this category are related to the design and implementation of data confidentiality and integrity. Frequently these deal with the use of encoding techniques, encryption libraries, and hashing algorithms. The weaknesses in this category could lead to a degradation of the quality data if they are not addressed.
Repository: https://github.com/erlang/otp
Files changed:
Commit message: Merge branch 'maint-r14' into dev


Vulnerable code:

Fixed code:
CVE-2020-36406 (C, published 2021-07-01T03:15Z)
Description: value: uWebSockets 18.11.0 and 18.12.0 has a stack-based buffer overflow in uWS::TopicTree::trimTree (called from uWS::TopicTree::unsubscribeAll). NOTE: the vendor's position is that this is "a minor issue or not even an issue at all" because the developer of an application (that uses uWebSockets) should not be allowing the large number of triggered topics to accumulate
Severity: MEDIUM (CVSS v3 base score: 8.8)
Weakness: CWE-787 \u2014 Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/uNetworking/uWebSockets
Files changed:
src/TopicTree.h
Commit message: Fix overflow of triggered topics


Vulnerable code:
        /* If we already have 64 triggered topics make sure to drain it here */
        if (numTriggeredTopics == 64) {
            drain();
        }

Fixed code:
                    /* If we already have 64 triggered topics make sure to drain it here */
                    if (numTriggeredTopics == 64) {
                        drain();
                    }

            /* If we already have 64 triggered topics make sure to drain it here */
            if (numTriggeredTopics == 64) {
                drain();
            }
CVE-2021-23413 (JavaScript, published 2021-07-25T13:15Z)
Description: value: This affects the package jszip before 3.7.0. Crafting a new zip file with filenames set to Object prototype values (e.g __proto__, toString, etc) results in a returned object with a modified prototype instance.
Severity: MEDIUM (CVSS v3 base score: 5.3)
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/Stuk/jszip
Files changed:
lib/index.js
lib/object.js
Commit message: fix: Use a null prototype object for this.files

This approach is taken to prevent overriding object methods that would
exist on a normal object Object.create({})


Vulnerable code:
    this.files = {};
            if (!this.files.hasOwnProperty(filename)) {
                continue;
            }

Fixed code:
    // NOTE: we use a null prototype because we do not
    // want filenames like "toString" coming from a zip file
    // to overwrite methods and attributes in a normal Object.
    this.files = Object.create(null);
        /* jshint ignore:start */
        // ignore warning about unwanted properties because this.files is a null prototype object
        /* jshint ignore:end */
CVE-2015-8789 (Other, published 2016-01-29T19:59Z)
Description: value: Use-after-free vulnerability in the EbmlMaster::Read function in libEBML before 1.3.3 allows context-dependent attackers to have unspecified impact via a "deeply nested element with infinite size" followed by another element of an upper level in an EBML document.
Severity: HIGH (CVSS v3 base score: 9.6)
Weakness: NVD-CWE-Other \u2014 Other
NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
Repository: https://github.com/Matroska-Org/libebml
Files changed:
ChangeLog
src/EbmlMaster.cpp
Commit message: EbmlMaster: propagate upper level element after infinite sized one correctly

When the parser encountered a deeply nested element with an infinite
size then a following element of an upper level was not propagated
correctly. Instead the element with the infinite size was added into the
EBML element tree a second time resulting in memory access after freeing
it and multiple attempts to free the same memory address during
destruction.

Fixes the issue reported as Cisco TALOS-CAN-0037.


Vulnerable code:

Fixed code:
        * EbmlMaster::Read(): When the parser encountered a deeply nested
        element with an infinite size then a following element of an upper
        level was not propagated correctly. Instead the element with the
        infinite size was added into the EBML element tree a second time
        resulting in memory access after freeing it and multiple attempts
        to free the same memory address during destruction. Fixes the
        issue reported as Cisco TALOS-CAN-0037.


          if (UpperEltFound) {
            --UpperEltFound;
            if (UpperEltFound > 0 || MaxSizeToRead <= 0)
              goto processCrc;
            ElementLevelA = FoundElt;
          }
CVE-2015-8790 (Other, published 2016-01-29T19:59Z)
Description: value: The EbmlUnicodeString::UpdateFromUTF8 function in libEBML before 1.3.3 allows context-dependent attackers to obtain sensitive information from process heap memory via a crafted UTF-8 string, which triggers an invalid memory access.
Severity: MEDIUM (CVSS v3 base score: 4.3)
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/Matroska-Org/libebml
Files changed:
ChangeLog
src/EbmlUnicodeString.cpp
Commit message: EbmlUnicodeString: don't read beyond end of string

The conversion from an UTF-8 encoded string into a wchar_t one was
reading from beyond the end of the source buffer if the length indicated
by a UTF-8 character's first byte exceeds the number of bytes actually
present afterwards.

Fixes the issue reported as Cisco TALOS-CAN-0036.


Vulnerable code:
  for (_Length=0, i=0; i<UTF8string.length(); _Length++) {
    uint8 lead = static_cast<uint8>(UTF8string[i]);
    if (lead < 0x80)
      i++;
    else if ((lead >> 5) == 0x6)
      i += 2;
    else if ((lead >> 4) == 0xe)
      i += 3;
    else if ((lead >> 3) == 0x1e)
      i += 4;
  for (j=0, i=0; i<UTF8string.length(); j++) {
    uint8 lead = static_cast<uint8>(UTF8string[i]);
    if (lead < 0x80) {
      i++;
    } else if ((lead >> 5) == 0x6) {
      i += 2;
    } else if ((lead >> 4) == 0xe) {
      i += 3;
    } else if ((lead >> 3) == 0x1e) {
      i += 4;
    } else
      // Invalid char?
      break;

Fixed code:
2015-10-20  Moritz Bunkus  <moritz@bunkus.org>

        * EbmlUnicodeString::UpdateFromUTF8(): Fixed an invalid memory
        access. When reading from a UTF-8 string in which the length
        indicated by a UTF-8 character's first byte exceeds the string's
        actual number of bytes the parser would access beyond the end of
        the string resulting in a heap information leak. Fixes the issue
        reported as Cisco TALOS-CAN-0036.

static unsigned int UTFCharLength(uint8 lead)
{
  if (lead < 0x80)
    return 1;
  else if ((lead >> 5) == 0x6)
    return 2;
  else if ((lead >> 4) == 0xe)
    return 3;
  else if ((lead >> 3) == 0x1e)
    return 4;
  else
    // Invalid size?
    return 0;
}

  const size_t SrcLength = UTF8string.length();
  for (_Length=0, i=0; i<SrcLength; _Length++) {
    const unsigned int CharLength = UTFCharLength(static_cast<uint8>(UTF8string[i]));
    if ((CharLength >= 1) && (CharLength <= 4))
      i += CharLength;
  for (j=0, i=0; i<SrcLength; j++) {
    const uint8 lead              = static_cast<uint8>(UTF8string[i]);
    const unsigned int CharLength = UTFCharLength(lead);
    if ((CharLength < 1) || (CharLength > 4))
      // Invalid char?
      break;

    if ((i + CharLength) > SrcLength)
      // Guard against invalid memory access beyond the end of the
      // source buffer.
      break;

    if (CharLength == 1)
    else if (CharLength == 2)
    else if (CharLength == 3)
    else if (CharLength == 4)

    i += CharLength;