hitoshura25/cvefixes huggingface dataset:
CVE-2023-6395 (Python, published 2024-01-16T15:15Z)
Description: value: The Mock software contains a vulnerability wherein an attacker could potentially exploit privilege escalation, enabling the execution of arbitrary code with root user privileges. This weakness stems from the absence of proper sandboxing during the expansion and execution of Jinja2 templates, which may be included in certain configuration parameters. While the Mock documentation advises treating users added to the mock group as privileged, certain build systems invoking mock on behalf of users might inadvertently permit less privileged users to define configuration tags. These tags could then be passed as parameters to mock during execution, potentially leading to the utilization of Jinja2 templates for remote privilege escalation and the execution of arbitrary code as the root user on the build server.
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/xsuchy/templated-dictionary
Files changed:
templated_dictionary/__init__.py
Commit message: Make the TemplatedDictionary objects picklable

The jinja2 SandboxedEnvironment objects are not guaranteed to be
pickle-serializable (even though they practically are).  So let's rather
store the environment elsewhere than in the TemplatedDictionary object
itself to keep it serializable.

Nb. TemplatedDictionary is just a wrapper around dict, which is quite
commonly subject of (de)serialization (e.g. Mock, the main user of
templated-dictionary library does that through the
concurrent.futures.ProcessPoolExecutor logic).

It would be disadvantageous to introduce additional internal arguments
into the object itself (considering we already have the __jinja_expand
internal).

Having a per-application shared environment is kind of expected anyway
(and even more optimal):

    https://jinja.palletsprojects.com/en/3.0.x/api/#basics

Note that this fix is mostly needed for the RHEL 8 environment with
jinja2 v2.10.1; newer versions made the environments (namely the
included filters) picklable: https://github.com/pallets/jinja/pull/1613


Vulnerable code:
        self.sandbox = sandbox.SandboxedEnvironment(keep_trailing_newline=True)

            value = _to_native(self.sandbox.from_string(value).render(self.__dict__, func=lambda:None))

Fixed code:
SANDBOX = sandbox.SandboxedEnvironment(keep_trailing_newline=True)
            value = _to_native(SANDBOX.from_string(value).render(self.__dict__, func=lambda:None))
CVE-2023-6395 (Python, published 2024-01-16T15:15Z)
Description: value: The Mock software contains a vulnerability wherein an attacker could potentially exploit privilege escalation, enabling the execution of arbitrary code with root user privileges. This weakness stems from the absence of proper sandboxing during the expansion and execution of Jinja2 templates, which may be included in certain configuration parameters. While the Mock documentation advises treating users added to the mock group as privileged, certain build systems invoking mock on behalf of users might inadvertently permit less privileged users to define configuration tags. These tags could then be passed as parameters to mock during execution, potentially leading to the utilization of Jinja2 templates for remote privilege escalation and the execution of arbitrary code as the root user on the build server.
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/xsuchy/templated-dictionary
Files changed:
templated_dictionary/__init__.py
Commit message: Use a sandboxed jinja2 environment

The task of templated_dictionary object is pretty simple, it just
expands precisely defined set of templates (dictionary attributes).
Having a full power of Python interpreter in templates doesn't seem to
make any sense.  So let's make the library safer.


Vulnerable code:
import jinja2
            template = jinja2.Template(value, keep_trailing_newline=True)
            value = _to_native(template.render(self.__dict__))

Fixed code:
from jinja2 import sandbox
        self.sandbox = sandbox.SandboxedEnvironment(keep_trailing_newline=True)

            value = _to_native(self.sandbox.from_string(value).render(self.__dict__, func=lambda:None))
CVE-2017-6511 (PHP, published 2017-03-07T19:59Z)
Description: value: andrzuk/FineCMS before 2017-03-06 is vulnerable to a reflected XSS in index.php because of missing validation of the action parameter in application/classes/application.php.
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
Repository: https://github.com/andrzuk/FineCMS
Files changed:
application/classes/application.php
application/core/view/roles.php
application/core/view/users.php
Commit message: Add filtration of URL action parameter.


Vulnerable code:
		$class_method = ucfirst($action) . '_Action';
			array('width' => '5%',  'align' => 'center', 'visible' => '1'),
			array('width' => '10%', 'align' => 'center', 'visible' => '1', 'image' => '1'),
			array('width' => '15%', 'align' => 'center', 'visible' => '1'),
			array('width' => '10%', 'align' => 'center', 'visible' => '1'),
			array('width' => '50%', 'align' => 'center', 'visible' => '1'),
			array('width' => '8%', 'align' => 'left',   'visible' => '1', 'image' => '1'),
			array('width' => '5%',  'align' => 'left',   'visible' => '0'),
			array('width' => '8%', 'align' => 'left',   'visible' => '1'),
			array('width' => '10%', 'align' => 'left', 'visible' => '1'),
			array('width' => '5%',  'align' => 'center', 'visible' => '1'),
			array('width' => '5%', 'align' => 'center', 'visible' => '1'),
			array('width' => '5%', 'align' => 'center', 'visible' => '1'),

Fixed code:
		$class_method = ucfirst(strip_tags($action)) . '_Action';
			array('width' => '10%',  'align' => 'center', 'visible' => '1'),
			array('width' => '15%', 'align' => 'left', 'visible' => '1', 'image' => '1'),
			array('width' => '20%', 'align' => 'left', 'visible' => '1'),
			array('width' => '10%', 'align' => 'left', 'visible' => '1'),
			array('width' => '30%', 'align' => 'left', 'visible' => '1'),
			array('width' => '10%', 'align' => 'left',   'visible' => '1', 'image' => '1'),
			array('width' => '10%',  'align' => 'left',   'visible' => '0'),
			array('width' => '10%', 'align' => 'left',   'visible' => '1'),
			array('width' => '25%', 'align' => 'left', 'visible' => '1'),
			array('width' => '5%',  'align' => 'left', 'visible' => '1'),
			array('width' => '5%', 'align' => 'center', 'visible' => '0'),
			array('width' => '5%', 'align' => 'center', 'visible' => '0'),
CVE-2021-43798 (Go, published 2021-12-07T19:15Z)
Description: value: Grafana is an open-source platform for monitoring and observability. Grafana versions 8.0.0-beta1 through 8.3.0 (except for patched versions) iss vulnerable to directory traversal, allowing access to local files. The vulnerable URL path is: `<grafana_host_url>/public/plugins//`, where is the plugin ID for any installed plugin. At no time has Grafana Cloud been vulnerable. Users are advised to upgrade to patched versions 8.0.7, 8.1.8, 8.2.7, or 8.3.1. The GitHub Security Advisory contains more information about vulnerable URL paths, mitigation, and the disclosure timeline.
Severity: MEDIUM (CVSS v3 base score: 7.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/grafana/grafana
Files changed:
pkg/api/plugins.go
pkg/api/plugins_test.go
Commit message: Security: Fix directory traversal issue (#42846)

* security: fix dir traversal issue

(cherry picked from commit 00e38ba555cfb120361c9623de3285d70c60172f)

* Improve comments and error message.

Co-authored-by: Kyle Brandt <kyle@grafana.com>

Vulnerable code:
	requestedFile := filepath.Clean(web.Params(c.Req)["*"])
	pluginFilePath := filepath.Join(plugin.PluginDir, requestedFile)
	if !plugin.IncludedInSignature(requestedFile) {

Fixed code:
	// prepend slash for cleaning relative paths
	requestedFile := filepath.Clean(filepath.Join("/", web.Params(c.Req)["*"]))
	rel, err := filepath.Rel("/", requestedFile)
	if err != nil {
		// slash is prepended above therefore this is not expected to fail
		c.JsonApiErr(500, "Failed to get the relative path", err)
		return
	}
	if !plugin.IncludedInSignature(rel) {
	absPluginDir, err := filepath.Abs(plugin.PluginDir)
	if err != nil {
		c.JsonApiErr(500, "Failed to get plugin absolute path", nil)
		return
	}

	pluginFilePath := filepath.Join(absPluginDir, rel)
	tmpFileInParentDir, err := ioutil.TempFile("..", "")
	require.NoError(t, err)
		err = os.RemoveAll(tmpFileInParentDir.Name())
		assert.NoError(t, err)
	t.Run("Given a request for a relative path", func(t *testing.T) {
		p := plugins.PluginDTO{
			JSONData: plugins.JSONData{
				ID: pluginID,
			},
			PluginDir: pluginDir,
		}
		service := &fakePluginStore{
			plugins: map[string]plugins.PluginDTO{
				pluginID: p,
			},
		}
		l := &logger{}

		url := fmt.Sprintf("/public/plugins/%s/%s", pluginID, tmpFileInParentDir.Name())
		pluginAssetScenario(t, "When calling GET on", url, "/public/plugins/:pluginId/*", service, l,
			func(sc *scenarioContext) {
				callGetPluginAsset(sc)

				require.Equal(t, 404, sc.resp.Code)
			})
	})
CVE-2019-9578 (C, published 2019-03-05T23:29Z)
Description: value: In devs.c in Yubico libu2f-host before 1.1.8, the response to init is misparsed, leaking uninitialized stack memory back to the device.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-908 \u2014 Use of Uninitialized Resource
The product uses or accesses a resource that has not been initialized.
Repository: https://github.com/Yubico/libu2f-host
Files changed:
u2f-host/devs.c
Commit message: fix filling out of initresp


Vulnerable code:
      U2FHID_INIT_RESP initresp;
      if (resplen > sizeof (initresp))
	  return U2FH_MEMORY_ERROR;
      memcpy (&initresp, resp, resplen);
      dev->cid = initresp.cid;
      dev->versionInterface = initresp.versionInterface;
      dev->versionMajor = initresp.versionMajor;
      dev->versionMinor = initresp.versionMinor;
      dev->capFlags = initresp.capFlags;

Fixed code:
      int offs = sizeof (nonce);
      /* the response has to be atleast 17 bytes, if it's more we discard that */
      if (resplen < 17)
	  return U2FH_SIZE_ERROR;

      /* incoming and outgoing nonce has to match */
      if (memcmp (nonce, resp, sizeof (nonce)) != 0)
	{
	  return U2FH_TRANSPORT_ERROR;
	}

      dev->cid =
	resp[offs] << 24 | resp[offs + 1] << 16 | resp[offs +
						       2] << 8 | resp[offs +
								      3];
      offs += 4;
      dev->versionInterface = resp[offs++];
      dev->versionMajor = resp[offs++];
      dev->versionMinor = resp[offs++];
      dev->versionBuild = resp[offs++];
      dev->capFlags = resp[offs++];
CVE-2023-34092 (TypeScript, published 2023-06-01T17:15Z)
Description: value: Vite provides frontend tooling. Prior to versions 2.9.16, 3.2.7, 4.0.5, 4.1.5, 4.2.3, and 4.3.9, Vite Server Options (`server.fs.deny`) can be bypassed using double forward-slash (//) allows any unauthenticated user to read file from the Vite root-path of the application including the default `fs.deny` settings (`['.env', '.env.*', '*.{crt,pem}']`). Only users explicitly exposing the Vite dev server to the network (using `--host` or `server.host` config option) are affected, and only files in the immediate Vite project root folder could be exposed. This issue is fixed in vite@4.3.9, vite@4.2.3, vite@4.1.5, vite@4.0.5, vite@3.2.7, and vite@2.9.16.
Severity: nan (CVSS v3 base score: 7.5)
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/vitejs/vite
Files changed:
packages/vite/src/node/server/middlewares/static.ts
playground/assets-sanitize/.env
playground/assets-sanitize/__tests__/assets-sanitize.spec.ts
playground/assets-sanitize/index.html
Commit message: fix: fs.deny with leading double slash (#13348)



Vulnerable code:
    const url = new URL(req.url!, 'http://example.com')
    const url = new URL(req.url!, 'http://example.com')
<h1>test elements below should show circles and their url</h1>

Fixed code:
    const url = new URL(req.url!.replace(/^\/+/, '/'), 'http://example.com')
    const url = new URL(req.url!.replace(/^\/+/, '/'), 'http://example.com')
KEY=unsafe

test.runIf(!isBuild)('denied .env', async () => {
  expect(await page.textContent('.unsafe-dotenv')).toBe('403')
  expect(await page.textContent('.unsafe-dotenv-double-slash')).toBe('403')
})
<h3>test elements below should show circles and their url</h3>

<h3>Denied .env</h3>
<div class="unsafe-dotenv"></div>
<div class="unsafe-dotenv-double-slash"></div>

<script type="module">
  // .env, denied by default. See fs-serve playground for other fs tests
  // these checks ensure that a project without a custom root respects fs.deny

  fetch('/.env')
    .then((r) => {
      text('.unsafe-dotenv', r.status)
    })
    .catch((e) => {
      console.error(e)
    })

  fetch(window.location + '/.env')
    .then((r) => {
      text('.unsafe-dotenv-double-slash', r.status)
    })
    .catch((e) => {
      console.error(e)
    })

  function text(el, text) {
    document.querySelector(el).textContent = text
  }
</script>
CVE-2024-31207 (TypeScript, published 2024-04-04T16:15Z)
Description: value: Vite (French word for "quick", pronounced /vit/, like "veet") is a frontend build tooling to improve the frontend development experience.`server.fs.deny` does not deny requests for patterns with directories. This vulnerability has been patched in version(s) 5.2.6, 5.1.7, 5.0.13, 4.5.3, 3.2.10 and 2.9.18.
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/vitejs/vite
Files changed:
packages/vite/src/node/server/index.ts
playground/fs-serve/__tests__/deny/fs-serve-deny.spec.ts
playground/fs-serve/package.json
playground/fs-serve/root/src/deny/.deny
playground/fs-serve/root/src/deny/deny.txt
playground/fs-serve/root/vite.config-deny.js
Commit message: fix: `fs.deny` with globs with directories (#16250)



Vulnerable code:
    _fsDenyGlob: picomatch(config.server.fs.deny, {
      matchBase: true,
      nocase: true,
    }),
    "preview:base": "vite preview root --config ./root/vite.config-base.js"

Fixed code:
    _fsDenyGlob: picomatch(
      // matchBase: true does not work as it's documented
      // https://github.com/micromatch/picomatch/issues/89
      // convert patterns without `/` on our side for now
      config.server.fs.deny.map((pattern) =>
        pattern.includes('/') ? pattern : `**/${pattern}`,
      ),
      {
        matchBase: false,
        nocase: true,
        dot: true,
      },
    ),
import { describe, expect, test } from 'vitest'
import { isServe, page, viteTestUrl } from '~utils'

describe.runIf(isServe)('main', () => {
  test('**/deny/** should deny src/deny/deny.txt', async () => {
    const res = await page.request.fetch(
      new URL('/src/deny/deny.txt', viteTestUrl).href,
    )
    expect(res.status()).toBe(403)
  })
  test('**/deny/** should deny src/deny/.deny', async () => {
    const res = await page.request.fetch(
      new URL('/src/deny/.deny', viteTestUrl).href,
    )
    expect(res.status()).toBe(403)
  })
})
    "preview:base": "vite preview root --config ./root/vite.config-base.js",
    "dev:deny": "vite root --config ./root/vite.config-deny.js",
    "build:deny": "vite build root --config ./root/vite.config-deny.js",
    "preview:deny": "vite preview root --config ./root/vite.config-deny.js"
.deny
deny
import path from 'node:path'
import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    rollupOptions: {
      input: {
        main: path.resolve(__dirname, 'src/index.html'),
      },
    },
  },
  server: {
    fs: {
      strict: true,
      allow: [path.resolve(__dirname, 'src')],
      deny: ['**/deny/**'],
    },
  },
  define: {
    ROOT: JSON.stringify(path.dirname(__dirname).replace(/\\/g, '/')),
  },
})
CVE-2023-51652 (C#, published 2024-01-02T20:15Z)
Description: value: OWASP AntiSamy .NET is a library for performing cleansing of HTML coming from untrusted sources. Prior to version 1.2.0, there is a potential for a mutation cross-site scripting (mXSS) vulnerability in AntiSamy caused by flawed parsing of the HTML being sanitized. To be subject to this vulnerability the `preserveComments` directive must be enabled in your policy file and also allow for certain tags at the same time. As a result, certain crafty inputs can result in elements in comment tags being interpreted as executable when using AntiSamy's sanitized output. This is patched in OWASP AntiSamy .NET 1.2.0 and later. See important remediation details in the reference given below. As a workaround, manually edit the AntiSamy policy file (e.g., antisamy.xml) by deleting the `preserveComments` directive or setting its value to `false`,  if present. Also it would be useful to make AntiSamy remove the `noscript` tag by adding a line described in the GitHub Security Advisory to the tag definitions under the `<tagrules>` node, or deleting it entirely if present. As the previously mentioned policy settings are preconditions for the mXSS attack to work, changing them as recommended should be sufficient to protect you against this vulnerability when using a vulnerable version of this library. However, the existing bug would still be present in AntiSamy or its parser dependency (HtmlAgilityPack). The safety of this workaround relies on configurations that may change in the future and don't address the root cause of the vulnerability. As such, it is strongly recommended to upgrade to a fixed version of AntiSamy.
Severity: nan (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
Repository: https://github.com/spassarop/antisamy-dotnet
Files changed:
OWASP.AntiSamyTests/Html/AntiSamyTest.cs
Commit message: Add more tests for mXSS


Vulnerable code:

Fixed code:
            antisamy.Scan("<style/><listing/>]]><noembed></style><img src=x onerror=mxss(1)></noembed>", policy).GetCleanHtml()
               .Should().NotContain("mxss");
            antisamy.Scan("<style/><math>'<noframes ></style><img src=x onerror=mxss(1)></noframes>'", policy).GetCleanHtml()
               .Should().NotContain("mxss");
CVE-2017-6903 (C, published 2017-03-14T22:59Z)
Description: value: In ioquake3 before 2017-03-14, the auto-downloading feature has insufficient content restrictions. This also affects Quake III Arena, OpenArena, OpenJK, iortcw, and other id Tech 3 (aka Quake 3 engine) forks. A malicious auto-downloaded file can trigger loading of crafted auto-downloaded files as native code DLLs. A malicious auto-downloaded file can contain configuration defaults that override the user's. Executable bytecode in a malicious auto-downloaded file can set configuration variables to values that will result in unwanted native code DLLs being loaded, resulting in sandbox escape.
Severity: HIGH (CVSS v3 base score: 7.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/ioquake/ioq3
Files changed:
code/client/snd_openal.c
Commit message: Don't open .pk3 files as OpenAL drivers.


Vulnerable code:
	s_alDriver = Cvar_Get( "s_alDriver", ALDRIVER_DEFAULT, CVAR_ARCHIVE | CVAR_LATCH );

Fixed code:
	s_alDriver = Cvar_Get( "s_alDriver", ALDRIVER_DEFAULT, CVAR_ARCHIVE | CVAR_LATCH | CVAR_PROTECTED );
	if ( COM_CompareExtension( s_alDriver->string, ".pk3" ) )
	{
		Com_Printf( "Rejecting DLL named \"%s\"", s_alDriver->string );
		return qfalse;
	}
CVE-2017-6903 (C, published 2017-03-14T22:59Z)
Description: value: In ioquake3 before 2017-03-14, the auto-downloading feature has insufficient content restrictions. This also affects Quake III Arena, OpenArena, OpenJK, iortcw, and other id Tech 3 (aka Quake 3 engine) forks. A malicious auto-downloaded file can trigger loading of crafted auto-downloaded files as native code DLLs. A malicious auto-downloaded file can contain configuration defaults that override the user's. Executable bytecode in a malicious auto-downloaded file can set configuration variables to values that will result in unwanted native code DLLs being loaded, resulting in sandbox escape.
Severity: HIGH (CVSS v3 base score: 7.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/ioquake/ioq3
Files changed:
code/client/cl_console.c
code/qcommon/common.c
Commit message: Merge some file writing extension checks from OpenJK.

Thanks Ensiform.
https://github.com/JACoders/OpenJK/commit/05928a57f9e4aae15a3bd0
https://github.com/JACoders/OpenJK/commit/ef124fd0fc48af164581176


Vulnerable code:

Fixed code:
	if (!COM_CompareExtension(filename, ".txt"))
	{
		Com_Printf("Con_Dump_f: Only the \".txt\" extension is supported by this command!\n");
		return;
	}


	if (!COM_CompareExtension(filename, ".cfg"))
	{
		Com_Printf("Com_WriteConfig_f: Only the \".cfg\" extension is supported by this command!\n");
		return;
	}
CVE-2017-6903 (C, published 2017-03-14T22:59Z)
Description: value: In ioquake3 before 2017-03-14, the auto-downloading feature has insufficient content restrictions. This also affects Quake III Arena, OpenArena, OpenJK, iortcw, and other id Tech 3 (aka Quake 3 engine) forks. A malicious auto-downloaded file can trigger loading of crafted auto-downloaded files as native code DLLs. A malicious auto-downloaded file can contain configuration defaults that override the user's. Executable bytecode in a malicious auto-downloaded file can set configuration variables to values that will result in unwanted native code DLLs being loaded, resulting in sandbox escape.
Severity: HIGH (CVSS v3 base score: 7.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/ioquake/ioq3
Files changed:
code/client/cl_main.c
code/qcommon/files.c
code/sys/sys_main.c
Commit message: Don't load .pk3s as .dlls, and don't load user config files from .pk3s.


Vulnerable code:
	cl_renderer = Cvar_Get("cl_renderer", "opengl2", CVAR_ARCHIVE | CVAR_LATCH);
	cl_cURLLib = Cvar_Get("cl_cURLLib", DEFAULT_CURL_LIB, CVAR_ARCHIVE);

Fixed code:
	cl_renderer = Cvar_Get("cl_renderer", "opengl2", CVAR_ARCHIVE | CVAR_LATCH | CVAR_PROTECTED);
	cl_cURLLib = Cvar_Get("cl_cURLLib", DEFAULT_CURL_LIB, CVAR_ARCHIVE | CVAR_PROTECTED);
	qboolean isLocalConfig;
	isLocalConfig = !strcmp(filename, "autoexec.cfg") || !strcmp(filename, Q3CONFIG_CFG);
		// autoexec.cfg and q3config.cfg can only be loaded outside of pk3 files.
		if (isLocalConfig && search->pack)
			continue;

	// Don't load any DLLs that end with the pk3 extension
	if (COM_CompareExtension(name, ".pk3"))
	{
		Com_Printf("Rejecting DLL named \"%s\"", name);
		return NULL;
	}