| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| ImportDump is an extension for mediawiki designed to automate user import requests. Anyone who can edit the interface strings of a wiki (typically administrators and interface admins) can embed XSS payloads in the messages for dates, and thus XSS anyone who views Special:RequestImportQueue. This issue has been patched in commit `d054b95` and all users are advised to apply this commit to their branch. Users unable to upgrade may either Prevent access to Special:RequestImportQueue on all wikis, except for the global wiki; and If an interface administrator (or equivalent) level protection is available (which is not provided by default) on the global wiki, protect the affected messages up to that level. This causes the XSS to be virtually useless as users with those rights can already edit Javascript pages. Or Prevent access to Special:RequestImportQueue altogether. |
| Backstage is an open framework for building developer portals. Configuration supplied through APP_CONFIG_* environment variables, for example APP_CONFIG_backend_listen_port=7007, where unexpectedly ignoring the visibility defined in configuration schema. This occurred even if the configuration schema specified that they should have backend or secret visibility. This was an intended feature of the APP_CONFIG_* way of supplying configuration, but now clearly goes against the expected behavior of the configuration system. This behavior leads to a risk of potentially exposing sensitive configuration details intended to remain private or restricted to backend processes. The issue has been resolved in version 0.3.75 of the @backstage/plugin-app-backend package. As a temporary measure, avoid supplying secrets using the APP_CONFIG_ configuration pattern. Consider alternative methods for setting secrets, such as the environment substitution available for Backstage configuration. |
| Pomerium is an identity and context-aware access proxy. The Pomerium databroker service is responsible for managing all persistent Pomerium application state. Requests to the databroker service API are authorized by the presence of a JSON Web Token (JWT) signed by a key known by all Pomerium services in the same deployment. However, incomplete validation of this JWT meant that some service account access tokens would incorrectly be treated as valid for the purpose of databroker API authorization. Improper access to the databroker API could allow exfiltration of user info, spoofing of user sessions, or tampering with Pomerium routes, policies, and other settings. A Pomerium deployment is susceptible to this issue if all of the following conditions are met, you have issued a service account access token using Pomerium Zero or Pomerium Enterprise, the access token has an explicit expiration date in the future, and the core Pomerium databroker gRPC API is not otherwise secured by network access controls. This vulnerability is fixed in 0.27.1. |
| XZ Utils provide a general-purpose data-compression library plus command-line tools. When built for native Windows (MinGW-w64 or MSVC), the command line tools from XZ Utils 5.6.2 and older have a command line argument injection vulnerability. If a command line contains Unicode characters (for example, filenames) that don't exist in the current legacy code page, the characters are converted to similar-looking characters with best-fit mapping. Some best-fit mappings result in ASCII characters that change the meaning of the command line, which can be exploited with malicious filenames to do argument injection or directory traversal attacks. This vulnerability is fixed in 5.6.3. Command line tools built for Cygwin or MSYS2 are unaffected. liblzma is unaffected. |
| RSSHub is an RSS network. Prior to commit 64e00e7, RSSHub's `docker-test-cont.yml` workflow is vulnerable to Artifact Poisoning, which could have lead to a full repository takeover. Downstream users of RSSHub are not vulnerable to this issue, and commit 64e00e7 fixed the underlying issue and made the repository no longer vulnerable. The `docker-test-cont.yml` workflow gets triggered when the `PR - Docker build test` workflow completes successfully. It then collects some information about the Pull Request that triggered the triggering workflow and set some labels depending on the PR body and sender. If the PR also contains a `routes` markdown block, it will set the `TEST_CONTINUE` environment variable to `true`. The workflow then downloads and extracts an artifact uploaded by the triggering workflow which is expected to contain a single `rsshub.tar.zst` file. However, prior to commit 64e00e7, it did not validate and the contents were extracted in the root of the workspace overriding any existing files. Since the contents of the artifact were not validated, it is possible for a malicious actor to send a Pull Request which uploads, not just the `rsshub.tar.zst` compressed docker image, but also a malicious `package.json` file with a script to run arbitrary code in the context of the privileged workflow. As of commit 64e00e7, this scenario has been addressed and the RSSHub repository is no longer vulnerable. |
| matrix-js-sdk is the Matrix Client-Server SDK for JavaScript and TypeScript. In matrix-js-sdk versions versions 9.11.0 through 34.7.0, the method `MatrixClient.sendSharedHistoryKeys` is vulnerable to interception by malicious homeservers. The method was introduced by MSC3061) and is commonly used to share historical message keys with newly invited users, granting them access to past messages in the room. However, it unconditionally sends these "shared" keys to all of the invited user's devices, regardless of whether the user's cryptographic identity is verified or whether the user's devices are signed by that identity. This allows the attacker to potentially inject its own devices to receive sensitive historical keys without proper security checks. Note that this only affects clients running the SDK with the legacy crypto stack. Clients using the new Rust cryptography stack (i.e. those that call `MatrixClient.initRustCrypto()` instead of `MatrixClient.initCrypto()`) are unaffected by this vulnerability, because `MatrixClient.sendSharedHistoryKeys()` raises an exception in such environments. The vulnerability was fixed in matrix-js-sdk 34.8.0 by removing the vulnerable functionality. As a workaround, remove use of affected functionality from clients. |
| SummaryThis advisory addresses a security vulnerability in Mautic where sensitive .env configuration files may be directly accessible via a web browser. This exposure could lead to the disclosure of sensitive information, including database credentials, API keys, and other critical system configurations.
Sensitive Information Disclosure via .env File Exposure: The .env file, which typically contains environment variables and sensitive application configurations, is directly accessible via a web browser due to missing web server configurations that restrict access to such files. This allows an unauthenticated attacker to view the contents of this file by simply navigating to its URL.
MitigationUpdate Mautic to the latest Mautic version.
By default, Mautic does not use .env files for production data.
For Apache users: Ensure your web server is configured to respect .htaccess files.
For Nginx users: As Nginx does not inherently support .htaccess files, you must manually add a configuration block to your Nginx server configuration to deny access to .env files. Add the following to your Nginx configuration for the Mautic site:
location ~ /\.env {
deny all;
}
After modifying your Nginx configuration, remember to reload or restart your Nginx service for the changes to take effect. |
| Develocity (formerly Gradle Enterprise) before 2024.1.8 has Incorrect Access Control. Project-level access control configuration was introduced in Enterprise Config schema version 8. Migration functionality from schema version 8 to versions 9 and 10 (in affected vulnerable versions) does not include the projects section of the configuration. This leads to all of the project settings being reset to their defaults when the old schema is loaded. In the case of projects.enabled, the default is false. Thus, using an enterprise config v8 results in Project level access control being disabled, even if it was previously enabled, and previously restricted project information disclosed. Most commonly, this occurs when a Develocity instance is upgraded from an earlier version. Specifically, this occurs if: Develocity 2023.3.X is upgraded to 2023.4.X; Develocity 2023.3.X is upgraded to 2024.1.X up to and including 2024.1.7; or Develocity 2023.4.X is upgraded to 2024.1.X up to and including 2024.1.7. The flaw does not occur when upgrading to a fixed version. An upgrade can only be triggered via administrator access, and cannot be forced by an external attacker. |
| Issue summary: Checking excessively long DSA keys or parameters may be very
slow.
Impact summary: Applications that use the functions EVP_PKEY_param_check()
or EVP_PKEY_public_check() to check a DSA public key or DSA parameters may
experience long delays. Where the key or parameters that are being checked
have been obtained from an untrusted source this may lead to a Denial of
Service.
The functions EVP_PKEY_param_check() or EVP_PKEY_public_check() perform
various checks on DSA parameters. Some of those computations take a long time
if the modulus (`p` parameter) is too large.
Trying to use a very large modulus is slow and OpenSSL will not allow using
public keys with a modulus which is over 10,000 bits in length for signature
verification. However the key and parameter check functions do not limit
the modulus size when performing the checks.
An application that calls EVP_PKEY_param_check() or EVP_PKEY_public_check()
and supplies a key or parameters obtained from an untrusted source could be
vulnerable to a Denial of Service attack.
These functions are not called by OpenSSL itself on untrusted DSA keys so
only applications that directly call these functions may be vulnerable.
Also vulnerable are the OpenSSL pkey and pkeyparam command line applications
when using the `-check` option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue. |
| 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. |
| gix-path is a crate of the gitoxide project dealing with git paths and their conversions. `gix-path` executes `git` to find the path of a configuration file that belongs to the `git` installation itself, but mistakenly treats the local repository's configuration as system-wide if no higher scoped configuration is found. In rare cases, this causes a less trusted repository to be treated as more trusted, or leaks sensitive information from one repository to another, such as sending credentials to another repository's remote. In `gix_path::env`, the underlying implementation of the `installation_config` and `installation_config_prefix` functions calls `git config -l --show-origin` and parses the first line of the output to extract the path to the configuration file holding the configuration variable of highest scope. It is believed to be very difficult to exploit this vulnerability deliberately, due to the need either to anticipate a situation in which higher-scoped configuration variables would be absent, or to arrange for this to happen. Although any operating system may be affected, users running Apple Git on macOS are much less likely to be affected. This issue has been addressed in release version 0.10.10. All users are advised to upgrade. |
| path-to-regexp turns path strings into a regular expressions. In certain cases, path-to-regexp will output a regular expression that can be exploited to cause poor performance. Because JavaScript is single threaded and regex matching runs on the main thread, poor performance will block the event loop and lead to a DoS. The bad regular expression is generated any time you have two parameters within a single segment, separated by something that is not a period (.). For users of 0.1, upgrade to 0.1.10. All other users should upgrade to 8.0.0. |
| An internal product security audit discovered a UEFI SMM (System Management Mode) callout vulnerability in some ThinkSystem servers that could allow a local attacker with elevated privileges to execute arbitrary code. |
| Chisel is a fast TCP/UDP tunnel, transported over HTTP, secured via SSH. The Chisel server doesn't ever read the documented `AUTH` environment variable used to set credentials, which allows any unauthenticated user to connect, even if credentials were set. Anyone running the Chisel server that is using the `AUTH` environment variable to specify credentials to authenticate against is affected by this vulnerability. Chisel is often used to provide an entrypoint to a private network, which means services that are gated by Chisel may be affected. Additionally, Chisel is often used for exposing services to the internet. An attacker could MITM requests by connecting to a Chisel server and requesting to forward traffic from a remote port. This issue has been addressed in release version 1.10.0. All users are advised to upgrade. There are no known workarounds for this vulnerability. |
| There are many buffer overflow vulnerabilities present in several CGI binaries of the charging station.This issue affects Iocharger firmware for AC model chargers beforeversion 24120701.
Likelihood: High – Given the prevalence of these buffer overflows, and the clear error message of the web server, an attacker is very likely to be able to find these vulnerabilities.
Impact: Low – Usually, overflowing one of these buffers just causes a segmentation fault of the CGI binary, which causes the web server to return a 502 Bad Gateway error. However the webserver itself is not affected, and no DoS can be achieved. Abusing these buffer overflows in a meaningful way requires highly technical knowledge, especially since ASLR also seems to be enabled on the charging station. However, a skilled attacker might be able to use one of these buffer overflows to obtain remote code execution.
CVSS clarification. The attack can be executed over any network connection the station is listening to and serves the web interface (AV:N), and there are no additional security measure sin place that need to be circumvented (AC:L), the attack does not rely on preconditions (AT:N). The attack does require authentication, but the level of authentication is irrelevant (PR:L), it does not require user interaction (UI:N). The attack has a small impact on the availability of the device (VC:N/VI:N/VA:L). There is no impact on subsequent systems. (SC:N/SI:N/SA:N). While this device is an EV charger handing significant amounts of power, we do not expect this vulnerability to have a safety impact. The attack can be automated (AU:Y). |
| The <redacted>.exe or <redacted>.exe CGI binary can be used to upload arbitrary files to /tmp/upload/ or /tmp/ respectively as any user, although the user interface for uploading files is only shown to the iocadmin user.
This issue affects Iocharger firmware for AC models before version 24120701.
Likelihood: Moderate – An attacker will need to have knowledge of this CGI binary, e.g. by finding it in firmware. Furthermore, the attacker will need a (low privilege) account to gain access to the <redacted>.exe or <redacted>.exe CGI binary and upload the file, or convince a user with such access to upload it.
Impact: Low – The attacker can upload arbitrary files to /tmp/upload/ or /tmp/. However, the attacker is unable to access or use these files without other vulnerabilities.
CVSS clarification. The attack can be executed over any network connection the station is listening to and serves the web interface (AV:N), and there are no additional security measure sin place that need to be circumvented (AC:L), the attack does not rely on preconditions (AT:N). The attack does require authentication, but the level of authentication is irrelevant (PR:L), it does not require user interaction (UI:N). Artitrary files can be uploaded, be these files will not be in a location where they can influence confidentiality or availability and have a minimal impact on device integrity (VC:N/VI:L/VA:N). There is no impact on subsequent systems. (SC:N/SI:N/SA:N). While this device is an EV charger handing significant amounts of power, we do not expect this vulnerability to have a safety impact. The attack can be automated (AU:Y). |
| The CGI script <redacted>.sh can be used to download any file on the filesystem.
This issue affects Iocharger firmware for AC model chargers beforeversion 24120701.
Likelihood: High, but credentials required.
Impact: Critical – The script can be used to download any file on the filesystem, including sensitive files such as /etc/shadow, the CGI script source code or binaries and configuration files.
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/S:P/AU:Y
CVSS clarification. The attack can be executed over any network connection the station is listening to and serves the web interface (AV:N), and there are no additional security measure sin place that need to be circumvented (AC:L), the attack does not rely on preconditions (AT:N). The attack does require authentication, but the level of authentication is irrelevant (PR:L), it does not require user interaction (UI:N). The confidentiality of all files of the devicd can be compromised (VC:H/VI:N/VA:N). There is no impact on subsequent systems. (SC:N/SI:N/SA:N). While this device is an EV charger handing significant amounts of power, this attack in isolation does not have a safety impact. The attack can be automated (AU:Y). |
| After gaining access to the firmware of a charging station, a file at <redacted> can be accessed to obtain default credentials that are the same across all Iocharger AC model EV chargers.
This issue affects Iocharger firmware for AC models before firmware version 25010801.
The issue is addressed by requiring a mandatory password change on first login, it is still recommended to change the password on older models.
Likelihood: Moderate – The attacker will first have to abuse a code execution or file inclusion vulnerability (for example by using <redacted>.sh) to gain access to the <redacted>.json file, or obtain a firmware dump of the charging station or obtain the firmware via other channels.
Impact: Critical – All chargers using Iocharger firmware for AC models started with the same initial password. For models with firmware version before 25010801 a password change was not mandatory. It is therefore very likely that this firmware password is still active on many chargers. These credentials could, once obtained, allow an attacker to log into many Iocharger charging station, and allow them to execute arbitrary commands via the System → Custom page.
CVSS clarification: Any network interface serving the web ui is vulnerable (AV:N) and there are not additional security measures to circumvent (AC:L), nor does the attack require and existing preconditions (AT:N). The attack is authenticated, and requires high privileges (PR:H), there is no user interaction required (UI:N). The attack leads to a compromised of the confidentialy of the "super user" credentials of the device (VC:H/VI:N/VA:N), and can subsequently be used to full compromise and other devices (SC:H/SI:H/SA:H). Becuase this is an EV charger handing significant power, there is a potential safety impact (S:P). This attack can be automated (AU:Y). |
| Patch traversal, External Control of File Name or Path vulnerability in Iocharger Home allows deletion of arbitrary files
This issue affects Iocharger firmware for AC model before firmware version 25010801.
Likelihood: High, but requires authentication
Impact: Critical – The vulnerability can be used to delete any file on the charging station, severely impacting the integrity of the charging station. Furthermore, the vulnerability could be used to delete binaries required for the functioning of the charging station, severely impacting the availability of the charging station.
CVSS clarification: Any network interface serving the web ui is vulnerable (AV:N) and there are not additional security measures to circumvent (AC:L), nor does the attack require and existing preconditions (AT:N). The attack is authenticated, but the level of authentication does not matter (PR:L), nor is any user interaction required (UI:N). The attack leads compromised of the integrity and availability of the device (VVC:N/VI:H/VA:H), with no effect on subsequent systems (SC:N/SI:N/SA:N). We do not forsee a safety impact (S:N). This attack can be automated (AU:Y). |
| Improper Neutralization of Special Elements used in a Command ('Command Injection') vulnerability allows OS Command Injection as root
This issue affects Iocharger firmware for AC model chargers before version 24120701.
Likelihood: Moderate – The attacker will first need to find the name of the script, and needs a (low privilege) account to gain access to the script, or convince a user with such access to execute a request to it.
Impact: Critical – The attacker has full control over the charging station as the root user, and can arbitrarily add, modify and deletefiles and services.
CVSS clarification: Any network interface serving the web ui is vulnerable (AV:N) and there are not additional security measures to circumvent (AC:L), nor does the attack require and existing preconditions (AT:N). The attack is authenticated, but the level of authentication does not matter (PR:L), nor is any user interaction required (UI:N). The attack leads to a full compromised (VC:H/VI:H/VA:H), and compromised devices can be used to pivot into networks that should potentially not be accessible (SC:L/SI:L/SA:H). Becuase this is an EV charger handing significant power, there is a potential safety impact (S:P). This attack can be automated (AU:Y). |
