hitoshura25/cvefixes huggingface dataset:
CVE-2024-23837 (C, published 2024-02-26T16:27Z)
Description: value: LibHTP is a security-aware parser for the HTTP protocol. Crafted traffic can cause excessive processing time of HTTP headers, leading to denial of service. This issue is addressed in 0.5.46.
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/OISF/libhtp
Files changed:
htp/htp_private.h
htp/htp_request.c
htp/htp_response.c
Commit message: headers: limit the size of folded headers

Ticket: #6444

So as to limit the quadratic complexity of always reallocating
to push more bytes in header value


Vulnerable code:
                    // Add to the existing header.                    
                    bstr *new_in_header = bstr_add_mem(connp->in_header, data, len);
                    if (new_in_header == NULL) return HTP_ERROR;
                    connp->in_header = new_in_header;
                        bstr *new_out_header = bstr_add_mem(connp->out_header, data, len);
                        if (new_out_header == NULL)
                            return HTP_ERROR;
                        connp->out_header = new_out_header;

Fixed code:
// as CURL_MAX_HTTP_HEADER
#define HTP_MAX_HEADER_FOLDED 102400

                    // Add to the existing header.
                    if (bstr_len(connp->in_header) < HTP_MAX_HEADER_FOLDED) {
                        bstr *new_in_header = bstr_add_mem(connp->in_header, data, len);
                        if (new_in_header == NULL) return HTP_ERROR;
                        connp->in_header = new_in_header;
                    } else {
                        htp_log(connp, HTP_LOG_MARK, HTP_LOG_WARNING, 0, "Request field length exceeds folded maximum");
                    }
                        if (bstr_len(connp->out_header) < HTP_MAX_HEADER_FOLDED) {
                            bstr *new_out_header = bstr_add_mem(connp->out_header, data, len);
                            if (new_out_header == NULL)
                                return HTP_ERROR;
                            connp->out_header = new_out_header;
                        } else {
                            htp_log(connp, HTP_LOG_MARK, HTP_LOG_WARNING, 0, "Response field length exceeds folded maximum");
                        }
CVE-2024-28871 (C, published 2024-04-04T15:15Z)
Description: value: LibHTP is a security-aware parser for the HTTP protocol and the related bits and pieces. Version 0.5.46 may parse malformed request traffic, leading to excessive CPU usage. Version 0.5.47 contains a patch for the issue. No known workarounds are available.
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/OISF/libhtp
Files changed:
htp/htp_request.c
Commit message: request: limit probing after missing protocol

And do not consider HTTP/0.9 if there is too much junk afterward.

Avoids quadratic complexity with probing many whitespaces lines.

Ticket: 6757

Fixes: bf618ec7f243 ("http0.9: process headers if there are non-space characters")


Vulnerable code:

Fixed code:
// HTTP/0.9 is supposed to be only a request line without protocol.
// Libhtp will still consider the request to be HTTP/0.9 if there
// are some junk whitespaces after that request line.
// Libhtp allows the small value of 16 extra bytes/whitespaces,
// otherwise we consider it to be a HTTP/1.x request with missing protocol.
// It is unlikely to meet HTTP/0.9, and we want to limit probing.
#define HTTP09_MAX_JUNK_LEN 16

        if (connp->in_current_len > connp->in_current_read_offset + HTTP09_MAX_JUNK_LEN) {
            htp_log(connp, HTP_LOG_MARK, HTP_LOG_WARNING, 0, "Request line: missing protocol");
            connp->in_tx->is_protocol_0_9 = 0;
            // Switch to request header parsing.
            connp->in_state = htp_connp_REQ_HEADERS;
            connp->in_tx->request_progress = HTP_REQUEST_HEADERS;
            return HTP_OK;
        }
CVE-2024-28871 (C++, published 2024-04-04T15:15Z)
Description: value: LibHTP is a security-aware parser for the HTTP protocol and the related bits and pieces. Version 0.5.46 may parse malformed request traffic, leading to excessive CPU usage. Version 0.5.47 contains a patch for the issue. No known workarounds are available.
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/OISF/libhtp
Files changed:
htp/htp_request.c
test/test_main.cpp
Commit message: http0.9: process headers if there are non-space characters

Previously, we fell back on HTTP/0.9 if there was a missing protocol
except if the following line cintained a colon.

This makes libhtp stricter to consider a transaction as 0.9
by only accepting if we have spaces after the request line

as done in libhtp-rs

Ticket: 6643


Vulnerable code:
        int afterspaces = 0;
            if (connp->in_current_data[pos] == ':') {
            } else if (htp_is_lws(connp->in_current_data[pos])) {
                // Allows spaces after header name
                afterspaces = 1;
            } else if (htp_is_space(connp->in_current_data[pos]) || afterspaces == 1) {
                break;
    ASSERT_TRUE(connp->conn->flags & HTP_CONN_HTTP_0_9_EXTRA);

Fixed code:
            if (!htp_is_space(connp->in_current_data[pos])) {
CVE-2018-18928 (C++, published 2018-11-04T20:29Z)
Description: value: International Components for Unicode (ICU) for C/C++ 63.1 has an integer overflow in number::impl::DecimalQuantity::toScientificString() in i18n/number_decimalquantity.cpp.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/unicode-org/icu
Files changed:
icu4c/source/i18n/fmtable.cpp
icu4c/source/i18n/number_decimalquantity.cpp
icu4c/source/test/intltest/numfmtst.cpp
icu4j/main/classes/core/src/com/ibm/icu/impl/number/DecimalQuantity_AbstractBCD.java
icu4j/main/classes/core/src/com/ibm/icu/impl/number/DecimalQuantity_DualStorageBCD.java
icu4j/main/tests/core/src/com/ibm/icu/dev/test/format/NumberFormatTest.java
Commit message: ICU-20246 Fixing another integer overflow in number parsing.


Vulnerable code:
      } else if (std::abs(fDecimalQuantity->getMagnitude()) < 5) {
    if (_scale < 0) {
        if (_scale < 0) {
            result = result.scaleByPowerOfTen(scale);

Fixed code:
      } else if (fDecimalQuantity->getMagnitude() != INT32_MIN && std::abs(fDecimalQuantity->getMagnitude()) < 5) {
    if (_scale == INT32_MIN) {
        result.append({u"-2147483648", -1});
        return result;
    } else if (_scale < 0) {

    // Test edge case overflow of exponent
    result = Formattable();
    nf->parse(u".0003e-2147483644", result, status);
    sp = result.getDecimalNumber(status);
    assertEquals(u"Should not overflow",
                 u"3E-2147483648",
                 {sp.data(), sp.length(), US_INV});
        if (_scale == Integer.MIN_VALUE) {
            result.append("-2147483648");
            return;
        } else if (_scale < 0) {
            try {
                result = result.scaleByPowerOfTen(scale);
            } catch (ArithmeticException e) {
                if (e.getMessage().contains("Underflow")) {
                    result = BigDecimal.ZERO;
                } else {
                    throw e;
                }
            }

        // Test edge case overflow of exponent
        result = nf.parse(".0003e-2147483644");
        assertEquals("Should not overflow",
                "0", result.toString());
CVE-2020-10531 (C++, published 2020-03-12T19:15Z)
Description: value: An issue was discovered in International Components for Unicode (ICU) for C/C++ through 66.1. An integer overflow, leading to a heap-based buffer overflow, exists in the UnicodeString::doAppend() function in common/unistr.cpp.
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/unicode-org/icu
Files changed:
icu4c/source/common/unistr.cpp
icu4c/source/test/intltest/ustrtest.cpp
icu4c/source/test/intltest/ustrtest.h
Commit message: ICU-20958 Prevent SEGV_MAPERR in append

See #971

Vulnerable code:
  int32_t newLength = oldLength + srcLength;

Fixed code:
  int32_t newLength;
  if (uprv_add32_overflow(oldLength, srcLength, &newLength)) {
    setToBogus();
    return *this;
  }
    TESTCASE_AUTO(TestLargeAppend);

void UnicodeStringTest::TestLargeAppend() {
    if(quick) return;

    IcuTestErrorCode status(*this, "TestLargeAppend");
    // Make a large UnicodeString
    int32_t len = 0xAFFFFFF;
    UnicodeString str;
    char16_t *buf = str.getBuffer(len);
    // A fast way to set buffer to valid Unicode.
    // 4E4E is a valid unicode character
    uprv_memset(buf, 0x4e, len * 2);
    str.releaseBuffer(len);
    UnicodeString dest;
    // Append it 16 times
    // 0xAFFFFFF times 16 is 0xA4FFFFF1,
    // which is greater than INT32_MAX, which is 0x7FFFFFFF.
    int64_t total = 0;
    for (int32_t i = 0; i < 16; i++) {
        dest.append(str);
        total += len;
        if (total <= INT32_MAX) {
            assertFalse("dest is not bogus", dest.isBogus());
        } else {
            assertTrue("dest should be bogus", dest.isBogus());
        }
    }
    dest.remove();
    total = 0;
    for (int32_t i = 0; i < 16; i++) {
        dest.append(str);
        total += len;
        if (total + len <= INT32_MAX) {
            assertFalse("dest is not bogus", dest.isBogus());
        } else if (total <= INT32_MAX) {
            // Check that a string of exactly the maximum size works
            UnicodeString str2;
            int32_t remain = INT32_MAX - total;
            char16_t *buf2 = str2.getBuffer(remain);
            if (buf2 == nullptr) {
                // if somehow memory allocation fail, return the test
                return;
            }
            uprv_memset(buf2, 0x4e, remain * 2);
            str2.releaseBuffer(remain);
            dest.append(str2);
            total += remain;
            assertEquals("When a string of exactly the maximum size works", (int64_t)INT32_MAX, total);
            assertEquals("When a string of exactly the maximum size works", INT32_MAX, dest.length());
            assertFalse("dest is not bogus", dest.isBogus());

            // Check that a string size+1 goes bogus
            str2.truncate(1);
            dest.append(str2);
            total++;
            assertTrue("dest should be bogus", dest.isBogus());
        } else {
            assertTrue("dest should be bogus", dest.isBogus());
        }
    }
}
    void TestLargeAppend();
CVE-2011-10003 (PHP, published 2023-02-07T21:15Z)
Description: value: A vulnerability was found in XpressEngine up to 1.4.4. It has been rated as critical. This issue affects some unknown processing of the component Update Query Handler. The manipulation leads to sql injection. Upgrading to version 1.4.5 is able to address this issue. The patch is named c6e94449f21256d6362450b29c7847305e756ad5. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-220247.
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/haegyung/xe-core
Files changed:
classes/db/DBCubrid.class.php
classes/db/DBMssql.class.php
classes/db/DBMysql.class.php
classes/db/DBPostgresql.class.php
classes/db/DBSqlite2.class.php
classes/db/DBSqlite3_pdo.class.php
Commit message: #19727459 SQL Injection fixed in Update Query


git-svn-id: http://xe-core.googlecode.com/svn/branches/1.4.5@8350 201d5d3c-b55e-5fd7-737f-ddc643e51545


Vulnerable code:
                    elseif (!$value || is_numeric ($value)) {
                        $value = (int) $value;
                    }

					
                    elseif(!$value || is_numeric($value)) $value = (int)$value;
                elseif (!$value || is_numeric($value))
                    $value = (int)$value;
                        elseif(!$value || is_numeric($value)) $value = (int)$value;
                        elseif(!$value || is_numeric($value)) $value = (int)$value;

Fixed code:
					// sql injection 문제로 xml 선언이 number인 경우이면서 넘어온 값이 숫자형이 아니면 숫자형으로 강제 형변환
					else $value = (int)$value;
					// sql injection 문제로 xml 선언이 number인 경우이면서 넘어온 값이 숫자형이 아니면 숫자형으로 강제 형변환
                	else $value = (int)$value;
				// sql injection 문제로 xml 선언이 number인 경우이면서 넘어온 값이 숫자형이 아니면 숫자형으로 강제 형변환
				else $value = (int)$value;
						// sql injection 문제로 xml 선언이 number인 경우이면서 넘어온 값이 숫자형이 아니면 숫자형으로 강제 형변환
						else $value = (int)$value;
						// sql injection 문제로 xml 선언이 number인 경우이면서 넘어온 값이 숫자형이 아니면 숫자형으로 강제 형변환
						else $value = (int)$value;
CVE-2019-14924 (Objective-C, published 2019-08-10T19:15Z)
Description: value: An issue was discovered in GCDWebServer before 3.5.3. The method moveItem in the GCDWebUploader class checks the FileExtension of newAbsolutePath but not oldAbsolutePath. By leveraging this vulnerability, an adversary can make an inaccessible file be available (the credential of the app, for instance).
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-863 \u2014 Incorrect Authorization
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. This allows attackers to bypass intended access restrictions.
Repository: https://github.com/swisspol/GCDWebServer
Files changed:
GCDWebDAVServer/GCDWebDAVServer.m
GCDWebUploader/GCDWebUploader.m
Commit message: Enforce hidden and extensions restrictions when moving and copying files in uploaders

Fixes #433


Vulnerable code:
  NSString* itemName = [dstAbsolutePath lastPathComponent];
  if ((!_allowHiddenItems && [itemName hasPrefix:@"."]) || (!isDirectory && ![self _checkFileExtension:itemName])) {
    return [GCDWebServerErrorResponse responseWithClientError:kGCDWebServerHTTPStatusCode_Forbidden message:@"%@ to item name \"%@\" is not allowed", isMove ? @"Moving" : @"Copying", itemName];
  NSString* itemName = [newAbsolutePath lastPathComponent];
  if ((!_allowHiddenItems && [itemName hasPrefix:@"."]) || (!isDirectory && ![self _checkFileExtension:itemName])) {
    return [GCDWebServerErrorResponse responseWithClientError:kGCDWebServerHTTPStatusCode_Forbidden message:@"Moving to item name \"%@\" is not allowed", itemName];

Fixed code:
  NSString* srcName = [srcAbsolutePath lastPathComponent];
  if ((!_allowHiddenItems && [srcName hasPrefix:@"."]) || (!isDirectory && ![self _checkFileExtension:srcName])) {
    return [GCDWebServerErrorResponse responseWithClientError:kGCDWebServerHTTPStatusCode_Forbidden message:@"%@ from item name \"%@\" is not allowed", isMove ? @"Moving" : @"Copying", srcName];
  }

  NSString* dstName = [dstAbsolutePath lastPathComponent];
  if ((!_allowHiddenItems && [dstName hasPrefix:@"."]) || (!isDirectory && ![self _checkFileExtension:dstName])) {
    return [GCDWebServerErrorResponse responseWithClientError:kGCDWebServerHTTPStatusCode_Forbidden message:@"%@ to item name \"%@\" is not allowed", isMove ? @"Moving" : @"Copying", dstName];
  NSString* oldItemName = [oldAbsolutePath lastPathComponent];
  if ((!_allowHiddenItems && [oldItemName hasPrefix:@"."]) || (!isDirectory && ![self _checkFileExtension:oldItemName])) {
    return [GCDWebServerErrorResponse responseWithClientError:kGCDWebServerHTTPStatusCode_Forbidden message:@"Moving from item name \"%@\" is not allowed", oldItemName];
  }

  NSString* newItemName = [newAbsolutePath lastPathComponent];
  if ((!_allowHiddenItems && [newItemName hasPrefix:@"."]) || (!isDirectory && ![self _checkFileExtension:newItemName])) {
    return [GCDWebServerErrorResponse responseWithClientError:kGCDWebServerHTTPStatusCode_Forbidden message:@"Moving to item name \"%@\" is not allowed", newItemName];
CVE-2015-10043 (PHP, published 2023-01-14T21:15Z)
Description: value: A vulnerability, which was classified as critical, was found in abreen Apollo. This affects an unknown part. The manipulation of the argument file leads to path traversal. The patch is named 6206406630780bbd074aff34f4683fb764faba71. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-218307.
Severity: nan (CVSS v3 base score: 8.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/abreen/Apollo
Files changed:
delete.php
download.php
view_file.php
Commit message: Patched potential file path exploit

Fixed an exploit that could have allowed users to specify file
paths elsewhere on the file system to view or delete.


Vulnerable code:

Fixed code:
// protects against attacks where '..' could be used in file path
if (basename($_GET['file']) !== $_GET['file'])
    trigger_error('invalid file path');

// protects against attacks where '..' could be used in file path
if (basename($_GET['file']) !== $_GET['file'])
    trigger_error('invalid file path');

// protects against attacks where '..' could be used in file path
if (basename($_GET['file']) !== $_GET['file'])
    trigger_error('invalid file path');
CVE-2024-34075 (Unknown, published 2024-05-03T18:15Z)
Description: value: kurwov is a fast, dependency-free library for creating Markov Chains. An unsafe sanitization of dataset contents on the `MarkovData#getNext` method used in `Markov#generate` and `Markov#choose` allows a maliciously crafted string on the dataset to throw and stop the function from running properly. If a string contains a forbidden substring (i.e. `__proto__`) followed by a space character, the code will access a special property in `MarkovData#finalData` by removing the last character of the string, bypassing the dataset sanitization (as it is supposed to be already sanitized before this function is called). Any dataset can be contaminated with the substring making it unable to properly generate anything in some cases. This issue has been addressed in version 3.2.5 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
Severity: nan (CVSS v3 base score: )
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/xiboon/kurwov
Files changed:
Commit message: Merge pull request from GHSA-hfrv-h3q8-9jpr

fix denial of service vulnerability 

Vulnerable code:

Fixed code:
CVE-2024-32030 (Java, published 2024-06-19T17:15Z)
Description: value: Kafka UI is an Open-Source Web UI for Apache Kafka Management. Kafka UI API allows users to connect to different Kafka brokers by specifying their network address and port. As a separate feature, it also provides the ability to monitor the performance of Kafka brokers by connecting to their JMX ports. JMX is based on the RMI protocol, so it is inherently susceptible to deserialization attacks. A potential attacker can exploit this feature by connecting Kafka UI backend to its own malicious broker. This vulnerability affects the deployments where one of the following occurs: 1. dynamic.config.enabled property is set in settings. It's not enabled by default, but it's suggested to be enabled in many tutorials for Kafka UI, including its own README.md. OR  2. an attacker has access to the Kafka cluster that is being connected to Kafka UI. In this scenario the attacker can exploit this vulnerability to expand their access and execute code on Kafka UI as well. Instead of setting up a legitimate JMX port, an attacker can create an RMI listener that returns a malicious serialized object for any RMI call. In the worst case it could lead to remote code execution as Kafka UI has the required gadget chains in its classpath. This issue may lead to post-auth remote code execution. This is particularly dangerous as Kafka-UI does not have authentication enabled by default. This issue has been addressed in version 0.7.2. All users are advised to upgrade. There are no known workarounds for this vulnerability. These issues were discovered and reported by the GitHub Security lab and is also tracked as GHSL-2023-230.
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/provectus/kafka-ui
Files changed:
kafka-ui-api/pom.xml
kafka-ui-api/src/main/java/com/provectus/kafka/ui/model/rbac/Permission.java
kafka-ui-api/src/main/java/com/provectus/kafka/ui/service/integration/odd/ConnectorInfo.java
kafka-ui-api/src/main/java/com/provectus/kafka/ui/service/rbac/AccessControlService.java
Commit message: added commons-collections4 library instead of commons-collections (#4427)

Co-authored-by: Narekmat <47845266+Narekmat@users.noreply.github.com>

Vulnerable code:


import org.apache.commons.collections.CollectionUtils;
import org.apache.commons.collections.CollectionUtils;
import org.apache.commons.collections.CollectionUtils;

Fixed code:
            <exclusions>
                <exclusion>
                    <groupId>commons-collections</groupId>
                    <artifactId>commons-collections</artifactId>
                </exclusion>
            </exclusions>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-collections4</artifactId>
            <version>4.4</version>
        </dependency>
import org.apache.commons.collections4.CollectionUtils;
import org.apache.commons.collections4.CollectionUtils;
import org.apache.commons.collections4.CollectionUtils;