Exploit Database
144,785 exploits tracked across all sources.
runc <1.2.0-rc2 - Privilege Escalation
runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.
Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual
user on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.
CVSS 3.6
quinn 0.11.0-0.11.3 and quinn-proto 0.11.0-0.11.6 - Denial of Service via Unvalidated Connection Retry
Quinn is a pure-Rust, async-compatible implementation of the IETF QUIC transport protocol. As of quinn-proto 0.11, it is possible for a server to `accept()`, `retry()`, `refuse()`, or `ignore()` an `Incoming` connection. However, calling `retry()` on an unvalidated connection exposes the server to a likely panic in the following situations: 1. Calling `refuse` or `ignore` on the resulting validated connection, if a duplicate initial packet is received. This issue can go undetected until a server's `refuse()`/`ignore()` code path is exercised, such as to stop a denial of service attack. 2. Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received. This issue can go undetected if clients are well-behaved. The former situation was observed in a real application, while the latter is only theoretical.
CVSS 7.5
Misused connection.serverAuthenticate - Auth Bypass
Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/[email protected] enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.
CVSS 9.1
sigstore-go < 0.6.1 - Denial of Service via Malicious Sigstore Bundle
sigstore-go, a Go library for Sigstore signing and verification, is susceptible to a denial of service attack in versions prior to 0.6.1 when a verifier is provided a maliciously crafted Sigstore Bundle containing large amounts of verifiable data, in the form of signed transparency log entries, RFC 3161 timestamps, and attestation subjects. The verification of these data structures is computationally expensive. This can be used to consume excessive CPU resources, leading to a denial of service attack. TUF's security model labels this type of vulnerability an "Endless data attack," and can lead to verification failing to complete and disrupting services that rely on sigstore-go for verification. This vulnerability is addressed with sigstore-go 0.6.1, which adds hard limits to the number of verifiable data structures that can be processed in a bundle. Verification will fail if a bundle has data that exceeds these limits. The limits are 32 signed transparency log entries, 32 RFC 3161 timestamps, 1024 attestation subjects, and 32 digests per attestation subject. These limits are intended to be high enough to accommodate the vast majority of use cases, while preventing the verification of maliciously crafted bundles that contain large amounts of verifiable data. Users who are vulnerable but unable to quickly upgrade may consider adding manual bundle validation to enforce limits similar to those in the referenced patch prior to calling sigstore-go's verification functions.
CVSS 3.1
h2o - Denial of Service
h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. When h2o is configured as a reverse proxy and HTTP/3 requests are cancelled by the client, h2o might crash due to an assertion failure. The crash can be exploited by an attacker to mount a Denial-of-Service attack. By default, the h2o standalone server automatically restarts, minimizing the impact. However, HTTP requests that were served concurrently will still be disrupted. The vulnerability has been addressed in commit 1ed32b2. Users may disable the use of HTTP/3 to mitigate the issue.
CVSS 3.7
gitoxide gix-path < 0.10.11 - Local Configuration Injection Code Execution
`gix-path` is a crate of the `gitoxide` project (an implementation of `git` written in Rust) dealing paths and their conversions. Prior to version 0.10.11, `gix-path` runs `git` to find the path of a configuration file associated with the `git` installation, but improperly resolves paths containing unusual or non-ASCII characters, in rare cases enabling a local attacker to inject configuration leading to code execution. Version 0.10.11 contains a patch for the issue.
In `gix_path::env`, the underlying implementation of the `installation_config` and `installation_config_prefix` functions calls `git config -l --show-origin` to find the path of a file to treat as belonging to the `git` installation. Affected versions of `gix-path` do not pass `-z`/`--null` to cause `git` to report literal paths. Instead, to cover the occasional case that `git` outputs a quoted path, they attempt to parse the path by stripping the quotation marks. The problem is that, when a path is quoted, it may change in substantial ways beyond the concatenation of quotation marks. If not reversed, these changes can result in another valid path that is not equivalent to the original.
On a single-user system, it is not possible to exploit this, unless `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL` have been set to unusual values or Git has been installed in an unusual way. Such a scenario is not expected. Exploitation is unlikely even on a multi-user system, though it is plausible in some uncommon configurations or use cases. In general, exploitation is more likely to succeed if users are expected to install `git` themselves, and are likely to do so in predictable locations; locations where `git` is installed, whether due to usernames in their paths or otherwise, contain characters that `git` quotes by default in paths, such as non-English letters and accented letters; a custom `system`-scope configuration file is specified with the `GIT_CONFIG_SYSTEM` environment variable, and its path is in an unusual location or has strangely named components; or a `system`-scope configuration file is absent, empty, or suppressed by means other than `GIT_CONFIG_NOSYSTEM`. Currently, `gix-path` can treat a `global`-scope configuration file as belonging to the installation if no higher scope configuration file is available. This increases the likelihood of exploitation even on a system where `git` is installed system-wide in an ordinary way. However, exploitation is expected to be very difficult even under any combination of those factors.
CVSS 6.0
Sunshine Pairing - Certificate Persistence Man-in-the-Middle
Sunshine is a self-hosted game stream host for Moonlight. Clients that experience a MITM attack during the pairing process may inadvertantly allow access to an unintended client rather than failing authentication due to a PIN validation error. The pairing attempt fails due to the incorrect PIN, but the certificate from the forged pairing attempt is incorrectly persisted prior to the completion of the pairing request. This allows access to the certificate belonging to the attacker.
CVSS 6.5
ruby-saml <=1.12.2 and 1.13.0-1.16.0 - Unauthenticated SAML Signature Verification Bypass
The Ruby SAML library is for implementing the client side of a SAML authorization. Ruby-SAML in <= 12.2 and 1.13.0 <= 1.16.0 does not properly verify the signature of the SAML Response. An unauthenticated attacker with access to any signed saml document (by the IdP) can thus forge a SAML Response/Assertion with arbitrary contents. This would allow the attacker to log in as arbitrary user within the vulnerable system. This vulnerability is fixed in 1.17.0 and 1.12.3.
CVSS 10.0
Twig <1.44.8, <2.16.1, <3.14.0 - RCE
Twig is a template language for PHP. Under some circumstances, the sandbox security checks are not run which allows user-contributed templates to bypass the sandbox restrictions. This vulnerability is fixed in 1.44.8, 2.16.1, and 3.14.0.
CVSS 8.5
htmldoc < 1.9.19 - Out-of-bounds Write in parse_paragraph
HTMLDOC before 1.9.19 has an out-of-bounds write in parse_paragraph in ps-pdf.cxx because of an attempt to strip leading whitespace from a whitespace-only node.
CVSS 9.8
body-parser < 1.20.3 - Denial of Service via URL Encoding
body-parser is Node.js body parsing middleware. body-parser <1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service. This issue is patched in 1.20.3.
CVSS 7.5
XWiki 1.8-15.10.8 - Unauthenticated Exposure of Private Personal Information via REST API
XWiki Platform is a generic wiki platform. The REST API exposes the history of any page in XWiki of which the attacker knows the name. The exposed information includes for each modification of the page the time of the modification, the version number, the author of the modification (both username and displayed name) and the version comment. This information is exposed regardless of the rights setup, and even when the wiki is configured to be fully private. On a private wiki, this can be tested by accessing /xwiki/rest/wikis/xwiki/spaces/Main/pages/WebHome/history, if this shows the history of the main page then the installation is vulnerable. This has been patched in XWiki 15.10.9 and XWiki 16.3.0RC1.
CVSS 5.3
auditor-bundle < 5.2.6 - Stored Cross-Site Scripting via Unescaped Entity Property
auditor-bundle, formerly known as DoctrineAuditBundle, integrates auditor library into any Symfony 3.4+ application. Prior to version 5.2.6, there is an unescaped entity property enabling Javascript injection. This is possible because `%source_label%` in twig macro is not escaped. Therefore script tags can be inserted and are executed. The vulnerability is fixed in versions 6.0.0 and 5.2.6.
CVSS 8.2
Directus < 10.13.3 - Unauthenticated Credential Exposure via OpenID/OAuth2 Redirect Cache
Directus is a real-time API and App dashboard for managing SQL database content. An unauthenticated user can access credentials of last authenticated user via OpenID or OAuth2 where the authentication URL did not include redirect query string. This happens because on that endpoint for both OpenId and Oauth2 Directus is using the respond middleware, which by default will try to cache GET requests that met some conditions. Although, those conditions do not include this scenario, when an unauthenticated request returns user credentials. This vulnerability is fixed in 10.13.3 and 11.1.0.
CVSS 7.4
Snappymail < 2.38.0 - Stored Cross-Site Scripting via HTML Sanitization Bypass
Snappymail is an open source web-based email client. SnappyMail uses the `cleanHtml()` function to cleanup HTML and CSS in emails. Research discovered that the function has a few bugs which cause an mXSS exploit. Because the function allowed too many (invalid) HTML elements, it was possible (with incorrect markup) to trick the browser to "fix" the broken markup into valid markup. As a result a motivated attacker may be able to inject javascript. However, due to the default Content Security Policy the impact of the exploit is minimal. It could be possible to create an attack which leaks some data when loading images through the proxy.
This way it might be possible to use the proxy to attack the local system, like with `http://localhost:5000/leak`. Another attack could be to load a JavaScript attachment of the email. This is very tricky as the email must link to every possible UID as each email has a unique UID which has a value between 1 and 18446744073709551615 **v2.38.0** and up now remove unsupported HTML elements which mitigates the issue. Users are advised to upgrade. Older versions can install an extension named "Security mXSS" as a mitigation. This will be available at the administration area at `/?admin#/packages`. **NOTE:** this extension can not "fix" malicious code in encrypted messages or (html) attachments as it can't manipulate the JavaScript code for this. It only protects normal message HTML.
CVSS 5.0
wireui < 1.19.3 - Cross-Site Scripting via Button Label Parameter
Wire UI is a library of components and resources to empower Laravel and Livewire application development. A potential Cross-Site Scripting (XSS) vulnerability has been identified in the `/wireui/button` endpoint, specifically through the `label` query parameter. Malicious actors could exploit this vulnerability by injecting JavaScript into the `label` parameter, leading to the execution of arbitrary code in the victim's browser. The `/wireui/button` endpoint dynamically renders button labels based on user-provided input via the `label` query parameter. Due to insufficient sanitization or escaping of this input, an attacker can inject malicious JavaScript. By crafting such a request, an attacker can inject arbitrary code that will be executed by the browser when the endpoint is accessed. If exploited, this vulnerability could allow an attacker to execute arbitrary JavaScript code in the context of the affected website. This could lead to: **Session Hijacking**: Stealing session cookies, tokens, or other sensitive information. **User Impersonation**: Performing unauthorized actions on behalf of authenticated users. **Phishing**: Redirecting users to malicious websites. **Content Manipulation**: Altering the appearance or behavior of the affected page to mislead users or execute further attacks. The severity of this vulnerability depends on the context of where the affected component is used, but in all cases, it poses a significant risk to user security. This issue has been addressed in release versions 1.19.3 and 2.1.3. Users are advised to upgrade. There are no known workarounds for this vulnerability.
CVSS 6.1
BandiView 7.05 - Improper Access Control via Crafted POC File
Bandisoft BandiView 7.05 is vulnerable to Incorrect Access Control in sub_0x3d80fc via a crafted POC file.
CVSS 6.5
Shanghai Sunfull Automation BACnet Server HMI1002-ARM 2.0.4 - Buffe...
A vulnerability classified as critical has been found in Shanghai Sunfull Automation BACnet Server HMI1002-ARM 2.0.4. This affects an unknown part of the component Message Handler. The manipulation leads to buffer overflow. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-263115. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
CVSS 6.3
IceHRM 32.4.0.OS - Reflected Cross-Site Scripting via Login Page Next Parameter
A reflected Cross-Site Scripting (XSS) vulnerability exists in the login page of IceHRM v32.4.0.OS. The vulnerability is due to improper sanitization of the "next" parameter, which is included in the application's response without adequate escaping. An attacker can exploit this flaw by tricking a user into visiting a specially crafted URL, causing the execution of arbitrary JavaScript code in the context of the victim's browser. The issue occurs even though the application has sanitization mechanisms in place.
CVSS 6.1
icehrm 30.0.0.OS - Stored Cross-Site Scripting via First Name Field
A stored cross-site scripting (XSS) vulnerability in Ice Hrm 30.0.0.OS allows attackers to steal cookies via a crafted payload inserted into the First Name field.
CVSS 5.4
icehrm 30.0.0.OS - Reflected Cross-Site Scripting via Dashboard m Parameter
Ice Hrm 30.0.0.OS was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the "m" parameter in the Dashboard of the current user. This vulnerability allows attackers to compromise session credentials via user interaction with a crafted link.
CVSS 6.1
icehrm 30.0.0.OS - Reflected Cross-Site Scripting via Key and fm Parameters
Ice Hrm 30.0.0.OS was discovered to contain multiple reflected cross-site scripting (XSS) vulnerabilities via the "key" and "fm" parameters in the component login.php.
CVSS 6.1
IceHrm <23.0.1.OS - Info Disclosure
IceHrm before 23.0.1.OS has a risky usage of a hashed password in a request.
CVSS 7.5
RuoYi < 4.7.9 - Code Injection via Code Generation Feature
RuoYi v4.7.9 and before has a security flaw that allows escaping from comments within the code generation feature, enabling the injection of malicious code.
CVSS 9.8
REDAXO CMS 5.17.1 - Stored Cross-Site Scripting via Password Parameter in /media/test.html
A stored cross-site scripting (XSS) vulnerability in the component /media/test.html of REDAXO CMS v5.17.1 allows attackers to execute arbitrary web scripts or HTML via injecting a crafted payload into the password parameter.
CVSS 5.4
By Source