Source
ghsa
### Summary [Vite dev server option](https://vitejs.dev/config/server-options.html#server-fs-deny) `server.fs.deny` did not deny requests for patterns with directories. An example of such a pattern is `/foo/**/*`. ### Impact Only apps setting a custom `server.fs.deny` that includes a pattern with directories, and explicitly exposing the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host)) are affected. ### Patches Fixed in [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] ### Details `server.fs.deny` uses picomatch with the config of `{ matchBase: true }`. [matchBase](https://github.com/micromatch/picomatch/blob/master/README.md#options:~:text=Description-,basename,-boolean) only matches the basename of the file, not the path due to a bug (https://github.com/micromatch/picomatch/issues/89). The vite config docs read like you should be able to set fs.deny to glob with picoma...
A NULL pointer dereference flaw was found in KubeVirt. This flaw allows an attacker who has access to a virtual machine guest on a node with DownwardMetrics enabled to cause a denial of service by issuing a high number of calls to vm-dump-metrics --virtio and then deleting the virtual machine.
### Impact Any deployment of voilà dashboard allow local file inclusion, that is to say any file on a filesystem that is readable by the user that runs the voilà dashboard server can be downloaded by someone with network access to the server. Whether this still requires authentication depends on how voilà is deployed. ### Patches This is patched in 0.2.17+, 0.3.8+, 0.4.4+, 0.5.6+ ### Workarounds None. ### References CWE-73: External Control of File Name or Path ### Original report I have found a local file inclusion vulnerability in one of your subprojects, voila (https://github.com/voila-dashboards/voila). The vulnerability exists in the "/static" Route, and can be exploited by simply making a request such as this: ``` $ curl localhost:8866/static/etc/passwd ``` ...or by using a webbrowser to download the file. I dug into the source code, and I think the offending line is here: https://github.com/voila-dashboards/voila/blob/8419cc7d79c0bb1dabfbd9ec49cb957740609d4d/voi...
Lack of sanitization during Installation Process in Dolibarr ERP CRM up to version 19.0.0 allows an attacker with adjacent access to the network to execute arbitrary code via a specifically crafted input.
Server Side Request Forgery (SSRF) vulnerability in Gleez Cms 1.2.0, allows remote attackers to execute arbitrary code and obtain sensitive information via modules/gleez/classes/request.php.
In _imagingcms.c in Pillow before 10.3.0, a buffer overflow exists because strcpy is used instead of strncpy.
This vulnerability allows authenticated users with produce or consume permissions to perform unauthorized operations on partitioned topics, such as unloading topics and triggering compaction. These management operations should be restricted to users with the tenant admin role or superuser role. An authenticated user with produce permission can create subscriptions and update subscription properties on partitioned topics, even though this should be limited to users with consume permissions. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different. Additionally, the vulnerability allows an authenticated user to read, create, modify, and delete namespace properties in any namespace in any tenant. In Pulsar, namespace properties are reserved for user provided metadata about the namespace. This issue affects Apache Pulsar versions from 2.7.1 to 2.10.6, from 2.11.0 to 2.11...
### Impact The 19.0.0 release of Wasmtime contains a regression introduced during its development which can lead to a guest WebAssembly module causing a panic in the host runtime. A valid WebAssembly module, when executed at runtime, may cause this panic. The panic in question is caused when a WebAssembly module issues a `table.*` instruction which uses a dropped element segment with a table that also has an `externref` type. This causes Wasmtime to erroneously use an empty function segment instead of an empty externref segment to perform this operation. This mismatch in types causes a panic in Wasmtime when it's asserted that an externref table is only viewed as externrefs. This regression was introduced during the development of the 19.0.0 release and only affects the 19.0.0 release. This panic requires the `reference-types` WebAssembly feature to be enabled, and it is enabled by default. Toolchains are not known to generate this pattern by default so it's likely a module would nee...
For an attacker with pre-existing access to send a signal to a workflow, the attacker can make the signal name a script that executes when a victim views that signal. The XSS is in the timeline page displaying the workflow execution details of the workflow that was sent the crafted signal. Access to send a signal to a workflow is determined by how you configured the authorizer on your server. This includes any entity with permission to directly call SignalWorkflowExecution or SignalWithStartWorkflowExecution, or any entity can deploy a worker that has access to call workflow progress APIs (specifically RespondWorkflowTaskCompleted).
The authentication service of the extension does not verify the OpenID Connect authentication state from the user lookup chain. Instead, the authentication service authenticates every valid frontend user from the user lookup chain, where the frontend user field “tx_oidc” is not empty. In scenarios, where either ext:felogin is active or where `$GLOBALS['TYPO3_CONF_VARS'][‘FE’][‘checkFeUserPid’]` is disabled, an attacker can login to OpenID Connect frontend user accounts by providing a valid username and any password.