Mopmonk-Ai

Missing Authorization vulnerability in Apache Kylin. A backend metadata dump API misses the enough authorization and the path-confinement. Impact most to the kylin services that are directly exposed to public network, which is not common. In-house kylin deployments are mostly not impacted. This issue affects Apache Kylin: from 4 through 5.0.4. Users are recommended to upgrade to version 5.0.5, which fixes the issue.

Improper Authentication vulnerability in Apache Kylin. Unauthenticated user may access to system cleanup actions. Impact most to the kylin services that are directly exposed to public network, which is not common. In-house kylin deployments are mostly not impacted. This issue affects Apache Kylin: from 4 through 5.0.4. Users are recommended to upgrade to version 5.0.5, which fixes the issue.

**Name of the Vulnerable Software and Affected Versions** Apache CXF versions prior to 4.2.4 Apache CXF versions prior to 4.1.9 Apache CXF versions prior to 3.6.13 **Description** An issue exists in the `STSTokenValidator` where the result of the SAML assertion signature check is stored in an object shared across all requests. This allows a remote, unauthenticated attacker to send a forged assertion signed with an untrusted certificate. If legitimate requests are processed simultaneously, the forged assertion may be incorrectly accepted as trusted without being sent to the Security Token Service (STS). This affects services using `STSTokenValidator` to validate SAML tokens where the `alwaysValidateToSts` variable is not set. **Recommendations** Upgrade to version 4.2.4. Upgrade to version 4.1.9. Upgrade to version 3.6.13.

**Name of the Vulnerable Software and Affected Versions** Apache CXF versions prior to 4.2.4 Apache CXF versions prior to 4.1.9 Apache CXF versions prior to 3.6.13 **Description** The STSTokenValidator and Security Token Service (STS) cache validated security tokens using a non-cryptographic 32-bit hash generated by `Java Arrays.hashCode/hashCode()`. Because the system treats a cache hit as confirmation that a token has been validated, an attacker can create a token, such as a self-signed SAML Assertion or a UsernameToken, that produces a hash colliding with an existing cached entry. This allows the attacker to bypass password validation, signature trust verification, or STS calls, enabling them to authenticate as another user and potentially obtain STS-signed tokens for that identity. **Recommendations** Upgrade to version 4.2.4. Upgrade to version 4.1.9. Upgrade to version 3.6.13.

**Name of the Vulnerable Software and Affected Versions** Apache Camel Karavan versions 4.0.0 through 4.22.0 **Description** Improper input validation occurs when a deployment is started. The software unmarshals a project's `kubernetes.yaml` and applies all contained resources to the cluster without restricting resource kinds, rejecting security-sensitive pod options, or pinning the target namespace. An authenticated user with any role can cause the application of arbitrary Kubernetes resources accessible to its service account, including pods requesting `hostNetwork`, `hostPID`, `hostIPC`, `hostPath` volumes, host ports, privileged containers, privilege escalation, or added capabilities. **Recommendations** Upgrade to version 4.22.1.

**Name of the Vulnerable Software and Affected Versions** Apache APISIX versions 3.17.0 through 3.18.0 **Description** Cross-Site Request Forgery (CSRF) exists in the feishu-auth and dingtalk-auth plugins. An attacker can trick a user into clicking a crafted link, causing the user's browser session on a protected route to be established under the attacker's identity. Consequently, any actions performed by the user during that session, such as form submissions, uploads, or account bindings, will be associated with the attacker's account. **Recommendations** Upgrade to version 3.19.0.

**Name of the Vulnerable Software and Affected Versions** Apache Karaf (affected versions not specified) **Description** Missing authorization in the `jdbc` and `jms` shell command scopes allows authenticated users, including those with only the `viewer` role, to execute any `jdbc:*` and `jms:*` commands. This occurs because the command guard `SecuredSessionFactoryImpl` allows commands that lack a matching Access Control List (ACL) rule. Specifically, the `jdbc:ds-create` command allows the storage of an unvalidated, attacker-controlled JDBC URL into a `pax-jdbc-config` factory configuration, which is then converted into a live `DataSource`. Since some JDBC drivers execute code or SQL based on URL parameters, a user with `viewer` privileges can achieve arbitrary code execution, bypassing the administrative role requirements typically protecting `shell:exec`. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Apache Karaf versions prior to 4.4.12 Apache Karaf versions prior to 4.5.0 **Description** Apache Karaf contains a flaw in the `KarafMBeanServerGuard` which fails to enforce role-based access control (RBAC) on specific MBean lifecycle operations. The `createMBean()`, `registerMBean()`, and `unregisterMBean()` functions are not included in the guarded operations list, allowing any authenticated user, including those with the least-privileged "viewer" role, to instantiate arbitrary classes as MBeans without authorization or audit logs. This can be exploited to instantiate the `javax.management.loading.MLet` class, which serves as a remote classloader. By invoking the `getMBeansFromURL()` operation—which is permitted for the "viewer" role due to a wildcard rule matching "get*"—an attacker can fetch a remote MLet file and execute arbitrary code within the Karaf JVM. **Recommendations** Upgrade to version 4.4.12 or 4.5.0 or later. Restrict network access to the JMX RMI registry/server ports 1099 and 44444 to trusted hosts. Avoid issuing JMX credentials to any users who do not require the "admin" role.