hitoshura25/cvefixes huggingface dataset:
CVE-2022-4725 (Java, published 2022-12-27T15:15Z)
Description: value: A vulnerability was found in AWS SDK 2.59.0. It has been rated as critical. This issue affects the function XpathUtils of the file aws-android-sdk-core/src/main/java/com/amazonaws/util/XpathUtils.java of the component XML Parser. The manipulation leads to server-side request forgery. Upgrading to version 2.59.1 is able to address this issue. The name of the patch is c3e6d69422e1f0c80fe53f2d757b8df97619af2b. It is recommended to upgrade the affected component. The identifier VDB-216737 was assigned to this vulnerability.
Severity: nan (CVSS v3 base score: 9.8)
Weakness: CWE-918 \u2014 Server-Side Request Forgery (SSRF)
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
Repository: https://github.com/aws-amplify/aws-sdk-android
Files changed:
aws-android-sdk-core/src/main/java/com/amazonaws/regions/RegionMetadataParser.java
aws-android-sdk-core/src/main/java/com/amazonaws/util/XpathUtils.java
Commit message: fix(core): added fix for xml parser (#3100)

* added fix for xml parser vulnerability

* added fix for xml parser vulnerability

Co-authored-by: Banji Jolaoso <banjij@amazon.com>

Vulnerable code:
            DocumentBuilderFactory factory =
                    DocumentBuilderFactory.newInstance();

    private static DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

Fixed code:
            DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
            factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
            factory.setXIncludeAware(false);
            factory.setExpandEntityReferences(false);
    private static DocumentBuilderFactory factory = getDocumentBuilderFactory();


    /**
     * Creates new documentbuilderfactory object
     * @return DocumentBuilderFactory.
     */
    private static DocumentBuilderFactory getDocumentBuilderFactory() {
        try {
            DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
            dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
            dbf.setXIncludeAware(false); // Default false for java 8. Disable XML Inclusions leading to SSRF - https://portswigger.net/web-security/xxe/lab-xinclude-attack
            dbf.setExpandEntityReferences(false);
            return dbf;
        }
        catch (ParserConfigurationException exception){
            return null;
        }
    }
CVE-2023-38704 (Other, published 2023-08-07T20:15Z)
Description: value: import-in-the-middle is a module loading interceptor specifically for ESM modules. The import-in-the-middle loader works by generating a wrapper module on the fly. The wrapper uses the module specifier to load the original module and add some wrapping code. Prior to version 1.4.2, it allows for remote code execution in cases where an application passes user-supplied input directly to the `import()` function. This vulnerability has been patched in import-in-the-middle version 1.4.2.

Some workarounds are available. Do not pass any user-supplied input to `import()`. Instead, verify it against a set of allowed values. If using import-in-the-middle, directly or indirectly, and support for EcmaScript Modules is not needed, ensure that no options are set, either via command-line or the `NODE_OPTIONS` environment variable, that would enable loader hooks.
Severity: nan (CVSS v3 base score: 9.8)
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/DataDog/import-in-the-middle
Files changed:
hook.js
test/low-level/sanitized-url.mjs
Commit message: sanitize URLs


Vulnerable code:
import * as namespace from '${url}'
register('${realUrl}', namespace, set, '${specifiers.get(realUrl)}')

Fixed code:
import * as namespace from ${JSON.stringify(url)}
register(${JSON.stringify(realUrl)}, namespace, set, ${JSON.stringify(specifiers.get(realUrl))})
// Unless explicitly stated otherwise all files in this repository are licensed under the Apache 2.0 License.
//
// This product includes software developed at Datadog (https://www.datadoghq.com/). Copyright 2021 Datadog, Inc.

import { addHook } from '../../index.js'

addHook(() => {})

;(async () => {
  await import("../fixtures/something.mjs#*/'/*';eval('process.exit\x281\x29\x0A')")
})()
CVE-2021-25968 (Other, published 2021-10-19T09:15Z)
Description: value: In “OpenCMS”, versions 10.5.0 to 11.0.2 are affected by a stored XSS vulnerability that allows low privileged application users to store malicious scripts in the Sitemap functionality. These scripts are executed in a victim’s browser when they open the page containing the vulnerable field.
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/alkacon/mercury-template
Files changed:
alkacon.mercury.template/resources/system/modules/alkacon.mercury.template/formatters/navigation/breadcrumbs.jsp
alkacon.mercury.template/resources/system/modules/alkacon.mercury.template/formatters/navigation/main.jsp
alkacon.mercury.template/resources/system/modules/alkacon.mercury.template/formatters/navigation/side.jsp
Commit message: Escaping of naviation text to prevent usage of script in nav elements.

Vulnerable code:
                            <c:set var="navText" value="${(empty navElem.navText or fn:startsWith(navElem.navText, '???'))
                                ? navElem.title : navElem.navText}" />
            <c:set var="navText" value="${(empty navElem.navText or fn:startsWith(navElem.navText, '???'))
                ? navElem.title : navElem.navText}" />
                <c:set var="navText" value="${(empty navElem.navText or fn:startsWith(navElem.navText, '???')) ? navElem.title : navElem.navText}" />

