hitoshura25/cvefixes huggingface dataset:
CVE-2024-28182 (C, published 2024-04-04T15:15Z)
Description: value: nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. The nghttp2 library prior to version 1.61.0 keeps reading the unbounded number of HTTP/2 CONTINUATION frames even after a stream is reset to keep HPACK context in sync.  This causes excessive CPU usage to decode HPACK stream. nghttp2 v1.61.0 mitigates this vulnerability by limiting the number of CONTINUATION frames it accepts per stream. There is no workaround 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/nghttp2/nghttp2
Files changed:
doc/Makefile.am
lib/includes/nghttp2/nghttp2.h
lib/nghttp2_option.c
lib/nghttp2_option.h
lib/nghttp2_session.c
Commit message: Add nghttp2_option_set_max_continuations


Vulnerable code:

Fixed code:
	nghttp2_option_set_max_continuations.rst \
/**
 * @function
 *
 * This function sets the maximum number of CONTINUATION frames
 * following an incoming HEADER frame.  If more than those frames are
 * received, the remote endpoint is considered to be misbehaving and
 * session will be closed.  The default value is 8.
 */
NGHTTP2_EXTERN void nghttp2_option_set_max_continuations(nghttp2_option *option,
                                                         size_t val);


void nghttp2_option_set_max_continuations(nghttp2_option *option, size_t val) {
  option->opt_set_mask |= NGHTTP2_OPT_MAX_CONTINUATIONS;
  option->max_continuations = val;
}
  NGHTTP2_OPT_MAX_CONTINUATIONS = 1 << 16,
  /**
   * NGHTTP2_OPT_MAX_CONTINUATIONS
   */
  size_t max_continuations;

    if (option->opt_set_mask & NGHTTP2_OPT_MAX_CONTINUATIONS) {
      (*session_ptr)->max_continuations = option->max_continuations;
    }
CVE-2021-43840 (Ruby, published 2021-12-17T19:15Z)
Description: value: message_bus is a messaging bus for Ruby processes and web clients. In versions prior to 3.3.7 users who deployed message bus with diagnostics features enabled (default off) are vulnerable to a path traversal bug, which could lead to disclosure of secret information on a machine if an unintended user were to gain access to the diagnostic route. The impact is also greater if there is no proxy for your web application as the number of steps up the directories is not bounded. For deployments which uses a proxy, the impact varies. For example, If a request goes through a proxy like Nginx with `merge_slashes` enabled, the number of steps up the directories that can be read is limited to 3 levels. This issue has been patched in version 3.3.7. Users unable to upgrade should ensure that MessageBus::Diagnostics is disabled.
Severity: LOW (CVSS v3 base score: 6.5)
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/discourse/message_bus
Files changed:
CHANGELOG
lib/message_bus/rack/diagnostics.rb
spec/lib/message_bus/rack/middleware_spec.rb
Commit message: SECURITY: Fix path traversal on diagnostics route.


Vulnerable code:
    if asset && !asset !~ /\//
          #{js_asset "jquery-1.8.2.js"}
          #{js_asset "react.js"}
          #{js_asset "react-dom.js"}
          #{js_asset "babel.min.js"}
          #{js_asset "message-bus.js"}
          #{js_asset "application.jsx", "text/jsx"}
    it "should return a 403 if a user attempts to get at the _diagnostics path" do



Fixed code:
  - SECURITY: Fix path traversal on diagnostics route.
  JS_ASSETS = %w{
    jquery-1.8.2.js
    react.js
    react-dom.js
    babel.min.js
    message-bus.js
    application.jsx
  }


    if asset && JS_ASSETS.include?(asset)
  def script_tags
    tags = []

    JS_ASSETS.each do |asset|
      type =
        if asset.end_with?('.js')
          'text/javascript'
        elsif asset.end_with?('.jsx')
          'text/jsx'
        end

      tags << js_asset(asset, type)
    end

    tags.join("\n")
  end


          #{script_tags}
    it "should return a 403 if an unauthorized user attempts to get at the _diagnostics path" do

    it "should return 404 for invalid assets path" do
      def @bus.is_admin_lookup
        proc { |_| true }
      end

      get "/message-bus/_diagnostics/assets/../Gemfile"
      last_response.status.must_equal 404
    end
