Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
e heap bound is larger than 2GiB, then it would be possible to read memory from a computable range dependent on the size of the heaps bound. The impact of this bug is highly dependent on heap implementation, specifically: * if the heap has bounds checks, and * does not rely exclusively on guard pages, and * the heap bound is 2GiB or smaller * then this bug cannot be used to reach memory from another Wasm program heap. The impact of the vulnerability is mitigated if there is no memory mapped in the range accessible using this bug, for example, if there is a 2 GiB guard region before the Wasm program heap. The bug in question performs a sign-extend instead of a zero-extend on a value loaded fr
n before the Wasm program heap. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, when the register allocator reloads a spilled integer value narrower than 64 bits. This interacts poorly with another optimization: the instruction selector elides a 32-to-64-bit zero-extend operator when we know that an instruction producing a 32-bit value actually zeros the upper 32 bits of its destination register. Hence, we rely on these zeroed bits, but the type of the value is still i32, and the spill/reload reconstitutes those bits as the sign extension of the i32’s MSB. The issue would thus occur when: * An i32 value in a Wasm program is greater than o
the sign extension of the i32’s MSB. The issue would thus occur when: * An i32 value in a Wasm program is greater than or equal to 0x8000_0000; * The value is spilled and reloaded by the register allocator due to high register pressure in the program between the value’s definition and its use; * The value is produced by an instruction that we know to be “special” in that it zeroes the upper 32 bits of its destination: add, sub, mul, and, or; * The value is then zero-extended to 64 bits in the Wasm program; * The resulting 64-bit value is used. Under these circumstances there is a potential sandbox escape when the i32 value is a pointer. The usual code emitted for heap accesses zero-extends t
e is a potential sandbox escape when the i32 value is a pointer. The usual code emitted for heap accesses zero-extends the Wasm heap address, adds it to a 64-bit heap base, and accesses the resulting address. If the zero-extend becomes a sign-extend, the program could reach backward and access memory up to 2GiB before the start of its heap. In addition to assessing the nature of the code generation bug in Cranelift, we have also determined that under specific circumstances, both Lucet and Wasmtime using this version of Cranelift may be exploitable. See referenced GitHub Advisory for more details. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/bytecodealli
isory for more details. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5 - https://github.com/bytecodealliance/wasmtime/commit/95559c01aaa7c061088a433040f31e8291fb09d0 - https://crates.io/crates/cranelift-codegen - https://www.fastly.com/security-advisories/memory-access-due-to-code-generation-flaw-in-cranelift-module
CVE ID: CVE-2021-32630 State: PUBLISHED Published: 2021-05-20T16:45:12 Last Updated: 2024-08-03T23:25:30.558Z Severity: CRITICAL (CVSS 9.6 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) Vendors: Admidio Products: admidio Problem Types: CWE-434 Description: Admidio is a free, open source user management system for websites of organizations and groups. In Admidio before version 4.0.4, there is an authenticated RCE via .phar file upload. A php web shell can be uploaded via the Documents & Files upload feature. Someone with upload permissions could rename the php shell with a .phar extension, visit the file, triggering the payload for a reverse/bind shell. This can be mitigated by excluding a .ph
har extension, visit the file, triggering the payload for a reverse/bind shell. This can be mitigated by excluding a .phar file extension to be uploaded (like you did with .php .phtml .php5 etc). The vulnerability is patched in version 4.0.4. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/Admidio/admidio/security/advisories/GHSA-xpqj-67r8-25j2 - https://github.com/Admidio/admidio/issues/994 - https://github.com/Admidio/admidio/releases/tag/v4.0.4
CVE ID: CVE-2021-32631 State: PUBLISHED Published: 2021-07-26T15:20:11 Last Updated: 2024-08-03T23:25:31.016Z Severity: MEDIUM (CVSS 6.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) Vendors: nimble-platform Products: common Problem Types: CWE-290 Description: Common is a package of common modules that can be accessed by NIMBLE services. Common before commit number 3b96cb0293d3443b870351945f41d7d55cb34b53 did not properly verify the signature of JSON Web Tokens. This allows someone to forge a valid JWT. Being able to forge JWTs may lead to authentication bypasses. Commit number 3b96cb0293d3443b870351945f41d7d55cb34b53 contains a patch for the issue. As a workaround, one may use the parseClai
mber 3b96cb0293d3443b870351945f41d7d55cb34b53 contains a patch for the issue. As a workaround, one may use the parseClaimsJws method to correctly verify the signature of a JWT. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/nimble-platform/common/security/advisories/GHSA-fjq8-896w-pv28 - https://github.com/nimble-platform/common/commit/12197a755bd524559bf4e16475595a2c6fcd34db - https://github.com/nimble-platform/common/commit/3b96cb0293d3443b870351945f41d7d55cb34b53 - https://github.com/nimble-platform/common/commit/a59ad46733912a5580530e39cac0e6ebc83cc563
CVE ID: CVE-2021-32632 State: PUBLISHED Published: 2021-05-20T16:10:11 Last Updated: 2024-08-03T23:25:30.954Z Severity: LOW (CVSS 2.4 CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:N) Vendors: pajbot Products: pajbot Problem Types: CWE-352 Description: Pajbot is a Twitch chat bot. Pajbot versions prior to 1.52 are vulnerable to cross-site request forgery (CSRF). Hosters of the bot should upgrade to `v1.52` or `stable` to install the patch or, as a workaround, can add one modern dependency. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/pajbot/pajbot/security/advisories/GHSA-wmfr-qrg4-qc3h - https://gist.github.com/Melonify/d8e5d70cdc1bebb871f72dc79d69ac60 - h
t/pajbot/security/advisories/GHSA-wmfr-qrg4-qc3h - https://gist.github.com/Melonify/d8e5d70cdc1bebb871f72dc79d69ac60 - https://github.com/pajbot/pajbot/releases/tag/v1.52
CVE ID: CVE-2021-32633 State: PUBLISHED Published: 2021-05-21T13:55:10 Last Updated: 2024-08-03T23:25:30.947Z Severity: MEDIUM (CVSS 6.8 CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N) Vendors: zopefoundation Products: Zope Problem Types: CWE-22 Description: Zope is an open-source web application server. In Zope versions prior to 4.6 and 5.2, users can access untrusted modules indirectly through Python modules that are available for direct use. By default, only users with the Manager role can add or edit Zope Page Templates through the web, but sites that allow untrusted users to add/edit Zope Page Templates through the web are at risk from this vulnerability. The problem has been fixed in Zop
s to add/edit Zope Page Templates through the web are at risk from this vulnerability. The problem has been fixed in Zope 5.2 and 4.6. As a workaround, a site administrator can restrict adding/editing Zope Page Templates through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing Zope Page Templates through the web should be restricted to trusted users only. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36 - https://github.com/zopefoundation/Zope/commit/1f8456bf1f908ea46012537d52bd7e752a532c91 - http://www.
SA-5pr9-v234-jw36 - https://github.com/zopefoundation/Zope/commit/1f8456bf1f908ea46012537d52bd7e752a532c91 - http://www.openwall.com/lists/oss-security/2021/05/21/1 - http://www.openwall.com/lists/oss-security/2021/05/22/1 - https://cyllective.com/blog/post/plone-authenticated-rce-cve-2021-32633/
CVE ID: CVE-2021-32634 State: PUBLISHED Published: 2021-05-21T17:15:11 Last Updated: 2024-08-03T23:25:30.885Z Severity: HIGH (CVSS 7.2 CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:H) Vendors: NationalSecurityAgency Products: emissary Problem Types: CWE-502 Description: Emissary is a distributed, peer-to-peer, data-driven workflow framework. Emissary 6.4.0 is vulnerable to Unsafe Deserialization of post-authenticated requests to the [`WorkSpaceClientEnqueue.action`](https://github.com/NationalSecurityAgency/emissary/blob/30c54ef16c6eb6ed09604a929939fb9f66868382/src/main/java/emissary/server/mvc/internal/WorkSpaceClientEnqueueAction.java) REST endpoint. This issue may lead to post-auth Remote Co
missary/server/mvc/internal/WorkSpaceClientEnqueueAction.java) REST endpoint. This issue may lead to post-auth Remote Code Execution. This issue has been patched in version 6.5.0. As a workaround, one can disable network access to Emissary from untrusted sources. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/NationalSecurityAgency/emissary/security/advisories/GHSA-m5qf-gfmp-7638 - https://github.com/NationalSecurityAgency/emissary/commit/40260b1ec1f76cc92361702cc14fa1e4388e19d7
CVE ID: CVE-2021-32635 State: PUBLISHED Published: 2021-05-28T20:20:12 Last Updated: 2024-08-03T23:25:31.038Z Severity: MEDIUM (CVSS 6.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L) Vendors: sylabs Products: singularity Problem Types: CWE-923, CWE-20 Description: Singularity is an open source container platform. In verions 3.7.2 and 3.7.3, Dde to incorrect use of a default URL, `singularity` action commands (`run`/`shell`/`exec`) specifying a container using a `library://` URI will always attempt to retrieve the container from the default remote endpoint (`cloud.sylabs.io`) rather than the configured remote endpoint. An attacker may be able to push a malicious container to the default remot
) rather than the configured remote endpoint. An attacker may be able to push a malicious container to the default remote endpoint with a URI that is identical to the URI used by a victim with a non-default remote endpoint, thus executing the malicious container. Only action commands (`run`/`shell`/`exec`) against `library://` URIs are affected. Other commands such as `pull` / `push` respect the configured remote endpoint. The vulnerability is patched in Singularity version 3.7.4. Two possible workarounds exist: Users can only interact with the default remote endpoint, or an installation can have an execution control list configured to restrict execution to containers signed with specific se
n installation can have an execution control list configured to restrict execution to containers signed with specific secure keys. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/sylabs/singularity/security/advisories/GHSA-5mv9-q7fq-9394 - https://github.com/sylabs/singularity/releases/tag/v3.7.4 - https://security.gentoo.org/glsa/202107-50
CVE ID: CVE-2021-32637 State: PUBLISHED Published: 2021-05-28T17:00:12 Last Updated: 2024-08-03T23:25:30.869Z Severity: CRITICAL (CVSS 10 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) Vendors: authelia Products: authelia Problem Types: CWE-287 Description: Authelia is a a single sign-on multi-factor portal for web apps. This affects uses who are using nginx ngx_http_auth_request_module with Authelia, it allows a malicious individual who crafts a malformed HTTP request to bypass the authentication mechanism. It additionally could theoretically affect other proxy servers, but all of the ones we officially support except nginx do not allow malformed URI paths. The problem is rectified entirely
all of the ones we officially support except nginx do not allow malformed URI paths. The problem is rectified entirely in v4.29.3. As this patch is relatively straightforward we can back port this to any version upon request. Alternatively we are supplying a git patch to 4.25.1 which should be relatively straightforward to apply to any version, the git patches for specific versions can be found in the references. The most relevant workaround is upgrading. You can also add a block which fails requests that contains a malformed URI in the internal location block. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/authelia/authelia/security/advisories/GHSA-68wm
Analyst Notes: - CVE Program Container: References: - https://github.com/authelia/authelia/security/advisories/GHSA-68wm-pfjf-wqp6 - https://github.com/authelia/authelia/commit/c62dbd43d6e69ae81530e7c4f8763857f8ff1dda
CVE ID: CVE-2021-32638 State: PUBLISHED Published: 2021-05-25T17:10:11 Last Updated: 2024-08-03T23:25:30.983Z Severity: MEDIUM (CVSS 4.4 CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N) Vendors: github Products: codeql-action Problem Types: CWE-200, CWE-214 Description: Github's CodeQL action is provided to run CodeQL-based code scanning on non-GitHub CI/CD systems and requires a GitHub access token to connect to a GitHub repository. The runner and its documentation previously suggested passing the GitHub token as a command-line parameter to the process instead of reading it from a file, standard input, or an environment variable. This approach made the token visible to other processes on the s
rom a file, standard input, or an environment variable. This approach made the token visible to other processes on the same machine, for example in the output of the `ps` command. If the CI system publicly exposes the output of `ps`, for example by logging the output, then the GitHub access token can be exposed beyond the scope intended. Users of the CodeQL runner on 3rd-party systems, who are passing a GitHub token via the `--github-auth` flag, are affected. This applies to both GitHub.com and GitHub Enterprise users. Users of the CodeQL Action on GitHub Actions are not affected. The `--github-auth` flag is now considered insecure and deprecated. The undocumented `--external-repository-toke
fected. The `--github-auth` flag is now considered insecure and deprecated. The undocumented `--external-repository-token` flag has been removed. To securely provide a GitHub access token to the CodeQL runner, users should **do one of the following instead**: Use the `--github-auth-stdin` flag and pass the token on the command line via standard input OR set the `GITHUB_TOKEN` environment variable to contain the token, then call the command without passing in the token. The old flag remains present for backwards compatibility with existing workflows. If the user tries to specify an access token using the `--github-auth` flag, there is a deprecation warning printed to the terminal that directs
cify an access token using the `--github-auth` flag, there is a deprecation warning printed to the terminal that directs the user to one of the above options. All CodeQL runner releases codeql-bundle-20210304 onwards contain the patches. We recommend updating to a recent version of the CodeQL runner, storing a token in your CI system's secret storage mechanism, and passing the token to the CodeQL runner using `--github-auth-stdin` or the `GITHUB_TOKEN` environment variable. If still using the old flag, ensure that process output, such as from `ps`, is not persisted in CI logs. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/github/codeql-action/security/ad
gs. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/github/codeql-action/security/advisories/GHSA-g36v-2xff-pv5m - https://github.com/github/codeql-action/commit/58defc0652e935f6f2ffc70a82828b98d75476fb - https://github.com/github/codeql-action/commit/88714e3a60e72ec53caa0e6a203652ee1f3fb1db - https://github.com/github/codeql-action/releases/tag/codeql-bundle-20210304 - https://www.netmeister.org/blog/passing-passwords.html
CVE ID: CVE-2021-32639 State: PUBLISHED Published: 2021-07-02T15:30:11 Last Updated: 2024-08-03T23:25:30.951Z Severity: HIGH (CVSS 7.2 CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:L) Vendors: NationalSecurityAgency Products: emissary Problem Types: CWE-918 Description: Emissary is a P2P-based, data-driven workflow engine. Emissary version 6.4.0 is vulnerable to Server-Side Request Forgery (SSRF). In particular, the `RegisterPeerAction` endpoint and the `AddChildDirectoryAction` endpoint are vulnerable to SSRF. This vulnerability may lead to credential leaks. Emissary version 7.0 contains a patch. As a workaround, disable network access to Emissary from untrusted sources. Additional Analyst Not
7.0 contains a patch. As a workaround, disable network access to Emissary from untrusted sources. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/NationalSecurityAgency/emissary/security/advisories/GHSA-2p8j-2rf3-h4xr - https://github.com/NationalSecurityAgency/emissary/blob/30c54ef16c6eb6ed09604a929939fb9f66868382/src/main/java/emissary/server/mvc/internal/AddChildDirectoryAction.java - https://github.com/NationalSecurityAgency/emissary/blob/30c54ef16c6eb6ed09604a929939fb9f66868382/src/main/java/emissary/server/mvc/internal/RegisterPeerAction.java
CVE ID: CVE-2021-32640 State: PUBLISHED Published: 2021-05-25T18:25:09 Last Updated: 2024-08-03T23:25:31.019Z Severity: MEDIUM (CVSS 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) Vendors: websockets Products: ws Problem Types: CWE-400 Description: ws is an open source WebSocket client and server library for Node.js. A specially crafted value of the `Sec-Websocket-Protocol` header can be used to significantly slow down a ws server. The vulnerability has been fixed in ws@7.4.6 (https://github.com/websockets/ws/commit/00c425ec77993773d823f018f64a5c44e17023ff). In vulnerable versions of ws, the issue can be mitigated by reducing the maximum allowed length of the request headers using the [`-
e versions of ws, the issue can be mitigated by reducing the maximum allowed length of the request headers using the [`--max-http-header-size=size`](https://nodejs.org/api/cli.html#cli_max_http_header_size_size) and/or the [`maxHeaderSize`](https://nodejs.org/api/http.html#http_http_createserver_options_requestlistener) options. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/websockets/ws/security/advisories/GHSA-6fc8-4gx4-v693 - https://github.com/websockets/ws/commit/00c425ec77993773d823f018f64a5c44e17023ff - https://lists.apache.org/thread.html/rdfa7b6253c4d6271e31566ecd5f30b7ce1b8fb2c89d52b8c4e0f4e30%40%3Ccommits.tinkerpop.apache.org%3E - https://secu
hread.html/rdfa7b6253c4d6271e31566ecd5f30b7ce1b8fb2c89d52b8c4e0f4e30%40%3Ccommits.tinkerpop.apache.org%3E - https://security.netapp.com/advisory/ntap-20210706-0005/
CVE ID: CVE-2021-32641 State: PUBLISHED Published: 2021-06-04T21:10:11 Last Updated: 2024-08-03T23:25:31.021Z Severity: HIGH (CVSS 8.1 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) Vendors: auth0 Products: lock Problem Types: CWE-79 Description: auth0-lock is Auth0's signin solution. Versions of nauth0-lock before and including `11.30.0` are vulnerable to reflected XSS. An attacker can execute arbitrary code when the library's `flashMessage` feature is utilized and user input or data from URL parameters is incorporated into the `flashMessage` or the library's `languageDictionary` feature is utilized and user input or data from URL parameters is incorporated into the `languageDictionary`. The
onary` feature is utilized and user input or data from URL parameters is incorporated into the `languageDictionary`. The vulnerability is patched in version 11.30.1. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/auth0/lock/security/advisories/GHSA-jr3j-whm4-9wwm - https://github.com/auth0/lock/commit/d139cf01c8234b07caf265e051f39d3eab08f7ed - https://github.com/auth0/lock/releases/tag/v11.30.1
CVE ID: CVE-2021-32642 State: PUBLISHED Published: 2021-05-28T16:40:10 Last Updated: 2024-08-03T23:25:31.030Z Severity: HIGH (CVSS 7 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H) Vendors: radsecproxy Products: radsecproxy Problem Types: CWE-20 Description: radsecproxy is a generic RADIUS proxy that supports both UDP and TLS (RadSec) RADIUS transports. Missing input validation in radsecproxy's `naptr-eduroam.sh` and `radsec-dynsrv.sh` scripts can lead to configuration injection via crafted radsec peer discovery DNS records. Users are subject to Information disclosure, Denial of Service, Redirection of Radius connection to a non-authenticated server leading to non-authenticated network access.
of Service, Redirection of Radius connection to a non-authenticated server leading to non-authenticated network access. Updated example scripts are available in the master branch and 1.9 release. Note that the scripts are not part of the installation package and are not updated automatically. If you are using the examples, you have to update them manually. The dyndisc scripts work independently of the radsecproxy code. The updated scripts can be used with any version of radsecproxy. Additional Analyst Notes: - CVE Program Container: References: - https://www.usenix.org/conference/usenixsecurity21/presentation/jeitner - https://github.com/radsecproxy/radsecproxy/security/advisories/GHSA-56gw
ference/usenixsecurity21/presentation/jeitner - https://github.com/radsecproxy/radsecproxy/security/advisories/GHSA-56gw-9rj9-55rc - https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/HOC5AFG65NYLMMUTNSBOPC5F4LBAC7BR/ - https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/W7QK5M2SZVMCAFSRQMM6PRZZRQQ372XI/
CVE ID: CVE-2021-32643 State: PUBLISHED Published: 2021-05-27T17:15:11 Last Updated: 2024-08-03T23:25:30.936Z Severity: MEDIUM (CVSS 5.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N) Vendors: http4s Products: http4s Problem Types: CWE-22 Description: Http4s is a Scala interface for HTTP services. `StaticFile.fromUrl` can leak the presence of a directory on a server when the `URL` scheme is not `file://`, and the URL points to a fetchable resource under its scheme and authority. The function returns `F[None]`, indicating no resource, if `url.getFile` is a directory, without first checking the scheme or authority of the URL. If a URL connection to the scheme and URL would return a stream, and
first checking the scheme or authority of the URL. If a URL connection to the scheme and URL would return a stream, and the path in the URL exists as a directory on the server, the presence of the directory on the server could be inferred from the 404 response. The contents and other metadata about the directory are not exposed. This affects http4s versions: 0.21.7 through 0.21.23, 0.22.0-M1 through 0.22.0-M8, 0.23.0-M1, and 1.0.0-M1 through 1.0.0-M22. The [patch](https://github.com/http4s/http4s/commit/52e1890665410b4385e37b96bc49c5e3c708e4e9) is available in the following versions: v0.21.24, v0.22.0-M9, v0.23.0-M2, v1.0.0-M23. As a workaround users can avoid calling `StaticFile.fromUrl` wi
versions: v0.21.24, v0.22.0-M9, v0.23.0-M2, v1.0.0-M23. As a workaround users can avoid calling `StaticFile.fromUrl` with non-file URLs. Additional Analyst Notes: - CVE Program Container: References: - https://github.com/http4s/http4s/security/advisories/GHSA-6h7w-fc84-x7p6 - https://github.com/http4s/http4s/commit/52e1890665410b4385e37b96bc49c5e3c708e4e9 - https://mvnrepository.com/artifact/org.http4s/http4s-core