Fixed code:
                            <c:set var="navText"><c:out value="${(empty navElem.navText or fn:startsWith(navElem.navText, '???'))
                                ? navElem.title : navElem.navText}" /></c:set>
            <c:set var="navText"><c:out value="${(empty navElem.navText or fn:startsWith(navElem.navText, '???'))
                ? navElem.title : navElem.navText}" /></c:set>

                <c:set var="navText"><c:out value="${(empty navElem.navText or fn:startsWith(navElem.navText, '???')) ? navElem.title : navElem.navText}" /></c:set>
CVE-2018-15853 (C, published 2018-08-25T21:29Z)
Description: value: Endless recursion exists in xkbcomp/expr.c in xkbcommon and libxkbcommon before 0.8.1, which could be used by local attackers to crash xkbcommon users by supplying a crafted keymap file that triggers boolean negation.
Severity: LOW (CVSS v3 base score: 5.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/xkbcommon/libxkbcommon
Files changed:
src/xkbcomp/expr.c
Commit message: xkbcomp: fix stack overflow when evaluating boolean negation

The expression evaluator would go into an infinite recursion when
evaluating something like this as a boolean: `!True`. Instead of
recursing to just `True` and negating, it recursed to `!True` itself
again.

Bug inherited from xkbcomp.

Caught with the afl fuzzer.

Signed-off-by: Ran Benita <ran234@gmail.com>


Vulnerable code:
        ok = ExprResolveBoolean(ctx, expr, set_rtrn);

Fixed code:
        ok = ExprResolveBoolean(ctx, expr->unary.child, set_rtrn);
CVE-2018-15854 (C, published 2018-08-25T21:29Z)
Description: value: Unchecked NULL pointer usage in xkbcommon before 0.8.1 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file, because geometry tokens were desupported incorrectly.
Severity: LOW (CVSS v3 base score: 5.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/xkbcommon/libxkbcommon
Files changed:
src/xkbcomp/ast-build.c
src/xkbcomp/ast-build.h
src/xkbcomp/ast.h
src/xkbcomp/parser.y
Commit message: xkbcomp: fix crashes in the parser when geometry tokens appear

In the XKB format, floats and various keywords can only be used in the
xkb_geometry section. xkbcommon removed support xkb_geometry, but still
parses it for backward compatibility. As part of ignoring it, the float
AST node and various keywords were removed, and instead NULL was
returned by their parsing actions. However, the rest of the code does
not handle NULLs, and so when they appear crashes usually ensue.

To fix this, restore the float AST node and the ignored keywords. None
of the evaluating code expects them, so nice error are displayed.

Caught with the afl fuzzer.

Signed-off-by: Ran Benita <ran234@gmail.com>


Vulnerable code:
                        { $$ = XKB_ATOM_NONE; }
                        { $$ = XKB_ATOM_NONE; }
                        { $$ = XKB_ATOM_NONE; }
                        { $$ = XKB_ATOM_NONE; }
                        { $$ = NULL; }

Fixed code:
ExprDef *
ExprCreateFloat(void)
{
    EXPR_CREATE(ExprFloat, expr, EXPR_VALUE, EXPR_TYPE_FLOAT);
    return expr;
}

    [EXPR_TYPE_FLOAT] = "float",
ExprDef *
ExprCreateFloat(void);

    EXPR_TYPE_FLOAT,
typedef struct {
    ExprCommon expr;
    /* We don't support floats, but we still represnt them in the AST, in
     * order to provide proper error messages. */
} ExprFloat;

                        { $$ = xkb_atom_intern_literal(param->ctx, "shape"); }
                        { $$ = xkb_atom_intern_literal(param->ctx, "row"); }
                        { $$ = xkb_atom_intern_literal(param->ctx, "section"); }
                        { $$ = xkb_atom_intern_literal(param->ctx, "text"); }
                        { $$ = ExprCreateFloat(/* Discard $1 */); }
CVE-2018-15855 (C, published 2018-08-25T21:29Z)
Description: value: Unchecked NULL pointer usage in xkbcommon before 0.8.1 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file, because the XkbFile for an xkb_geometry section was mishandled.
Severity: LOW (CVSS v3 base score: 5.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/xkbcommon/libxkbcommon
Files changed:
src/xkbcomp/keymap.c
src/xkbcomp/parser.y
Commit message: xkbcomp: fix crash when parsing an xkb_geometry section

xkb_geometry sections are ignored; previously the had done so by
returning NULL for the section's XkbFile, however some sections of the
code do not expect this. Instead, create an XkbFile for it, it will
never be processes and discarded later.

Caught with the afl fuzzer.

Signed-off-by: Ran Benita <ran234@gmail.com>


Vulnerable code:
            log_err(ctx, "Cannot define %s in a keymap file\n",
                    xkb_file_type_to_string(file->file_type));
                            if ($2 == FILE_TYPE_GEOMETRY) {
                                free($3);
                                FreeStmt($5);
                                $$ = NULL;
                            }
                            else {
                                $$ = XkbFileCreate($2, $3, $5, $1);
                            }

Fixed code:
            if (file->file_type == FILE_TYPE_GEOMETRY) {
                log_vrb(ctx, 1,
                        "Geometry sections are not supported; ignoring\n");
            } else {
                log_err(ctx, "Cannot define %s in a keymap file\n",
                        xkb_file_type_to_string(file->file_type));
            }
                            $$ = XkbFileCreate($2, $3, $5, $1);
CVE-2018-15856 (C, published 2018-08-25T21:29Z)
Description: value: An infinite loop when reaching EOL unexpectedly in compose/parser.c (aka the keymap parser) in xkbcommon before 0.8.1 could be used by local attackers to cause a denial of service during parsing of crafted keymap files.
Severity: LOW (CVSS v3 base score: 5.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/xkbcommon/libxkbcommon
Files changed:
src/compose/parser.c
Commit message: compose: fix infinite loop in parser on some inputs

The parser would enter an infinite loop if an unterminated keysym
literal occurs at EOF.

Found with the afl fuzzer.

Signed-off-by: Ran Benita <ran234@gmail.com>


Vulnerable code:
        while (peek(s) != '>' && !eol(s))

Fixed code:
        while (peek(s) != '>' && !eol(s) && !eof(s))
CVE-2018-15857 (C, published 2018-08-25T21:29Z)
Description: value: An invalid free in ExprAppendMultiKeysymList in xkbcomp/ast-build.c in xkbcommon before 0.8.1 could be used by local attackers to crash xkbcommon keymap parsers or possibly have unspecified other impact by supplying a crafted keymap file.
Severity: MEDIUM (CVSS v3 base score: 7.8)
Weakness: CWE-416 \u2014 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Repository: https://github.com/xkbcommon/libxkbcommon
Files changed:
src/xkbcomp/ast-build.c
Commit message: xkbcomp: fix pointer value for FreeStmt

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>


Vulnerable code:
    FreeStmt((ParseCommon *) &append);

Fixed code:
    FreeStmt((ParseCommon *) append);
CVE-2018-15858 (C, published 2018-08-25T21:29Z)
Description: value: Unchecked NULL pointer usage when handling invalid aliases in CopyKeyAliasesToKeymap in xkbcomp/keycodes.c in xkbcommon before 0.8.1 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file.
Severity: LOW (CVSS v3 base score: 5.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/xkbcommon/libxkbcommon
Files changed:
src/xkbcomp/keycodes.c
Commit message: keycodes: don't try to copy zero key aliases

Move the aliases copy to within the (num_key_aliases > 0) block.

Passing info->aliases into this fuction with invalid aliases will
cause log messages but num_key_aliases stays on 0. The key_aliases array
is never allocated and remains NULL. We then loop through the aliases, causing
a null-pointer dereference.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>


Vulnerable code:
    }
    i = 0;
    darray_foreach(alias, info->aliases) {
        if (alias->real != XKB_ATOM_NONE) {
            key_aliases[i].alias = alias->alias;
            key_aliases[i].real = alias->real;
            i++;

Fixed code:
        i = 0;
        darray_foreach(alias, info->aliases) {
            if (alias->real != XKB_ATOM_NONE) {
                key_aliases[i].alias = alias->alias;
                key_aliases[i].real = alias->real;
                i++;
            }
CVE-2018-15859 (C, published 2018-08-25T21:29Z)
Description: value: Unchecked NULL pointer usage when parsing invalid atoms in ExprResolveLhs in xkbcomp/expr.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file, because lookup failures are mishandled.
Severity: LOW (CVSS v3 base score: 5.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/xkbcommon/libxkbcommon
Files changed:
src/xkbcomp/expr.c
Commit message: Fail expression lookup on invalid atoms

If we fail atom lookup, then we should not claim that we successfully
looked up the expression.

Signed-off-by: Daniel Stone <daniels@collabora.com>


Vulnerable code:
        return true;

Fixed code:
        return (*elem_rtrn != NULL && *field_rtrn != NULL);
	if (expr->array_ref.element != XKB_ATOM_NONE && *elem_rtrn == NULL)
		return false;
	if (*field_rtrn == NULL)
		return false;
CVE-2018-15861 (C, published 2018-08-25T21:29Z)
Description: value: Unchecked NULL pointer usage in ExprResolveLhs in xkbcomp/expr.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file that triggers an xkb_intern_atom failure.
Severity: LOW (CVSS v3 base score: 5.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/xkbcommon/libxkbcommon
Files changed:
src/xkbcomp/expr.c
Commit message: xkbcomp: Don't falsely promise from ExprResolveLhs

Every user of ExprReturnLhs goes on to unconditionally dereference the
field return, which can be NULL if xkb_intern_atom fails. Return false
if this is the case, so we fail safely.

testcase: splice geometry data into interp

Signed-off-by: Daniel Stone <daniels@collabora.com>


Vulnerable code:
        return true;

Fixed code:
        return (*field_rtrn != NULL);
CVE-2018-15862 (C, published 2018-08-25T21:29Z)
Description: value: Unchecked NULL pointer usage in LookupModMask in xkbcomp/expr.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file with invalid virtual modifiers.
Severity: LOW (CVSS v3 base score: 5.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/xkbcommon/libxkbcommon
Files changed:
src/xkbcomp/expr.c
Commit message: xkbcomp: Don't explode on invalid virtual modifiers

testcase: 'virtualModifiers=LevelThreC'

Signed-off-by: Daniel Stone <daniels@collabora.com>


Vulnerable code:

Fixed code:
    if (!str)
        return false;
CVE-2018-15863 (C, published 2018-08-25T21:29Z)
Description: value: Unchecked NULL pointer usage in ResolveStateAndPredicate in xkbcomp/compat.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file with a no-op modmask expression.
Severity: LOW (CVSS v3 base score: 5.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/xkbcommon/libxkbcommon
Files changed:
src/xkbcomp/compat.c
Commit message: xkbcomp: Don't crash on no-op modmask expressions

If we have an expression of the form 'l1' in an interp section, we
unconditionally try to dereference its args, even if it has none.

Signed-off-by: Daniel Stone <daniels@collabora.com>


Vulnerable code:
        if (!LookupString(symInterpretMatchMaskNames, pred_txt, pred_rtrn)) {

Fixed code:
        if (!LookupString(symInterpretMatchMaskNames, pred_txt, pred_rtrn) ||
            !expr->action.args) {
CVE-2018-15864 (Other, published 2018-08-25T21:29Z)
Description: value: Unchecked NULL pointer usage in resolve_keysym in xkbcomp/parser.y in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file, because a map access attempt can occur for a map that was never created.
Severity: LOW (CVSS v3 base score: 5.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/xkbcommon/libxkbcommon
Files changed:
src/xkbcomp/parser.y
Commit message: parser: Don't set more maps when we don't have any

If the scanner indicates that we might have something which looks like a
map, but the parser in fact fails to create that map, we will try to
access the map regardless. Stop doing that.

testcase: 'xkb_keymap {' -> '#kb_keymap'

Signed-off-by: Daniel Stone <daniels@collabora.com>


Vulnerable code:
                        { $$ = param->rtrn = $1; param->more_maps = true; }
                        { $$ = param->rtrn = $1; param->more_maps = true; YYACCEPT; }

Fixed code:
                        { $$ = param->rtrn = $1; param->more_maps = !!param->rtrn; }
                        { $$ = param->rtrn = $1; param->more_maps = !!param->rtrn; YYACCEPT; }
        .more_maps = false,
CVE-2022-1440 (JSON, published 2022-04-22T18:15Z)
Description: value: Command Injection vulnerability in git-interface@2.1.1 in GitHub repository yarkeev/git-interface prior to 2.1.2. If both are provided by user input, then the use of a `--upload-pack` command-line argument feature of git is also supported for `git clone`, which would then allow for any operating system command to be spawned by the attacker.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-78 \u2014 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.
Repository: https://github.com/yarkeev/git-interface
Files changed:
package.json
src/index.ts
Commit message: fix potential vulnerability with git clone


Vulnerable code:
	"version": "2.1.1",
		"prepublish": "npm run build"
		"typescript": "^3.0.3"

		const depthOption = opt.depth !== Infinity ? ` --depth=${opt.depth}` : '';

		return this.gitExec(`clone ${repository} ${dest}${depthOption}`);
}

Fixed code:
	"version": "2.1.2",
		"prepublishOnly": "npm run build && bump"
		"typescript": "^3.0.3",
		"version-bump-prompt": "^6.1.0"
		const depthOption = opt.depth !== Infinity ? `--depth=${opt.depth}` : '';
		return this.gitExec(`clone ${depthOption} -- ${repository} ${dest}`);
}