CVE-2024-28183 (C, published 2024-03-25T15:15Z)
Description: value: ESP-IDF is the development framework for Espressif SoCs supported on Windows, Linux and macOS. A Time-of-Check to Time-of-Use (TOCTOU) vulnerability was discovered in the implementation of the ESP-IDF bootloader which could allow an attacker with physical access to flash of the device to bypass anti-rollback protection. Anti-rollback prevents rollback to application with security version lower than one programmed in eFuse of chip. This attack can allow to boot past (passive) application partition having lower security version of the same device even in the presence of the flash encryption scheme. The attack requires carefully modifying the flash contents after the anti-rollback checks have been performed by the bootloader (before loading the application). The vulnerability is fixed in 4.4.7 and 5.2.1.
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/espressif/esp-idf
Files changed:
components/bootloader_support/src/esp_image_format.c
Commit message: fix(bootloader_support): check the secure version only for app image

Secure version in the image header is only available for the application
image. However, for certain security workflows, bootloader verifies
itself (own image) and hence the secure version check during that must be
avoided.

Regression introduced in recent commit-id: 3305cb4d

Tested that both secure boot and flash-enc workflows work correctly
with the anti-rollback scenario.


Vulnerable code:
#endif
    if (segment == 0) {

Fixed code:
#endif // BOOTLOADER_BUILD
    // Case I: Bootloader verifying application
    // Case II: Bootloader verifying bootloader
    // Anti-rollback check should handle only Case I from above.
    if (segment == 0 && metadata->start_addr != ESP_BOOTLOADER_OFFSET) {
        ESP_LOGD(TAG, "additional anti-rollback check 0x%"PRIx32, data_addr);
CVE-2015-0284 (Other, published 2016-04-14T14:59Z)
Description: value: Cross-site scripting (XSS) vulnerability in spacewalk-java in Spacewalk and Red Hat Satellite 5.7 allows remote authenticated users to inject arbitrary web script or HTML via crafted XML data to the XMLRPC API, involving user details.  NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-7811.
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/spacewalkproject/spacewalk
Files changed:
backend/server/rhnPackage.py
java/code/webapp/WEB-INF/pages/admin/multiorg/org_users.jsp
java/code/webapp/WEB-INF/pages/admin/multiorg/sat_org_users.jsp
java/code/webapp/WEB-INF/pages/admin/users/activelist.jsp
java/code/webapp/WEB-INF/pages/common/fragments/manage/managers.jspf
java/code/webapp/WEB-INF/pages/common/fragments/manage/subscribers.jspf
java/code/webapp/WEB-INF/pages/common/fragments/user/userlist_columns.jspf
java/code/webapp/WEB-INF/pages/groups/adminlist.jsp
Commit message: 1181152 - XSS when altering user details and going somewhere where you are choosing user
        - Escaped tags in real names


Vulnerable code:
    if pkg[3] == '0' or pkg[3] == '':
                <c:out value="${current.userDisplayName}" escapeXml="false" />
                <c:out value="<a href=\"mailto:${current.address}\">${current.userLastName}, ${current.userFirstName}</a>" escapeXml="false"/>
                <c:out value="${current.userLastName}, ${current.userFirstName}" />
            ${current.userLastName}, ${current.userFirstName}
            ${current.userLastName}, ${current.userFirstName}
        <c:out value="${current.userLastName}, ${current.userFirstName}" />
            ${current.userLastName}, ${current.userFirstName}

Fixed code:
    if pkg[3] == '0' or pkg[3] == '' or pkg[3]==None:
                <c:out value="${current.userDisplayName}" escapeXml="true" />
                <c:out value="<a href=\"mailto:${current.address}\">${current.userLastName}, ${current.userFirstName}</a>" escapeXml="true"/>
                <c:out escapeXml="true" value="${current.userLastName}, ${current.userFirstName}" />
            <c:out escapeXml="true" value="${current.userLastName},${current.userFirstName}" />
            <c:out escapeXml="true" value="${current.userLastName},${current.userFirstName}" />
        <c:out escapeXml="true" value="${current.userLastName}, ${current.userFirstName}" />
            <c:out escapeXml="true" value="${current.userLastName},${current.userFirstName}" />
CVE-2015-0284 (Other, published 2016-04-14T14:59Z)
Description: value: Cross-site scripting (XSS) vulnerability in spacewalk-java in Spacewalk and Red Hat Satellite 5.7 allows remote authenticated users to inject arbitrary web script or HTML via crafted XML data to the XMLRPC API, involving user details.  NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-7811.
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/spacewalkproject/spacewalk
Files changed:
java/code/webapp/WEB-INF/pages/admin/multiorg/sat_org_users.jsp
Commit message: 1181152 - WebUI -> Admin -> Users XSS


Vulnerable code:
                <c:out value="<a href=\"mailto:${current.address}\">${current.userLastName}, ${current.userFirstName}</a>" escapeXml="true"/>

Fixed code:
                <c:out value="<a href=\"mailto:${current.address}\">" escapeXml="false" />
                <c:out value="${current.userLastName}, ${current.userFirstName}" escapeXml="true" />
                <c:out value="</a>" escapeXml="false" />
CVE-2020-1693 (Other, published 2020-02-17T20:15Z)
Description: value: A flaw was found in Spacewalk up to version 2.9 where it was vulnerable to XML internal entity attacks via the /rpc/api endpoint. An unauthenticated remote attacker could use this flaw to retrieve the content of certain files and trigger a denial of service, or in certain circumstances, execute arbitrary code on the Spacewalk server.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-611 \u2014 Improper Restriction of XML External Entity Reference
The product processes an XML document that can contain XML entities with URIs that resolve to documents outside of the intended sphere of control, causing the product to embed incorrect documents into its output.
Repository: https://github.com/spacewalkproject/spacewalk
Files changed:
spec-tree/redstone-xmlrpc/redstone-xmlrpc.spec
spec-tree/redstone-xmlrpc/xxe2.patch
Commit message: 1791164 - disable external entity parsing


Vulnerable code:

Fixed code:
Patch4: xxe2.patch
%patch4 -p0
diff '--exclude=CVS' '--exclude=.svn' -ur ../xmlrpc-orig/source/redstone/xmlrpc/XmlRpcParser.java ../xmlrpc/source/redstone/xmlrpc/XmlRpcParser.java
--- source/redstone/xmlrpc/XmlRpcParser.java	2020-01-16 14:18:28.294284905 +0100
@@ -135,6 +135,7 @@
                 {
                     reader = XMLReaderFactory.createXMLReader();
                     reader.setEntityResolver(new DummyEntityResolver());
+                    reader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
                 }
                 catch ( SAXException e )
                 {
CVE-2021-39194 (Kotlin, published 2021-09-07T20:15Z)
Description: value: kaml is an open source implementation of the YAML format with support for kotlinx.serialization. In affected versions attackers that could provide arbitrary YAML input to an application that uses kaml could cause the application to endlessly loop while parsing the input. This could result in resource starvation and denial of service. This only affects applications that use polymorphic serialization with the default tagged polymorphism style. Applications using the property polymorphism style are not affected. YAML input for a polymorphic type that provided a tag but no value for the object would trigger the issue. Version 0.35.3 or later contain the fix for this issue.
Severity: MEDIUM (CVSS v3 base score: 6.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/charleskorn/kaml
Files changed:
src/commonMain/kotlin/com/charleskorn/kaml/YamlInput.kt
src/commonTest/kotlin/com/charleskorn/kaml/YamlReadingTest.kt
Commit message: Fix issue where decoding a polymorphic type that uses the tag polymorphism style could hang if no value was provided after the tag.

Fixes #179.


Vulnerable code:
    override fun decodeElementIndex(descriptor: SerialDescriptor): Int = 0

Fixed code:
import kotlinx.serialization.encoding.CompositeDecoder.Companion.DECODE_DONE
    override fun decodeElementIndex(descriptor: SerialDescriptor): Int = DECODE_DONE
                // See https://github.com/charleskorn/kaml/issues/179.
                context("given some input where a tag is provided but no value is provided") {
                    val input = """
                        !<sealedString>
                    """.trimIndent()

                    context("parsing that input") {
                        it("throws an appropriate exception") {
                            expect({ polymorphicYaml.decodeFromString(TestSealedStructure.serializer(), input) }).toThrow<MissingRequiredPropertyException> {
                                message { toBe("Property 'value' is required but it is missing.") }
                                line { toBe(1) }
                                column { toBe(1) }
                                propertyName { toBe("value") }
                                path { toBe(YamlPath.root) }
                            }
                        }
                    }
                }
CVE-2023-48218 (JavaScript, published 2023-11-20T17:15Z)
Description: value: The Strapi Protected Populate Plugin protects `get` endpoints from revealing too much information. Prior to version 1.3.4, users were able to bypass the field level security. Users who tried to populate something that they didn't have access to could populate those fields anyway. This issue has been patched in version 1.3.4. There are no known workarounds.
Severity: nan (CVSS v3 base score: 5.3)
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/strapi-community/strapi-plugin-protected-populate
Files changed:
server/middlewares/helpers/protect-route.js
Commit message: fix fields always populating ID


Vulnerable code:
      populate.fields = [];
      populate.fields = info.fields;
      let fields = [];
      populate.fields = info.fields;
  query.populate = savePopulate.populate;

Fixed code:
      populate.fields = ['id'];
      populate.fields = ['id', ...info.fields];
      let fields = ['id'];
      populate.fields = ['id', ...info.fields];
    //DZ
  query.populate = savePopulate.populate || savePopulate.on;
CVE-2018-14474 (Go, published 2018-07-20T18:29Z)
Description: value: views/auth.go in Orange Forum 1.4.0 allows Open Redirection via the next parameter to /login or /signup.
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-601 \u2014 URL Redirection to Untrusted Site ('Open Redirect')
A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.
Repository: https://github.com/s-gv/orangeforum
Files changed:
views/auth.go
Commit message: Fix open redirection


Vulnerable code:
	if redirectURL == "" || err != nil {
	if redirectURL == "" || err != nil {

Fixed code:
	if err != nil || redirectURL == "" || redirectURL[0] != '/' {
	if err != nil || redirectURL == "" || redirectURL[0] != '/' {
CVE-2019-20791 (C++, published 2020-04-28T18:15Z)
Description: value: OpenThread before 2019-12-13 has a stack-based buffer overflow in MeshCoP::Commissioner::GeneratePskc.
Severity: HIGH (CVSS v3 base score: 9.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/openthread/openthread
Files changed:
src/core/meshcop/commissioner.cpp
Commit message: [commissioner] add network name length check in GeneratePskc() (#4404)


Vulnerable code:
                     (strlen(aPassPhrase) <= OT_COMMISSIONING_PASSPHRASE_MAX_SIZE),

Fixed code:
                     (strlen(aPassPhrase) <= OT_COMMISSIONING_PASSPHRASE_MAX_SIZE) &&
                     (strlen(aNetworkName) <= OT_NETWORK_NAME_MAX_SIZE),
CVE-2019-20791 (C++, published 2020-04-28T18:15Z)
Description: value: OpenThread before 2019-12-13 has a stack-based buffer overflow in MeshCoP::Commissioner::GeneratePskc.
Severity: HIGH (CVSS v3 base score: 9.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/openthread/openthread
Files changed:
src/core/meshcop/commissioner.cpp
Commit message: [commissioner] use strnlen instead of strlen (#4404)


Vulnerable code:
    VerifyOrExit(strlen(aPskd) <= Dtls::kPskMaxLength, error = OT_ERROR_INVALID_ARGS);
    otError     error      = OT_ERROR_NONE;
    const char *saltPrefix = "Thread";
    uint8_t     salt[OT_PBKDF2_SALT_MAX_LEN];
    uint16_t    saltLen = 0;

    VerifyOrExit((strlen(aPassPhrase) >= OT_COMMISSIONING_PASSPHRASE_MIN_SIZE) &&
                     (strlen(aPassPhrase) <= OT_COMMISSIONING_PASSPHRASE_MAX_SIZE) &&
                     (strlen(aNetworkName) <= OT_NETWORK_NAME_MAX_SIZE),
    memcpy(salt, saltPrefix, strlen(saltPrefix));
    saltLen += static_cast<uint16_t>(strlen(saltPrefix));
    memcpy(salt + saltLen, aNetworkName, strlen(aNetworkName));
    saltLen += static_cast<uint16_t>(strlen(aNetworkName));
    otPbkdf2Cmac(reinterpret_cast<const uint8_t *>(aPassPhrase), static_cast<uint16_t>(strlen(aPassPhrase)),
                 reinterpret_cast<const uint8_t *>(salt), saltLen, 16384, OT_PSKC_MAX_SIZE, aPskc.m8);

Fixed code:
    VerifyOrExit(strnlen(aPskd, Dtls::kPskMaxLength + 1) <= Dtls::kPskMaxLength, error = OT_ERROR_INVALID_ARGS);

    otError    error        = OT_ERROR_NONE;
    const char saltPrefix[] = "Thread";
    uint8_t    salt[OT_PBKDF2_SALT_MAX_LEN];
    uint16_t   saltLen = 0;
    uint16_t   passphraseLen;
    uint8_t    networkNameLen;

    passphraseLen  = static_cast<uint16_t>(strnlen(aPassPhrase, OT_COMMISSIONING_PASSPHRASE_MAX_SIZE + 1));
    networkNameLen = static_cast<uint8_t>(strnlen(aNetworkName, OT_NETWORK_NAME_MAX_SIZE + 1));

    VerifyOrExit((passphraseLen >= OT_COMMISSIONING_PASSPHRASE_MIN_SIZE) &&
                     (passphraseLen <= OT_COMMISSIONING_PASSPHRASE_MAX_SIZE) &&
                     (networkNameLen <= OT_NETWORK_NAME_MAX_SIZE),
    memcpy(salt, saltPrefix, sizeof(saltPrefix) - 1);
    saltLen += static_cast<uint16_t>(sizeof(saltPrefix) - 1);
    memcpy(salt + saltLen, aNetworkName, networkNameLen);
    saltLen += networkNameLen;
    otPbkdf2Cmac(reinterpret_cast<const uint8_t *>(aPassPhrase), passphraseLen, reinterpret_cast<const uint8_t *>(salt),
                 saltLen, 16384, OT_PSKC_MAX_SIZE, aPskc.m8);
CVE-2021-41263 (Ruby, published 2021-11-15T20:15Z)
Description: value: rails_multisite provides multi-db support for Rails applications. In affected versions this vulnerability impacts any Rails applications using `rails_multisite` alongside Rails' signed/encrypted cookies. Depending on how the application makes use of these cookies, it may be possible for an attacker to re-use cookies on different 'sites' within a multi-site Rails application. The issue has been patched in v4 of the `rails_multisite` gem. Note that this upgrade will invalidate all previous signed/encrypted cookies. The impact of this invalidation will vary based on the application architecture.
Severity: MEDIUM (CVSS v3 base score: 8.8)
Weakness: CWE-327 \u2014 Use of a Broken or Risky Cryptographic Algorithm
The product uses a broken or risky cryptographic algorithm or protocol.
Repository: https://github.com/discourse/rails_multisite
Files changed:
CHANGELOG.md
lib/rails_multisite.rb
lib/rails_multisite/cookie_salt.rb
lib/rails_multisite/middleware.rb
lib/rails_multisite/version.rb
spec/middleware_spec.rb
Commit message: SECURITY: Vary the encrypted/signed cookie salts per-hostname (#26)

This ensures Rails encrypted/signed cookies cannot be re-used across different sites which share the same secret_key_base

Vulnerable code:
  VERSION = "3.1.0"

Fixed code:
## 4.0.0 - 2021-11-15

 * Vary the encrypted/signed cookie salts per-hostname (fix for CVE-2021-41263). This update will
   cause existing cookies to be invalidated

require 'rails_multisite/cookie_salt'
# frozen_string_literal: true

module RailsMultisite
  class CookieSalt
    COOKIE_SALT_KEYS = [
      "action_dispatch.signed_cookie_salt",
      "action_dispatch.encrypted_cookie_salt",
      "action_dispatch.encrypted_signed_cookie_salt",
      "action_dispatch.authenticated_encrypted_cookie_salt"
    ]

    def self.update_cookie_salts(env:, host:)
      COOKIE_SALT_KEYS.each { |key| env[key] = "#{env[key]} #{host}" }
    end
  end
end
        CookieSalt.update_cookie_salts(env: env, host: host)
  VERSION = "4.0.0"
require 'json'
      map '/salts' do
        run (proc do |env|
          [200, { 'Content-Type' => 'application/json' }, env.slice(*RailsMultisite::CookieSalt::COOKIE_SALT_KEYS).to_json]
        end)
      end

  describe 'encrypted/signed cookie salts' do
    it 'updates salts per-hostname' do
      get 'http://default.localhost/salts'
      expect(last_response).to be_ok
      default_salts = JSON.parse(last_response.body)
      expect(default_salts.keys).to contain_exactly(*RailsMultisite::CookieSalt::COOKIE_SALT_KEYS)
      expect(default_salts.values).to all(include("default.localhost"))

      get 'http://second.localhost/salts'
      expect(last_response).to be_ok
      second_salts = JSON.parse(last_response.body)
      expect(second_salts.keys).to contain_exactly(*RailsMultisite::CookieSalt::COOKIE_SALT_KEYS)
      expect(second_salts.values).to all(include("second.localhost"))

      leaked_previous_hostname = second_salts.values.any? { |v| v.include?("default.localhost") }
      expect(leaked_previous_hostname).to eq(false)
    end
  end