hitoshura25/cvefixes huggingface dataset:
CVE-2020-5246 (Java, published 2020-07-14T21:15Z)
Description: value: Traccar GPS Tracking System before version 4.9 has a LDAP injection vulnerability. It occurs when user input is being used in LDAP search filter. By providing specially crafted input, an attacker can modify the logic of the LDAP query and get admin privileges. The issue only impacts instances with LDAP configuration and where users can craft their own names. This has been patched in version 4.9.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-74 \u2014 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
Repository: https://github.com/traccar/traccar
Files changed:
src/main/java/org/traccar/database/LdapProvider.java
Commit message: Encode LDAP user names


Vulnerable code:
 * Copyright 2017 Anton Tananaev (anton@traccar.org)
                String searchString = adminFilter.replace(":login", accountName);
        String searchString = searchFilter.replace(":login", accountName);

Fixed code:
 * Copyright 2017 - 2020 Anton Tananaev (anton@traccar.org)
                String searchString = adminFilter.replace(":login", encodeForLdap(accountName));
        String searchString = searchFilter.replace(":login", encodeForLdap(accountName));
    public String encodeForLdap(String input) {
        if( input == null ) {
            return null;
        }
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < input.length(); i++) {
            char c = input.charAt(i);
            switch (c) {
                case '\\':
                    sb.append("\\5c");
                    break;
                case '*':
                    sb.append("\\2a");
                    break;
                case '(':
                    sb.append("\\28");
                    break;
                case ')':
                    sb.append("\\29");
                    break;
                case '\0':
                    sb.append("\\00");
                    break;
                default:
                    sb.append(c);
            }
        }
        return sb.toString();
    }
CVE-2021-21292 (Java, published 2021-02-02T20:15Z)
Description: value: Traccar is an open source GPS tracking system. In Traccar before version 4.12 there is an unquoted Windows binary path vulnerability. Only Windows versions are impacted. Attacker needs write access to the filesystem on the host machine. If Java path includes a space, then attacker can lift their privilege to the same as Traccar service (system). This is fixed in version 4.12.
Severity: LOW (CVSS v3 base score: 6.3)
Weakness: CWE-428 \u2014 Unquoted Search Path or Element
The product uses a search path that contains an unquoted element, in which the element contains whitespace or other separators. This can cause the product to access resources in a parent path.
Repository: https://github.com/traccar/traccar
Files changed:
src/main/java/org/traccar/WindowsService.java
Commit message: Quote binary path


Vulnerable code:
 * Copyright 2018 Anton Tananaev (anton@traccar.org)
        String javaBinary = javaHome + "\\bin\\java.exe";

Fixed code:
 * Copyright 2018 - 2020 Anton Tananaev (anton@traccar.org)
        String javaBinary = "\"" + javaHome + "\\bin\\java.exe\"";
CVE-2024-24809 (Java, published 2024-04-10T15:16Z)
Description: value: Traccar is an open source GPS tracking system. Versions prior to 6.0 are vulnerable to path traversal and unrestricted upload of file with dangerous type. Since the system allows registration by default, attackers can acquire ordinary user permissions by registering an account and exploit this vulnerability to upload files with the prefix `device.` under any folder. Attackers can use this vulnerability for phishing, cross-site scripting attacks, and potentially execute arbitrary commands on the server. Version 6.0 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/traccar/traccar
Files changed:
src/main/java/org/traccar/api/resource/DeviceResource.java
Commit message: Remove extra dot


Vulnerable code:
                return ".jpg";
                return ".png";
                return ".gif";
                return ".webp";
                return ".svg";

Fixed code:
                return "jpg";
                return "png";
                return "gif";
                return "webp";
                return "svg";
CVE-2024-31214 (Java, published 2024-04-10T18:15Z)
Description: value: Traccar is an open source GPS tracking system. Traccar versions 5.1 through 5.12 allow arbitrary files to be uploaded through the device image upload API. Attackers have full control over the file contents, full control over the directory where the file is stored, full control over the file extension, and partial control over the file name. While it's not  for an attacker to overwrite an existing file, an attacker can create new files with certain names and attacker-controlled extensions anywhere on the file system. This can potentially lead to remote code execution, XSS, DOS, etc. The default install of Traccar makes this vulnerability more severe. Self-registration is enabled by default, allowing anyone to create an account to exploit this vulnerability. Traccar also runs by default with root/system privileges, allowing files to be placed anywhere on the file system. Version 6.0 contains a fix for the issue. One may also turn off self-registration by default, as that would make most vulnerabilities in the application much harder to exploit by default and reduce the severity considerably.

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/traccar/traccar
Files changed:
src/main/java/org/traccar/model/Device.java
Commit message: Update device id check


