hitoshura25/cvefixes huggingface dataset:
CVE-2023-6832 (PHP, published 2023-12-15T01:15Z)
Description: value: Business Logic Errors in GitHub repository microweber/microweber prior to 2.0.
Severity: nan (CVSS v3 base score: 4.3)
Weakness: CWE-840 \u2014 Business Logic Errors
Weaknesses in this category identify some of the underlying problems that commonly allow attackers to manipulate the business logic of an application. Errors in business logic can be devastating to an entire application. They can be difficult to find automatically, since they typically involve legitimate use of the application's functionality. However, many business logic errors can exhibit patterns that are similar to well-understood implementation and design weaknesses.
Repository: https://github.com/microweber/microweber
Files changed:
src/MicroweberPackages/Checkout/CheckoutManager.php
userfiles/modules/shop/coupons/admin.php
userfiles/modules/shop/coupons/functions.php
Commit message: update


Vulnerable code:

            if ($coupon_code) {
                    <input type="checkbox" name="enable_coupons" class="mw_option_field form-check-input" id="enable_coupons" data-option-group="shop" data-value-checked="y" data-value-unchecked="n" <?php if (get_option('enable_coupons', 'shop') == 1): ?>checked<?php endif; ?> />

Fixed code:
            $canUseCoupons = $this->app->option_manager->get('enable_coupons', 'shop') == 1;
            if ($canUseCoupons and $coupon_code) {
                    <input type="checkbox" name="enable_coupons" class="mw_option_field form-check-input" id="enable_coupons" data-option-group="shop" data-value-checked="1" data-value-unchecked="0" <?php if (get_option('enable_coupons', 'shop') == 1): ?>checked<?php endif; ?> />
    if (get_option('enable_coupons', 'shop') == 0){
        $json['error_message'] = _e('The coupon code usage is disabled.', true);
        return $json;
    }
CVE-2016-10128 (C, published 2017-03-24T15:59Z)
Description: value: Buffer overflow in the git_pkt_parse_line function in transports/smart_pkt.c in the Git Smart Protocol support in libgit2 before 0.24.6 and 0.25.x before 0.25.1 allows remote attackers to have unspecified impact via a crafted non-flush packet.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/libgit2/libgit2
Files changed:
src/transports/smart_pkt.c
Commit message: smart_pkt: verify packet length exceeds PKT_LEN_SIZE

Each packet line in the Git protocol is prefixed by a four-byte
length of how much data will follow, which we parse in
`git_pkt_parse_line`. The transmitted length can either be equal
to zero in case of a flush packet or has to be at least of length
four, as it also includes the encoded length itself. Not
checking this may result in a buffer overflow as we directly pass
the length to functions which accept a `size_t` length as
parameter.

Fix the issue by verifying that non-flush packets have at least a
length of `PKT_LEN_SIZE`.


Vulnerable code:

Fixed code:
	/*
	 * The length has to be exactly 0 in case of a flush
	 * packet or greater than PKT_LEN_SIZE, as the decoded
	 * length includes its own encoded length of four bytes.
	 */
	if (len != 0 && len < PKT_LEN_SIZE)
		return GIT_ERROR;
CVE-2016-10129 (C, published 2017-03-24T15:59Z)
Description: value: The Git Smart Protocol support in libgit2 before 0.24.6 and 0.25.x before 0.25.1 allows remote attackers to cause a denial of service (NULL pointer dereference) via an empty packet line.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-476 \u2014 NULL Pointer Dereference
The product dereferences a pointer that it expects to be valid but is NULL.
Repository: https://github.com/libgit2/libgit2
Files changed:
src/transports/smart_pkt.c
src/transports/smart_protocol.c
Commit message: smart_pkt: treat empty packet lines as error

The Git protocol does not specify what should happen in the case
of an empty packet line (that is a packet line "0004"). We
currently indicate success, but do not return a packet in the
case where we hit an empty line. The smart protocol was not
prepared to handle such packets in all cases, though, resulting
in a `NULL` pointer dereference.

Fix the issue by returning an error instead. As such kind of
packets is not even specified by upstream, this is the right
thing to do.


Vulnerable code:
	 * TODO: How do we deal with empty lines? Try again? with the next
	 * line?
		*head = NULL;
		*out = line;
		return 0;
		/* When a valid packet with no content has been
		 * read, git_pkt_parse_line does not report an
		 * error, but the pkt pointer has not been set.
		 * Handle this by skipping over empty packets.
		 */
		if (pkt == NULL)
			continue;

		if (pkt == NULL)
			continue;


Fixed code:
	 * The Git protocol does not specify empty lines as part
	 * of the protocol. Not knowing what to do with an empty
	 * line, we should return an error upon hitting one.
		giterr_set_str(GITERR_NET, "Invalid empty packet");
		return GIT_ERROR;
CVE-2016-10130 (C, published 2017-03-24T15:59Z)
Description: value: The http_connect function in transports/http.c in libgit2 before 0.24.6 and 0.25.x before 0.25.1 might allow man-in-the-middle attackers to spoof servers by leveraging clobbering of the error variable.
Severity: MEDIUM (CVSS v3 base score: 5.9)
Weakness: CWE-284 \u2014 Improper Access Control
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
Repository: https://github.com/libgit2/libgit2
Files changed:
src/transports/http.c
Commit message: http: check certificate validity before clobbering the error variable

Vulnerable code:
		int is_valid;
		is_valid = error != GIT_ECERTIFICATE;

Fixed code:
		int is_valid = (error == GIT_OK);
CVE-2018-8098 (C, published 2018-03-14T00:29Z)
Description: value: Integer overflow in the index.c:read_entry() function while decompressing a compressed prefix length in libgit2 before v0.26.2 allows an attacker to cause a denial of service (out-of-bounds read) via a crafted repository index file.
Severity: MEDIUM (CVSS v3 base score: 6.5)
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/libgit2/libgit2
Files changed:
src/index.c
Commit message: index: error out on unreasonable prefix-compressed path lengths

When computing the complete path length from the encoded
prefix-compressed path, we end up just allocating the complete path
without ever checking what the encoded path length actually is. This can
easily lead to a denial of service by just encoding an unreasonable long
path name inside of the index. Git already enforces a maximum path
length of 4096 bytes. As we also have that enforcement ready in some
places, just make sure that the resulting path is smaller than
GIT_PATH_MAX.

Reported-by: Krishna Ram Prakash R <krp@gtux.in>
Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>


Vulnerable code:

Fixed code:

		if (path_len > GIT_PATH_MAX)
			return index_error_invalid("unreasonable path length");
CVE-2018-8098 (C, published 2018-03-14T00:29Z)
Description: value: Integer overflow in the index.c:read_entry() function while decompressing a compressed prefix length in libgit2 before v0.26.2 allows an attacker to cause a denial of service (out-of-bounds read) via a crafted repository index file.
Severity: MEDIUM (CVSS v3 base score: 6.5)
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/libgit2/libgit2
Files changed:
src/index.c
Commit message: index: fix out-of-bounds read with invalid index entry prefix length

The index format in version 4 has prefix-compressed entries, where every
index entry can compress its path by using a path prefix of the previous
entry. Since implmenting support for this index format version in commit
5625d86b9 (index: support index v4, 2016-05-17), though, we do not
correctly verify that the prefix length that we want to reuse is
actually smaller or equal to the amount of characters than the length of
the previous index entry's path. This can lead to a an integer underflow
and subsequently to an out-of-bounds read.

Fix this by verifying that the prefix is actually smaller than the
previous entry's path length.

Reported-by: Krishna Ram Prakash R <krp@gtux.in>
Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>


Vulnerable code:
		size_t varint_len;
		size_t strip_len = git_decode_varint((const unsigned char *)path_ptr,
						     &varint_len);
		size_t last_len = strlen(last);
		size_t prefix_len = last_len - strip_len;
		size_t suffix_len = strlen(path_ptr + varint_len);
		size_t path_len;

		if (varint_len == 0)

Fixed code:
		size_t varint_len, last_len, prefix_len, suffix_len, path_len;
		uintmax_t strip_len;

		strip_len = git_decode_varint((const unsigned char *)path_ptr, &varint_len);
		last_len = strlen(last);

		if (varint_len == 0 || last_len < strip_len)
		prefix_len = last_len - strip_len;
		suffix_len = strlen(path_ptr + varint_len);
CVE-2018-8099 (C, published 2018-03-14T00:29Z)
Description: value: Incorrect returning of an error code in the index.c:read_entry() function leads to a double free in libgit2 before v0.26.2, which allows an attacker to cause a denial of service via a crafted repository index file.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-415 \u2014 Double Free
The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.
Repository: https://github.com/libgit2/libgit2
Files changed:
src/index.c
Commit message: index: convert `read_entry` to return entry size via an out-param

The function `read_entry` does not conform to our usual coding style of
returning stuff via the out parameter and to use the return value for
reporting errors. Due to most of our code conforming to that pattern, it
has become quite natural for us to actually return `-1` in case there is
any error, which has also slipped in with commit 5625d86b9 (index:
support index v4, 2016-05-17). As the function returns an `size_t` only,
though, the return value is wrapped around, causing the caller of
`read_tree` to continue with an invalid index entry. Ultimately, this
can lead to a double-free.

Improve code and fix the bug by converting the function to return the
index entry size via an out parameter and only using the return value to
indicate errors.

Reported-by: Krishna Ram Prakash R <krp@gtux.in>
Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>


Vulnerable code:
static size_t read_entry(
		return 0;
				return 0;
		return 0;
		return 0;
	return entry_size;
		size_t entry_size = read_entry(&entry, index, buffer, buffer_size, last);
		/* 0 bytes read means an object corruption */
		if (entry_size == 0) {

Fixed code:
static int read_entry(
	size_t *out_size,
		return -1;
				return -1;
	if (entry_size == 0)
		return -1;

		return -1;
		return -1;
	*out_size = entry_size;
	return 0;
		size_t entry_size;
		if ((error = read_entry(&entry, &entry_size, index, buffer, buffer_size, last)) < 0) {
CVE-2020-12278 (C, published 2020-04-27T17:15Z)
Description: value: An issue was discovered in libgit2 before 0.28.4 and 0.9x before 0.99.0. path.c mishandles equivalent filenames that exist because of NTFS Alternate Data Streams. This may allow remote code execution when cloning a repository. This issue is similar to CVE-2019-1352.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-706 \u2014 Use of Incorrectly-Resolved Name or Reference
The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere.
Repository: https://github.com/libgit2/libgit2
Files changed:
src/path.c
tests/path/dotgit.c
Commit message: path: also guard `.gitmodules` against NTFS Alternate Data Streams

We just safe-guarded `.git` against NTFS Alternate Data Stream-related
attack vectors, and now it is time to do the same for `.gitmodules`.

Note: In the added regression test, we refrain from verifying all kinds
of variations between short names and NTFS Alternate Data Streams: as
the new code disallows _all_ Alternate Data Streams of `.gitmodules`, it
is enough to test one in order to know that all of them are guarded
against.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>


Vulnerable code:
		if (*c == '\0')

Fixed code:
		if (*c == '\0' || *c == ':')
	cl_assert_equal_b(false, git_path_isvalid(NULL, ".gitmodules . .::$DATA", S_IFLNK, GIT_PATH_REJECT_DOT_GIT_NTFS));
CVE-2020-12278 (C, published 2020-04-27T17:15Z)
Description: value: An issue was discovered in libgit2 before 0.28.4 and 0.9x before 0.99.0. path.c mishandles equivalent filenames that exist because of NTFS Alternate Data Streams. This may allow remote code execution when cloning a repository. This issue is similar to CVE-2019-1352.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-706 \u2014 Use of Incorrectly-Resolved Name or Reference
The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere.
Repository: https://github.com/libgit2/libgit2
Files changed:
src/path.c
tests/checkout/nasty.c
Commit message: Disallow NTFS Alternate Data Stream attacks, even on Linux/macOS

A little-known feature of NTFS is that it offers to store metadata in
so-called "Alternate Data Streams" (inspired by Apple's "resource
forks") that are copied together with the file they are associated with.
These Alternate Data Streams can be accessed via `<file name>:<stream
name>:<stream type>`.

Directories, too, have Alternate Data Streams, and they even have a
default stream type `$INDEX_ALLOCATION`. Which means that `abc/` and
`abc::$INDEX_ALLOCATION/` are actually equivalent.

This is of course another attack vector on the Git directory that we
definitely want to prevent.

On Windows, we already do this incidentally, by disallowing colons in
file/directory names.

While it looks as if files'/directories' Alternate Data Streams are not
accessible in the Windows Subsystem for Linux, and neither via
CIFS/SMB-mounted network shares in Linux, it _is_ possible to access
them on SMB-mounted network shares on macOS.

Therefore, let's go the extra mile and prevent this particular attack
_everywhere_. To keep things simple, let's just disallow *any* Alternate
Data Stream of `.git`.

This is libgit2's variant of CVE-2019-1352.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>


Vulnerable code:
	/* Reject paths like ".git\" */
	if (path[start] == '\\')

Fixed code:
	/*
	 * Reject paths that start with Windows-style directory separators
	 * (".git\") or NTFS alternate streams (".git:") and could be used
	 * to write to the ".git" directory on Windows platforms.
	 */
	if (path[start] == '\\' || path[start] == ':')
/* A tree that contains an entry ".git::$INDEX_ALLOCATION" because NTFS
 * will interpret that as a synonym to ".git", even when mounted via SMB
 * on macOS.
 */
void test_checkout_nasty__dotgit_alternate_data_stream(void)
{
	test_checkout_fails("refs/heads/dotgit_alternate_data_stream", ".git/dummy-file");
	test_checkout_fails("refs/heads/dotgit_alternate_data_stream", ".git::$INDEX_ALLOCATION/dummy-file");
}
CVE-2020-12279 (C, published 2020-04-27T17:15Z)
Description: value: An issue was discovered in libgit2 before 0.28.4 and 0.9x before 0.99.0. checkout.c mishandles equivalent filenames that exist because of NTFS short names. This may allow remote code execution when cloning a repository. This issue is similar to CVE-2019-1353.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-706 \u2014 Use of Incorrectly-Resolved Name or Reference
The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere.
Repository: https://github.com/libgit2/libgit2
Files changed:
src/checkout.c
tests/checkout/nasty.c
Commit message: Protect against 8.3 "short name" attacks also on Linux/macOS

The Windows Subsystem for Linux (WSL) is getting increasingly popular,
in particular because it makes it _so_ easy to run Linux software on
Windows' files, via the auto-mounted Windows drives (`C:\` is mapped to
`/mnt/c/`, no need to set that up manually).

Unfortunately, files/directories on the Windows drives can be accessed
via their _short names_, if that feature is enabled (which it is on the
`C:` drive by default).

Which means that we have to safeguard even our Linux users against the
short name attacks.

Further, while the default options of CIFS/SMB-mounts seem to disallow
accessing files on network shares via their short names on Linux/macOS,
it _is_ possible to do so with the right options.

So let's just safe-guard against short name attacks _everywhere_.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>


Vulnerable code:
	unsigned int flags = GIT_PATH_REJECT_WORKDIR_DEFAULTS;
#ifdef GIT_WIN32
#endif

Fixed code:
	unsigned int flags = GIT_PATH_REJECT_WORKDIR_DEFAULTS | GIT_PATH_REJECT_DOT_GIT_NTFS;
	test_checkout_fails("refs/heads/git_tilde1", "git~1/foobar");
CVE-2024-24575 (C, published 2024-02-06T22:16Z)
Description: value: libgit2 is a portable C implementation of the Git core methods provided as a linkable library with a solid API, allowing to build Git functionality into your application. Using well-crafted inputs to `git_revparse_single` can cause the function to enter an infinite loop, potentially causing a Denial of Service attack in the calling application. The revparse function in `src/libgit2/revparse.c` uses a loop to parse the user-provided spec string. There is an edge-case during parsing that allows a bad actor to force the loop conditions to access arbitrary memory. Potentially, this could also leak memory if the extracted rev spec is reflected back to the attacker. As such, libgit2 versions before 1.4.0 are not affected. Users should upgrade to version 1.6.5 or 1.7.2.
Severity: nan (CVSS v3 base score: 7.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/libgit2/libgit2
Files changed:
src/revparse.c
tests/refs/revparse.c
Commit message: revparse: support bare '@'

A bare '@' revision syntax represents HEAD.  Support it as such.


Vulnerable code:

Fixed code:
			} else if (spec[pos+1] == '\0') {
				spec = "HEAD";
				break;

void test_refs_revparse__parses_at_head(void)
{
	test_id("HEAD", "a65fedf39aefe402d3bb6e24df4d4f5fe4547750", NULL, GIT_REVSPEC_SINGLE);
	test_id("@{0}", "a65fedf39aefe402d3bb6e24df4d4f5fe4547750", NULL, GIT_REVSPEC_SINGLE);
	test_id("@", "a65fedf39aefe402d3bb6e24df4d4f5fe4547750", NULL, GIT_REVSPEC_SINGLE);
}
CVE-2019-25092 (PHP, published 2022-12-28T09:15Z)
Description: value: A vulnerability classified as problematic was found in Nakiami Mellivora up to 2.1.x. Affected by this vulnerability is the function print_user_ip_log of the file include/layout/user.inc.php of the component Admin Panel. The manipulation of the argument $entry['ip'] leads to cross site scripting. The attack can be launched remotely. Upgrading to version 2.2.0 is able to address this issue. The name of the patch is e0b6965f8dde608a3d2621617c05695eb406cbb9. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-216955.
Severity: nan (CVSS v3 base score: 4.8)
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/Nakiami/mellivora
Files changed:
include/layout/user.inc.php
Commit message: fix hostname lookup xss in admin panel reported in issue 123 by Sin42


Vulnerable code:
            <td>',(Config::get('MELLIVORA_CONFIG_GET_IP_HOST_BY_ADDRESS') ? gethostbyaddr($entry['ip']) : '<i>Lookup disabled in config</i>'),'</td>

Fixed code:
            <td>',(Config::get('MELLIVORA_CONFIG_GET_IP_HOST_BY_ADDRESS') ? htmlspecialchars(gethostbyaddr($entry['ip'])) : '<i>Lookup disabled in config</i>'),'</td>
CVE-2020-15257 (Unknown, published 2020-12-01T03:15Z)
Description: value: containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows. In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host network containers. Access controls for the shim’s API socket verified that the connecting process had an effective UID of 0, but did not otherwise restrict access to the abstract Unix domain socket. This would allow malicious containers running in the same network namespace as the shim, with an effective UID of 0 but otherwise reduced privileges, to cause new processes to be run with elevated privileges. This vulnerability has been fixed in containerd 1.3.9 and 1.4.3. Users should update to these versions as soon as they are released. It should be noted that containers started with an old version of containerd-shim should be stopped and restarted, as running containers will continue to be vulnerable even after an upgrade. If you are not providing the ability for untrusted users to start containers in the same network namespace as the shim (typically the "host" network namespace, for example with docker run --net=host or hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this issue. If you are running containers with a vulnerable configuration, you can deny access to all abstract sockets with AppArmor by adding a line similar to deny unix addr=@**, to your policy. It is best practice to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of isolation mechanisms used for a container necessarily increases that container's privilege, regardless of what container runtime is used for running that container.
Severity: LOW (CVSS v3 base score: 5.2)
Weakness: CWE-669 \u2014 Incorrect Resource Transfer Between Spheres
The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.
Repository: https://github.com/containerd/containerd
Files changed:
Commit message: Merge pull request from GHSA-36xw-fx78-c5r4

Use path based unix socket for shims

Vulnerable code:

Fixed code: