hitoshura25/cvefixes huggingface dataset:
CVE-2014-3148 (Other, published 2015-08-31T18:59Z)
Description: value: Cross-site scripting (XSS) vulnerability in libahttp/err.c in OkCupid OKWS (OK Web Server) allows remote attackers to inject arbitrary web script or HTML via the PATH_INFO to a non-existent page, which is not properly handled in a 404 error page.
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/okws/okws
Files changed:
libahttp/err.C
Commit message: Escape error page content

Credit to Kenneth F. Belva (https://twitter.com/infosecmaverick)
https://hackerone.com/reports/3317


Vulnerable code:
  const str sdesc = http_status.get_desc (n, &ldesc);
    b << "The file <tt>" << aux 
    << "  <i>" << si << "</i>\n"

Fixed code:
#include "pescape.h"
  const str sdesc = xss_escape (http_status.get_desc (n, &ldesc));
    b << "The file <tt>" << xss_escape (aux)
    << "  <i>" << xss_escape (si) << "</i>\n"
CVE-2019-11924 (C++, published 2019-08-20T20:15Z)
Description: value: A peer could send empty handshake fragments containing only padding which would be kept in memory until a full handshake was received, resulting in memory exhaustion. This issue affects versions v2019.01.28.00 and above of fizz, until v2019.08.05.00.
Severity: HIGH (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/facebookincubator/fizz
Files changed:
fizz/record/EncryptedRecordLayer.cpp
fizz/record/RecordLayer.cpp
Commit message: Coalesce handshake buffers

Summary:
It is possible that a peer might send us records in a manner such
that there is a 16KB record and only 1 byte of handshake message in
each record. Since we normally just trim the IOBuf, we would end up
holding 16K of data per actual byte of data. To prevent this we allocate a contiguous
buffer to copy over these bytes for handshake messages for now.

This is a partial fix for CVE-2019-11924

Reviewed By: ngoyal

Differential Revision: D16478044

fbshipit-source-id: 464bc68eaefda065d9a327818100427377293fbd


Vulnerable code:
  TLSMessage msg;
        unparsedHandshakeData_.append(std::move(message->fragment));

Fixed code:
  TLSMessage msg{};
        std::unique_ptr<folly::IOBuf> handshakeMessage =
            unparsedHandshakeData_.move();
        // It is possible that a peer might send us records in a manner such
        // that there is a 16KB record and only 1 byte of handshake message in
        // each record. Since we normally just trim the IOBuf, we would end up
        // holding 16K of data. To prevent this we allocate a contiguous
        // buffer to copy over these bytes. We supply kExtraAlloc bytes in
        // order to avoid needing to re-allocate a lot of times if we receive
        // a lot of small messages. There might be more optimal reallocation
        // policies, but this should be fine.
        message->fragment->coalesce();
        constexpr size_t kExtraAlloc = 1024;
        if (!handshakeMessage) {
          handshakeMessage =
              folly::IOBuf::create(message->fragment->length() + kExtraAlloc);
        } else if (handshakeMessage->tailroom() < message->fragment->length()) {
          handshakeMessage->reserve(
              0, message->fragment->length() + kExtraAlloc);
        }
        memcpy(
            handshakeMessage->writableTail(),
            message->fragment->data(),
            message->fragment->length());
        handshakeMessage->append(message->fragment->length());
        unparsedHandshakeData_.append(std::move(handshakeMessage));
CVE-2019-11924 (C++, published 2019-08-20T20:15Z)
Description: value: A peer could send empty handshake fragments containing only padding which would be kept in memory until a full handshake was received, resulting in memory exhaustion. This issue affects versions v2019.01.28.00 and above of fizz, until v2019.08.05.00.
Severity: HIGH (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/facebookincubator/fizz
Files changed:
fizz/record/EncryptedRecordLayer.cpp
fizz/record/test/EncryptedRecordTest.cpp
Commit message: Reject zero length handshake records.

Summary:
Zero length (all padding) handshake are forbidden by RFC. Allowing
these was a regression in D13754697 (2c6f78a).

This is a partial fix for CVE-2019-11924

Reviewed By: xybu

Differential Revision: D16285100

fbshipit-source-id: 05a19d31ad74601ce89156a0e59517aaad8dd928


Vulnerable code:
  if (!msg.fragment) {
  EXPECT_NO_THROW(read_.read(queue_));

Fixed code:
  if (!msg.fragment || msg.fragment->empty()) {
  EXPECT_ANY_THROW(read_.read(queue_));
CVE-2019-3560 (C++, published 2019-04-29T16:29Z)
Description: value: An improperly performed length calculation on a buffer in PlaintextRecordLayer could lead to an infinite loop and denial-of-service based on user input. This issue affected versions of fizz prior to v2019.03.04.00.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-131 \u2014 Incorrect Calculation of Buffer Size
The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
Repository: https://github.com/facebookincubator/fizz
Files changed:
fizz/record/PlaintextRecordLayer.cpp
fizz/record/test/PlaintextRecordTest.cpp
Commit message: Avoid arithmetic operation on uint16 read from the wire.

Summary:
This could overflow previously.

CVE-2019-3560

Reviewed By: yfeldblum

Differential Revision: D14152362

fbshipit-source-id: c0ebb3fc59b49c7c23e6bcb90458c19cd891be65


Vulnerable code:
        length +=
            sizeof(ContentType) + sizeof(ProtocolVersion) + sizeof(uint16_t);
        buf.trimStart(length);

Fixed code:
        buf.trimStart(static_cast<size_t>(kPlaintextHeaderSize) + length);
TEST_F(PlaintextRecordTest, TestSkipOversizedRecord) {
  read_.setSkipEncryptedRecords(true);
  addToQueue("170301fffb");
  auto longBuf = IOBuf::create(0xfffb);
  longBuf->append(0xfffb);
  queue_.append(std::move(longBuf));
  EXPECT_FALSE(read_.read(queue_).hasValue());
  EXPECT_TRUE(queue_.empty());
}
CVE-2019-3560 (C++, published 2019-04-29T16:29Z)
Description: value: An improperly performed length calculation on a buffer in PlaintextRecordLayer could lead to an infinite loop and denial-of-service based on user input. This issue affected versions of fizz prior to v2019.03.04.00.
Severity: MEDIUM (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/facebookincubator/fizz
Files changed:
fizz/record/PlaintextRecordLayer.cpp
fizz/record/test/PlaintextRecordTest.cpp
Commit message: Avoid arithmetic operation on uint16 read from the wire.

Summary:
This could overflow previously.

CVE-2019-3560

Reviewed By: yfeldblum

Differential Revision: D14152362

fbshipit-source-id: c0ebb3fc59b49c7c23e6bcb90458c19cd891be65


Vulnerable code:
        length +=
            sizeof(ContentType) + sizeof(ProtocolVersion) + sizeof(uint16_t);
        buf.trimStart(length);

Fixed code:
        buf.trimStart(static_cast<size_t>(kPlaintextHeaderSize) + length);
TEST_F(PlaintextRecordTest, TestSkipOversizedRecord) {
  read_.setSkipEncryptedRecords(true);
  addToQueue("170301fffb");
  auto longBuf = IOBuf::create(0xfffb);
  longBuf->append(0xfffb);
  queue_.append(std::move(longBuf));
  EXPECT_FALSE(read_.read(queue_).hasValue());
  EXPECT_TRUE(queue_.empty());
}
CVE-2023-23759 (C++, published 2023-05-18T22:15Z)
Description: value: There is a vulnerability in the fizz library prior to v2023.01.30.00 where a CHECK failure can be triggered remotely. This behavior requires the client supported cipher advertisement changing between the original ClientHello and the second ClientHello, crashing the process (impact is limited to denial of service).
Severity: nan (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/facebookincubator/fizz
Files changed:
fizz/server/ServerProtocol.cpp
Commit message: Check HelloRetryRequest cipher consistency earlier.

CVE-2023-23759

Co-authored-by: Facebook Community Bot <6422482+facebook-github-bot@users.noreply.github.com>

Differential Revision: D42508182

Vulnerable code:
        if (state.cipher().has_value() && cipher != *state.cipher()) {
          throw FizzException(
              "cipher mismatch with previous negotiation",
              AlertDescription::illegal_parameter);
        }


Fixed code:
  if (state.cipher().has_value() && cipher != *state.cipher()) {
    throw FizzException(
        "cipher mismatch with previous negotiation",
        AlertDescription::illegal_parameter);
  }
CVE-2020-35132 (PHP, published 2020-12-11T05:15Z)
Description: value: An XSS issue has been discovered in phpLDAPadmin before 1.2.6.2 that allows users to store malicious values that may be executed by other users at a later time via get_request in lib/function.php.
Severity: LOW (CVSS v3 base score: 5.4)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
Repository: https://github.com/leenooks/phpLDAPadmin
Files changed:
lib/functions.php
Commit message: Fix error and set by default to preventXSS

Vulnerable code:
function get_request($attr,$type='POST',$die=false,$default=null,$preventXSS=false) {
				basename($_SERVER['PHP_SELF']),get_request('cmd','REQUEST',false,null,true),preventXSS($attr),preventXSS($type)),
function preventXSS($value){
	return htmlspecialchars(addslashes($value), ENT_QUOTES, 'UTF-8');
}


Fixed code:
function get_request($attr,$type='POST',$die=false,$default=null,$preventXSS=true) {
				basename($_SERVER['PHP_SELF']),get_request('cmd','REQUEST'),preventXSS($attr),preventXSS($type)),
 function preventXSS($data){
        if (gettype($data) == 'array') {
            foreach ($data as $key => $value) {
                if (gettype($value) == 'array')
                    $data[$key] = preventXSS($value);
                else
                    $data[$key] = htmlspecialchars($value);
            }
            return $data;
        }
        return htmlspecialchars($data, ENT_QUOTES, 'UTF-8');
}

/*
CVE-2024-33531 (Unknown, published 2024-04-24T06:15Z)
Description: value: cdbattags lua-resty-jwt 0.2.3 allows attackers to bypass all JWT-parsing signature checks by crafting a JWT with an enc header with the value A256GCM.
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/cdbattags/lua-resty-jwt
Files changed:
Commit message: Merge pull request #62 from nemmerich/master

Fix authentication bypass

Vulnerable code:

Fixed code:
CVE-2017-15132 (C, published 2018-01-25T20:29Z)
Description: value: A flaw was found in dovecot 2.0 up to 2.2.33 and 2.3.0. An abort of SASL authentication results in a memory leak in dovecot's auth client used by login processes. The leak has impact in high performance configuration where same login processes are reused and can cause the process to crash due to memory exhaustion.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-772 \u2014 Missing Release of Resource after Effective Lifetime
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
Repository: https://github.com/dovecot/core
Files changed:
src/lib-auth/auth-client-request.c
Commit message: lib-auth: Fix memory leak in auth_client_request_abort()

This caused memory leaks when authentication was aborted. For example
with IMAP:

a AUTHENTICATE PLAIN
*

Broken by 9137c55411aa39d41c1e705ddc34d5bd26c65021


Vulnerable code:

Fixed code:
	pool_unref(&request->pool);
CVE-2017-2669 (C, published 2018-06-21T13:29Z)
Description: value: Dovecot before version 2.2.29 is vulnerable to a denial of service. When 'dict' passdb and userdb were used for user authentication, the username sent by the IMAP/POP3 client was sent through var_expand() to perform %variable expansion. Sending specially crafted %variable fields could result in excessive memory usage causing the process to crash (and restart), or excessive CPU usage causing all authentications to hang.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-20 \u2014 Improper Input Validation
The product receives input or data, but it does
        not validate or incorrectly validates that the input has the
        properties that are required to process the data safely and
        correctly.
Repository: https://github.com/dovecot/core
Files changed:
src/auth/db-dict.c
Commit message: auth: Do not double-expand key in passdb dict when authenticating

Broken by 79042f8c


Vulnerable code:
		ret = var_expand(path, key->key->key, iter->var_expand_table, &error);
		if (ret <= 0) {
			auth_request_log_error(iter->auth_request, AUTH_SUBSYS_DB,
				"Failed to expand key %s: %s", key->key->key, error);
			return -1;
		}

Fixed code:
		str_append(path, key->key->key);
CVE-2022-21144 (JavaScript, published 2022-05-01T16:15Z)
Description: value: This affects all versions of package libxmljs. When invoking the libxmljs.parseXml function with a non-buffer argument the V8 code will attempt invoking the .toString method of the argument. If the argument's toString value is not a Function object V8 will crash.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-20 \u2014 Improper Input Validation
The product receives input or data, but it does
        not validate or incorrectly validates that the input has the
        properties that are required to process the data safely and
        correctly.
Repository: https://github.com/libxmljs/libxmljs
Files changed:
package.json
src/xml_document.cc
test/html_parser.js
test/xml_parser.js
Commit message: Ensure parseXml/parseHtml input is string or buffer (#594)



Vulnerable code:
  "version": "0.19.7",
}
    if (!node::Buffer::HasInstance(info[0])) {
    else {
    if (!node::Buffer::HasInstance(info[0])) {
    else {

Fixed code:
  "version": "0.19.8",
}
    if (info[0]->IsString()) {
    else if (node::Buffer::HasInstance(info[0])) {
    } else {
        return Nan::ThrowError("XML must be a string or buffer");
    if (info[0]->IsString()) {
    else if (node::Buffer::HasInstance(info[0])) {
    } else {
        return Nan::ThrowError("XML must be a string or buffer");
module.exports.invalid_input = function(assert) {
    try {
        libxml.parseHtml({object: true});
        assert.ok(false);
    } catch(err) {
        assert.ok(true)
    }

    assert.done();
};

module.exports.invalid_input = function(assert) {
    try {
        libxml.parseXml({object: true});
        assert.ok(false);
    } catch(err) {
        assert.ok(true)
    }

    assert.done();
};
CVE-2014-4172 (Java, published 2020-01-24T19:15Z)
Description: value: A URL parameter injection vulnerability was found in the back-channel ticket validation step of the CAS protocol in Jasig Java CAS Client before 3.3.2, .NET CAS Client before 1.0.2, and phpCAS before 1.3.3 that allow remote attackers to inject arbitrary web script or HTML via the (1) service parameter to validation/AbstractUrlBasedTicketValidator.java or (2) pgtUrl parameter to validation/Cas20ServiceTicketValidator.java.
Severity: HIGH (CVSS v3 base score: 9.8)
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/Jasig/java-cas-client
Files changed:
cas-client-core/src/main/java/org/jasig/cas/client/validation/AbstractUrlBasedTicketValidator.java
cas-client-core/src/main/java/org/jasig/cas/client/validation/Cas20ServiceTicketValidator.java
cas-client-core/src/test/java/org/jasig/cas/client/validation/Cas10TicketValidatorTests.java
Commit message: CASC-228 URL Encode Paramaters Passed to Server via Validate

Problem: We currently don't pass encoded values to the server, possibly resolving in parsing/extraction errors.
Solution: URL Encode all values instead of just the service url.

QA Notes: Added unit test.


Vulnerable code:
        urlParameters.put("service", encodeUrl(serviceUrl));
                buffer.append(value);
        urlParameters.put("pgtUrl", encodeUrl(this.proxyCallbackUrl));
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.fail;

Fixed code:
        urlParameters.put("service", serviceUrl);
                final String encodedValue = encodeUrl(value);
                buffer.append(encodedValue);
        urlParameters.put("pgtUrl", this.proxyCallbackUrl);
import static org.junit.Assert.*;

    @Test
    public void urlEncodedValues() {
        final String ticket = "ST-1-owKEOtYJjg77iHcCQpkl-cas01.example.org%26%73%65%72%76%69%63%65%3d%68%74%74%70%25%33%41%25%32%46%25%32%46%31%32%37%2e%30%2e%30%2e%31%25%32%46%62%6f%72%69%6e%67%25%32%46%23";
        final String service = "foobar";
        final String url = this.ticketValidator.constructValidationUrl(ticket, service);

        final String encodedValue = this.ticketValidator.encodeUrl(ticket);
        assertTrue(url.contains(encodedValue));
        assertFalse(url.contains(ticket));
    }
CVE-2023-28119 (Go, published 2023-03-22T20:15Z)
Description: value: The crewjam/saml go library contains a partial implementation of the SAML standard in golang. Prior to version 0.4.13, the package's use of `flate.NewReader` does not limit the size of the input. The user can pass more than 1 MB of data in the HTTP request to the processing functions, which will be decompressed server-side using the Deflate algorithm. Therefore, after repeating the same request multiple times, it is possible to achieve a reliable crash since the operating system kills the process. This issue is patched in version 0.4.13.

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/crewjam/saml
Files changed:
flate.go
identity_provider.go
identity_provider_test.go
service_provider.go
Commit message: Merge pull request from GHSA-5mqj-xc49-246p

https://github.com/crewjam/saml/security/advisories/GHSA-5mqj-xc49-246p

Vulnerable code:
	"compress/flate"
		req.RequestBuffer, err = ioutil.ReadAll(flate.NewReader(bytes.NewReader(compressedRequest)))
	gr, err := ioutil.ReadAll(flate.NewReader(bytes.NewBuffer(rawResponseBuf)))

Fixed code:
package saml

import (
	"compress/flate"
	"fmt"
	"io"
)

const flateUncompressLimit = 10 * 1024 * 1024 // 10MB

func newSaferFlateReader(r io.Reader) io.ReadCloser {
	return &saferFlateReader{r: flate.NewReader(r)}
}

type saferFlateReader struct {
	r     io.ReadCloser
	count int
}

func (r *saferFlateReader) Read(p []byte) (n int, err error) {
	if r.count+len(p) > flateUncompressLimit {
		return 0, fmt.Errorf("flate: uncompress limit exceeded (%d bytes)", flateUncompressLimit)
	}
	n, err = r.r.Read(p)
	r.count += n
	return n, err
}

func (r *saferFlateReader) Close() error {
	return r.r.Close()
}
		req.RequestBuffer, err = ioutil.ReadAll(newSaferFlateReader(bytes.NewReader(compressedRequest)))
	"bytes"
	"compress/flate"

func TestIDPRejectDecompressionBomb(t *testing.T) {
	test := NewIdentifyProviderTest(t)
	test.IDP.SessionProvider = &mockSessionProvider{
		GetSessionFunc: func(w http.ResponseWriter, r *http.Request, req *IdpAuthnRequest) *Session {
			fmt.Fprintf(w, "RelayState: %s\nSAMLRequest: %s",
				req.RelayState, req.RequestBuffer)
			return nil
		},
	}

	//w := httptest.NewRecorder()

	data := bytes.Repeat([]byte("a"), 768*1024*1024)
	var compressed bytes.Buffer
	w, _ := flate.NewWriter(&compressed, flate.BestCompression)
	w.Write(data)
	w.Close()
	encoded := base64.StdEncoding.EncodeToString(compressed.Bytes())

	r, _ := http.NewRequest("GET", "/dontcare?"+url.Values{
		"SAMLRequest": {encoded},
	}.Encode(), nil)
	_, err := NewIdpAuthnRequest(&test.IDP, r)
	assert.Error(t, err, "cannot decompress request: flate: uncompress limit exceeded (10485760 bytes)")
}
	gr, err := ioutil.ReadAll(newSaferFlateReader(bytes.NewBuffer(rawResponseBuf)))
CVE-2021-43572 (Python, published 2021-11-09T22:15Z)
Description: value: The verify function in the Stark Bank Python ECDSA library (aka starkbank-escada or ecdsa-python) before 2.0.1 fails to check that the signature is non-zero, which allows attackers to forge signatures on arbitrary messages.
Severity: HIGH (CVSS v3 base score: 9.8)
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/starkbank/ecdsa-python
Files changed:
CHANGELOG.md
ellipticcurve/__init__.py
ellipticcurve/ecdsa.py
Commit message: Add signature.r and signature.s range check


Vulnerable code:
from ellipticcurve.utils.compatibility import *
from ellipticcurve.privateKey import PrivateKey
from ellipticcurve.publicKey import PublicKey
from ellipticcurve.signature import Signature
from ellipticcurve.utils.file import File
from ellipticcurve.ecdsa import Ecdsa

Fixed code:
### Fixed
- Signature r and s range check
from .utils.compatibility import *
from .privateKey import PrivateKey
from .publicKey import PublicKey
from .signature import Signature
from .utils.file import File
from .ecdsa import Ecdsa
        if not 1 <= r <= curve.N - 1:
            return False
        if not 1 <= s <= curve.N - 1:
            return False