Vulnerable code:
        if (uniqueId.contains("../") || uniqueId.contains("..\\")) {

Fixed code:
        if (uniqueId.contains("..")) {
CVE-2013-10005 (Go, published 2022-12-27T22:15Z)
Description: value: The RemoteAddr and LocalAddr methods on the returned net.Conn may call themselves, leading to an infinite loop which will crash the program due to a stack overflow.
Severity: nan (CVSS v3 base score: 7.5)
Weakness: CWE-835 \u2014 Loop with Unreachable Exit Condition ('Infinite Loop')
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
Repository: https://github.com/btcsuite/go-socks
Files changed:
conn.go
Commit message: fix potential infinite loops in both LocalAddr and RemoteAddr


Vulnerable code:
	return c.LocalAddr()
	return c.RemoteAddr()

Fixed code:
	return c.conn.LocalAddr()
	return c.conn.RemoteAddr()
CVE-2012-5648 (Ruby, published 2014-04-04T14:55Z)
Description: value: Multiple SQL injection vulnerabilities in Foreman before 1.0.2 allow remote attackers to execute arbitrary SQL commands via unspecified parameters to (1) app/models/hostext/search.rb or (2) app/models/puppetclass.rb, related to the search mechanism.
Severity: HIGH (CVSS v3 base score: )
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/theforeman/foreman
Files changed:
app/models/hostext/search.rb
app/models/puppetclass.rb
Commit message: Fix Foreman SQL injection through search mechanism CVE-2012-5648


Vulnerable code:
          users = User.all(:conditions => "#{key_name} #{operator} '#{value_to_sql(operator, value)}'")
          opts  = hosts.empty? ? "= 'nil'" : "IN (#{hosts.map(&:id).join(',')})"
          conditions  = "puppetclasses.name #{operator} '#{value_to_sql(operator, value)}'"
          opts     = {:conditions => "name = '#{key_name}' and value #{operator} '#{value_to_sql(operator, value)}'", :order => :priority}
          negate_opts = {:conditions => "name = '#{key_name}' and NOT(value #{operator} '#{value_to_sql(operator, value)}') and priority > #{max}", :order => :priority}
    conditions = "hosts.name #{operator} '#{value_to_sql(operator, value)}'"
    direct     = Puppetclass.all(:conditions => conditions, :joins => :hosts, :select => 'puppetclasses.id').map(&:id).uniq

Fixed code:
          condition = sanitize_sql_for_conditions(["? #{operator} ?", key_name, value_to_sql(operator, value)])
          users = User.all(:conditions => condition)
          opts  = hosts.empty? ? "< 0" : "IN (#{hosts.map(&:id).join(',')})"
          conditions  = sanitize_sql_for_conditions(["puppetclasses.name #{operator} ?", value_to_sql(operator, value)])
          condition = sanitize_sql_for_conditions(["name = ? and value #{operator} ?", key_name, value_to_sql(operator, value)])
          opts     = {:conditions => condition, :order => :priority}
          condition   = sanitize_sql_for_conditions(["name = ? and NOT(value #{operator} ?) and priority > ?",key_name,value_to_sql(operator, value), max])
          negate_opts = {:conditions => condition, :order => :priority}
    conditions = sanitize_sql_for_conditions(["hosts.name #{operator} ?", value_to_sql(operator, value)])
    direct     = Puppetclass.joins(:hosts).where(conditions).select('puppetclasses.id').map(&:id).uniq
CVE-2015-5282 (JavaScript, published 2017-09-25T17:29Z)
Description: value: Cross-site scripting (XSS) vulnerability in Foreman 1.7.0 and after.
Severity: MEDIUM (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/theforeman/foreman
Files changed:
app/assets/javascripts/hidden_values.js
Commit message: Fixes #11859 - handle HTML in parameters safely when hiding values (CVE-2015-5282)


Vulnerable code:
    target = '<input class="form-control" type="password" id="' + id + '" name="' + source.name + '" value ="' + source.value + '"></input>'
    target = '<textarea class="form-control editor_source hide" id="' + id + '" name="' + source.name + '" placeholder="Value" rows="1">' + source.value + '</textarea>'
    var target = '<textarea class="form-control" id="' + id + '" name="' + source.name + '" placeholder="Value" rows="1">' + source.value + '</textarea>'

Fixed code:
    target = $('<input/>').attr({ type: 'password', id: id, name: source.name, value: $(source).val(), class: 'form-control'});
    target = $('<textarea/>').attr({class: 'form-control editor_source hide', id: id, name: source.name, placeholder: 'Value', rows: 1, value: $(source).val()});
    var target = $('<textarea/>').attr({class: 'form-control', id: id, name: source.name, placeholder: 'Value', rows: 1, value: $(source).val()});
CVE-2016-3693 (Other, published 2016-05-20T14:59Z)
Description: value: The Safemode gem before 1.2.4 for Ruby, when initialized with a delegate object that is a Rails controller, allows context-dependent attackers to obtain sensitive information via the inspect method.
Severity: MEDIUM (CVSS v3 base score: 8.1)
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/theforeman/foreman
Files changed:
Gemfile
Commit message: Fixes #14635 - bump safemode version to fix the unwanted inspect issue


Vulnerable code:
gem 'safemode', '~> 1.2'

Fixed code:
gem 'safemode', '~> 1.2', '>= 1.2.4'
CVE-2016-3693 (Other, published 2016-05-20T14:59Z)
Description: value: The Safemode gem before 1.2.4 for Ruby, when initialized with a delegate object that is a Rails controller, allows context-dependent attackers to obtain sensitive information via the inspect method.
Severity: MEDIUM (CVSS v3 base score: 8.1)
Weakness: CWE-264 \u2014 Permissions, Privileges, and Access Controls
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.
Repository: https://github.com/theforeman/foreman
Files changed:
Gemfile
Commit message: Fixes #14635 - bump safemode version to fix the unwanted inspect issue


Vulnerable code:
gem 'safemode', '~> 1.2'

Fixed code:
gem 'safemode', '~> 1.2', '>= 1.2.4'
CVE-2016-6319 (Ruby, published 2016-08-19T21:59Z)
Description: value: Cross-site scripting (XSS) vulnerability in app/helpers/form_helper.rb in Foreman before 1.12.2, as used by Remote Execution and possibly other plugins, allows remote attackers to inject arbitrary web script or HTML via the label parameter.
Severity: MEDIUM (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/theforeman/foreman
Files changed:
app/helpers/form_helper.rb
Commit message: Fixes #16024 - escape labels of form fields


Vulnerable code:
    label = label.present? ? label_tag(attr, "#{label}#{required_mark}".html_safe, :class => label_size + " control-label") : ''

Fixed code:
    label = label.present? ? label_tag(attr, "#{label}#{required_mark}", :class => label_size + " control-label") : ''
CVE-2019-16786 (Unknown, published 2019-12-20T23:15Z)
Description: value: Waitress through version 1.3.1 would parse the Transfer-Encoding header and only look for a single string value, if that value was not chunked it would fall through and use the Content-Length header instead. According to the HTTP standard Transfer-Encoding should be a comma separated list, with the inner-most encoding first, followed by any further transfer codings, ending with chunked. Requests sent with: "Transfer-Encoding: gzip, chunked" would incorrectly get ignored, and the request would use a Content-Length header instead to determine the body size of the HTTP message. This could allow for Waitress to treat a single request as multiple requests in the case of HTTP pipelining. This issue is fixed in Waitress 1.4.0.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-444 \u2014 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
The product acts as an intermediary HTTP agent
         (such as a proxy or firewall) in the data flow between two
         entities such as a client and server, but it does not
         interpret malformed HTTP requests or responses in ways that
         are consistent with how the messages will be processed by
         those entities that are at the ultimate destination.
Repository: https://github.com/Pylons/waitress
Files changed:
Commit message: Merge pull request from GHSA-g2xc-35jw-c63p

HTTP Request Smuggling Fixes

Vulnerable code:

Fixed code:
CVE-2019-16789 (Unknown, published 2019-12-26T17:15Z)
Description: value: In Waitress through version 1.4.0, if a proxy server is used in front of waitress, an invalid request may be sent by an attacker that bypasses the front-end and is parsed differently by waitress leading to a potential for HTTP request smuggling. Specially crafted requests containing special whitespace characters in the Transfer-Encoding header would get parsed by Waitress as being a chunked request, but a front-end server would use the Content-Length instead as the Transfer-Encoding header is considered invalid due to containing invalid characters. If a front-end server does HTTP pipelining to a backend Waitress server this could lead to HTTP request splitting which may lead to potential cache poisoning or unexpected information disclosure. This issue is fixed in Waitress 1.4.1 through more strict HTTP field validation.
Severity: MEDIUM (CVSS v3 base score: 8.2)
Weakness: CWE-444 \u2014 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
The product acts as an intermediary HTTP agent
         (such as a proxy or firewall) in the data flow between two
         entities such as a client and server, but it does not
         interpret malformed HTTP requests or responses in ways that
         are consistent with how the messages will be processed by
         those entities that are at the ultimate destination.
Repository: https://github.com/Pylons/waitress
Files changed:
Commit message: Merge pull request from GHSA-m5ff-3wj3-8ph4

HTTP header-field stricter validation

Vulnerable code:

Fixed code:
CVE-2019-16792 (Python, published 2020-01-22T19:15Z)
Description: value: Waitress through version 1.3.1 allows request smuggling by sending the Content-Length header twice. Waitress would header fold a double Content-Length header and due to being unable to cast the now comma separated value to an integer would set the Content-Length to 0 internally. If two Content-Length headers are sent in a single request, Waitress would treat the request as having no body, thereby treating the body of the request as a new request in HTTP pipelining. This issue is fixed in Waitress 1.4.0.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-444 \u2014 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
The product acts as an intermediary HTTP agent
         (such as a proxy or firewall) in the data flow between two
         entities such as a client and server, but it does not
         interpret malformed HTTP requests or responses in ways that
         are consistent with how the messages will be processed by
         those entities that are at the ultimate destination.
Repository: https://github.com/Pylons/waitress
Files changed:
waitress/parser.py
waitress/tests/test_parser.py
Commit message: Upon receiving invalid Content-Length bail

Instead of attempting to continue processing the request, we instead
raise a ParsingError and return a HTTP Bad Request to the client.

This also catches the case where two Content-Length's are sent, and are
folded together using HTTP header folding.


Vulnerable code:
                cl = 0
        self.parser.parse_header(data)
        self.assertEqual(self.parser.body_rcv, None)

Fixed code:
                raise ParsingError("Content-Length is invalid")

        from waitress.parser import ParsingError


        try:
            self.parser.parse_header(data)
        except ParsingError as e:
            self.assertIn("Content-Length is invalid", e.args[0])
        else:  # pragma: nocover
            self.assertTrue(False)

    def test_parse_header_multiple_content_length(self):
        from waitress.parser import ParsingError

        data = b"GET /foobar HTTP/8.4\r\ncontent-length: 10\r\ncontent-length: 20\r\n"

        try:
            self.parser.parse_header(data)
        except ParsingError as e:
            self.assertIn("Content-Length is invalid", e.args[0])
        else:  # pragma: nocover
            self.assertTrue(False)
CVE-2020-5236 (Unknown, published 2020-02-04T03:15Z)
Description: value: Waitress version 1.4.2 allows a DOS attack When waitress receives a header that contains invalid characters. When a header like "Bad-header: xxxxxxxxxxxxxxx\x10" is received, it will cause the regular expression engine to catastrophically backtrack causing the process to use 100% CPU time and blocking any other interactions. This allows an attacker to send a single request with an invalid header and take the service offline. This issue was introduced in version 1.4.2 when the regular expression was updated to attempt to match the behaviour required by errata associated with RFC7230. The regular expression that is used to validate incoming headers has been updated in version 1.4.3, it is recommended that people upgrade to the new version of Waitress as soon as possible.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-400 \u2014 Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.
Repository: https://github.com/Pylons/waitress
Files changed:
Commit message: Merge pull request from GHSA-73m2-3pwg-5fgc

Fix catastrophic backtracking in regular expression

Vulnerable code:

Fixed code:
CVE-2022-24761 (Unknown, published 2022-03-17T13:15Z)
Description: value: Waitress is a Web Server Gateway Interface server for Python 2 and 3. When using Waitress versions 2.1.0 and prior behind a proxy that does not properly validate the incoming HTTP request matches the RFC7230 standard, Waitress and the frontend proxy may disagree on where one request starts and where it ends. This would allow requests to be smuggled via the front-end proxy to waitress and later behavior. There are two classes of vulnerability that may lead to request smuggling that are addressed by this advisory: The use of Python's `int()` to parse strings into integers, leading to `+10` to be parsed as `10`, or `0x01` to be parsed as `1`, where as the standard specifies that the string should contain only digits or hex digits; and Waitress does not support chunk extensions, however it was discarding them without validating that they did not contain illegal characters. This vulnerability has been patched in Waitress 2.1.1. A workaround is available. When deploying a proxy in front of waitress, turning on any and all functionality to make sure that the request matches the RFC7230 standard. Certain proxy servers may not have this functionality though and users are encouraged to upgrade to the latest version of waitress instead.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-444 \u2014 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
The product acts as an intermediary HTTP agent
         (such as a proxy or firewall) in the data flow between two
         entities such as a client and server, but it does not
         interpret malformed HTTP requests or responses in ways that
         are consistent with how the messages will be processed by
         those entities that are at the ultimate destination.
Repository: https://github.com/Pylons/waitress
Files changed:
Commit message: Merge pull request from GHSA-4f7p-27jc-3c36

Fix for HTTP request smuggling due to incorrect validation

Vulnerable code:

Fixed code: