ghsa

Improper isolation or compartmentalization in Azure PromptFlow allows an unauthorized attacker to execute code over a network.

### Summary A mock API configuration for static file serving following the same approach presented in the [documentation page](https://mockoon.com/tutorials/create-endpoint-serving-static-file/), where the server filename is generated via templating features from user input is vulnerable to Path Traversal and LFI, allowing an attacker to get any file in the mock server filesystem. The issue may be particularly relevant in cloud hosted server instances ### Details In `sendFileWithCallback`([code](https://github.com/mockoon/mockoon/blob/1ed31c4059d7f757f6cb2a43e10dc81b0d9c55a9/packages/commons-server/src/libs/server/server.ts#L1400)) and `sendFile`([code](https://github.com/mockoon/mockoon/blob/1ed31c4059d7f757f6cb2a43e10dc81b0d9c55a9/packages/commons-server/src/libs/server/server.ts#L1551)) the `filePath` variable is parsed using `TemplateParser` ```js let filePath = TemplateParser({ shouldOmitDataHelper: false, // replace backslashes with forward slashes, but not if f...

### Impact Via manipulation of backoffice API URLs it's possible for authenticated backoffice users to retrieve or delete content or media held within folders the editor does not have access to. ### Patches Will be patched in 10.8.9 and 13.7.1 ### Workarounds None available.

### Impact An improper API access control issue has been identified, allowing low-privilege, authenticated users to create and update data type information that should be restricted to users with access to the settings section. ### Patches Will be patched in 14.3.3 and 15.2.3. ### Workarounds None available.

### Impact In a Kubernetes environment, Ratify can be configured to authenticate to a private Azure Container Registry (ACR). The Azure workload identity and Azure managed identity authentication providers are configured in this setup. Users that configure a private ACR to be used with the Azure authentication providers may be impacted. Both Azure authentication providers attempt to exchange an Entra ID (EID) token for an ACR refresh token. However, Ratify’s Azure authentication providers did not verify that the target registry is an ACR. This could have led to the EID token being presented to a non-ACR registry during token exchange. EID tokens with ACR access can potentially be extracted and abused if a user workload contains an image reference to a malicious registry. ### Patches The Azure workload identity and Azure managed identity authentication providers are updated to add new validation prior to EID token exchange. Validation relies upon registry domain validation against a ...

The Keras Model.load_model function permits arbitrary code execution, even with safe_mode=True, through a manually constructed, malicious .keras archive. By altering the config.json file within the archive, an attacker can specify arbitrary Python modules and functions, along with their arguments, to be loaded and executed during model loading.

### Impact Users with an enabled repository with access to repo level CI secrets in Vela are vulnerable to the exploit. Any user with access to the CI instance and the linked source control manager can perform the exploit. ### Method By spoofing a webhook payload with a specific set of headers and body data, an attacker could transfer ownership of a repository and its repo level secrets to a separate repository. These secrets could be exfiltrated by follow up builds to the repository. ### Patches `v0.26.3` — Image: `target/vela-server:v0.26.3` `v0.25.3` — Image: `target/vela-server:v0.25.3` ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ There are no workarounds to the issue. ### References _Are there any links users can visit to find out more?_ Please see linked CWEs (common weakness enumerators) for more information.

## Summary `Rack::Static` can serve files under the specified `root:` even if `urls:` are provided, which may expose other files under the specified `root:` unexpectedly. ## Details The vulnerability occurs because `Rack::Static` does not properly sanitize user-supplied paths before serving files. Specifically, encoded path traversal sequences are not correctly validated, allowing attackers to access files outside the designated static file directory. ## Impact By exploiting this vulnerability, an attacker can gain access to all files under the specified `root:` directory, provided they are able to determine then path of the file. ## Mitigation - Update to the latest version of Rack, or - Remove usage of `Rack::Static`, or - Ensure that `root:` points at a directory path which only contains files which should be accessed publicly. It is likely that a CDN or similar static file server would also mitigate the issue.

Concrete CMS versions 9.0.0 through 9.3.9 are affected by a stored XSS in Folder Function.The "Add Folder" functionality lacks input sanitization, allowing a rogue admin to inject XSS payloads as folder names.  The Concrete CMS security team gave this vulnerability a CVSS 4.0 Score of 4.8 with vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N. Versions below 9 are not affected. Thanks, Alfin Joseph for reporting.

This vulnerability is caused by the improper mapping of users to organizations based solely on email/username patterns. The issue is limited to the token claim level, meaning the user is not truly added to the organization but may appear as such in applications relying on these claims. The risk increases in scenarios where self-registration is enabled and unrestricted, allowing an attacker to exploit the naming pattern. The issue is mitigated if admins restrict registration or use strict validation mechanisms.