| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Authentication Bypass by Alternate Name vulnerability in Apache Shiro.
This issue affects Apache Shiro: before 2.0.7.
Users are recommended to upgrade to version 2.0.7, which fixes the issue.
The issue only effects static files. If static files are served from a case-insensitive filesystem,
such as default macOS setup, static files may be accessed by varying the case of the filename in the request.
If only lower-case (common default) filters are present in Shiro, they may be bypassed this way.
Shiro 2.0.7 and later has a new parameters to remediate this issue
shiro.ini: filterChainResolver.caseInsensitive = true
application.propertie: shiro.caseInsensitive=true
Shiro 3.0.0 and later (upcoming) makes this the default. |
| In case of SQL errors, exception/stack trace of errors was exposed in API even if "api/expose_stack_traces" was set to false. That could lead to exposing additional information to potential attacker. Users are recommended to upgrade to Apache Airflow 3.2.0, which fixes the issue. |
| Secrets in Variables saved as JSON dictionaries were not properly redacted - in case thee variables were retrieved by the user the secrets stored as nested fields were not masked.
If you do not store variables with sensitive values in JSON form, you are not affected. Otherwise please upgrade to Apache Airflow 3.2.0 that has the fix implemented |
| The Keycloak authentication manager in `apache-airflow-providers-keycloak` did not generate or validate the OAuth 2.0 `state` parameter on the login / login-callback flow, and did not use PKCE. An attacker with a Keycloak account in the same realm could deliver a crafted callback URL to a victim's browser and cause the victim to be logged into the attacker's Airflow session (login-CSRF / session fixation), where any credentials the victim subsequently stored in Airflow Connections would be harvestable by the attacker. Users are advised to upgrade `apache-airflow-providers-keycloak` to 0.7.0 or later. |
| Improper Restriction of XML External Entity Reference vulnerability in Apache Syncope Console.
An administrator with adequate entitlements to create or edit Keymaster parameters via Console can construct malicious XML text to launch an XXE attack, thereby causing sensitive data leakage occurs.
This issue affects Apache Syncope: from 3.0 through 3.0.15, from 4.0 through 4.0.3.
Users are recommended to upgrade to version 3.0.16 / 4.0.4, which fix this issue. |
| Reflected XSS in Apache Syncope's Enduser Login page.
An attacker that tricks a legitimate user into clicking a malicious link and logging in to Syncope Enduser could steal that user's credentials.
This issue affects Apache Syncope: from 3.0 through 3.0.15, from 4.0 through 4.0.3.
Users are recommended to upgrade to version 3.0.16 / 4.0.4, which fix this issue. |
| Affected Products and Versions
* Apache Druid
* Affected Versions: 0.17.0 through 35.x (all versions prior to 36.0.0)
* Prerequisites: * druid-basic-security extension enabled
* LDAP authenticator configured
* Underlying LDAP server permits anonymous bind
Vulnerability Description
An authentication bypass vulnerability exists in Apache Druid when using the druid-basic-security extension with LDAP authentication. If the underlying LDAP server is configured to allow anonymous
binds, an attacker can bypass authentication by providing an existing username with an empty password. This allows unauthorized access to otherwise restricted Druid resources without valid credentials.
The vulnerability stems from improper validation of LDAP authentication responses when anonymous binds are permitted, effectively treating anonymous bind success as valid user authentication.
Impact
A remote, unauthenticated attacker can:
* Gain unauthorized access to the Apache Druid cluster
* Access sensitive data stored in Druid datasources
* Execute queries and potentially manipulate data
* Access administrative interfaces if the bypassed account has elevated privileges
* Completely compromise the confidentiality, integrity, and availability of the Druid deployment
Mitigation
Immediate Mitigation (No Druid Upgrade Required):
* Disable anonymous bind on your LDAP server. This prevents the vulnerability from being exploitable and is the recommended immediate action.
Resolution
* Upgrade Apache Druid to version 36.0.0 or later, which includes fixes to properly reject anonymous LDAP bind attempts. |
| Cross-Realm Token Acceptance Bypass in KeycloakSecurityPolicy Apache Camel Keycloak component.
The Camel-Keycloak KeycloakSecurityPolicy does not validate the iss (issuer) claim of JWT tokens against the configured realm. A token issued by one Keycloak realm is silently accepted by a policy configured for a completely different realm, breaking tenant isolation.
This issue affects Apache Camel: from 4.15.0 before 4.18.0.
Users are recommended to upgrade to version 4.18.0, which fixes the issue. |
| A vulnerability in Apache IoTDB.
This issue affects Apache IoTDB: from 1.0.0 before 1.3.7, from 2.0.0 before 2.0.7.
Users are recommended to upgrade to version 1.3.7 or 2.0.7, which fixes the issue. |
| Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ.
Apache ActiveMQ Classic exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on the web console. The default Jolokia access policy permits exec operations on all ActiveMQ MBeans (org.apache.activemq:*), including
BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String).
An authenticated attacker can invoke these operations with a crafted discovery URI that triggers the VM transport's brokerConfig parameter to load a remote Spring XML application context using ResourceXmlApplicationContext.
Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec().
This issue affects Apache ActiveMQ Broker: before 5.19.4, from 6.0.0 before 6.2.3; Apache ActiveMQ All: before 5.19.4, from 6.0.0 before 6.2.3; Apache ActiveMQ: before 5.19.4, from 6.0.0 before 6.2.3.
Users are recommended to upgrade to version 5.19.4 or 6.2.3, which fixes the issue |
| JWT Tokens used by tasks were exposed in logs. This could allow UI users to act as Dag Authors.
Users are advised to upgrade to Airflow version that contains fix.
Users are recommended to upgrade to version 3.2.0, which fixes this issue. |
| Dag Authors, who normally should not be able to execute code in the webserver context could craft XCom payload causing the webserver to execute arbitrary code. Since Dag Authors are already highly trusted, severity of this issue is Low.
Users are recommended to upgrade to Apache Airflow 3.2.0, which fixes the issue. |
| An example of BashOperator in Airflow documentation suggested a way of passing dag_run.conf in the way that could cause unsanitized user input to be used to escalate privileges of UI user to allow execute code on worker. Users should review if any of their own DAGs have adopted this incorrect advice. |
| UI / API User with asset materialize permission could trigger dags they had no access to.
Users are advised to migrate to Airflow version 3.2.0 that fixes the issue. |
| The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element . These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem. On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes.
Solr deployments are subject to this vulnerability if they meet the following criteria:
* Solr is running in its "standalone" mode.
* Solr's "allowPath" setting is being used to restrict file access to certain directories.
* Solr's "create core" API is exposed and accessible to untrusted users. This can happen if Solr's RuleBasedAuthorizationPlugin https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html is disabled, or if it is enabled but the "core-admin-edit" predefined permission (or an equivalent custom permission) is given to low-trust (i.e. non-admin) user roles.
Users can mitigate this by enabling Solr's RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores. Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue. |
| Deployments of Apache Solr 5.3.0 through 9.10.0 that rely on Solr's "Rule Based Authorization Plugin" are vulnerable to allowing unauthorized access to certain Solr APIs, due to insufficiently strict input validation in those components. Only deployments that meet all of the following criteria are impacted by this vulnerability:
* Use of Solr's "RuleBasedAuthorizationPlugin"
* A RuleBasedAuthorizationPlugin config (see security.json) that specifies multiple "roles"
* A RuleBasedAuthorizationPlugin permission list (see security.json) that uses one or more of the following pre-defined permission rules: "config-read", "config-edit", "schema-read", "metrics-read", or "security-read".
* A RuleBasedAuthorizationPlugin permission list that doesn't define the "all" pre-defined permission
* A networking setup that allows clients to make unfiltered network requests to Solr. (i.e. user-submitted HTTP/HTTPS requests reach Solr as-is, unmodified or restricted by any intervening proxy or gateway)
Users can mitigate this vulnerability by ensuring that their RuleBasedAuthorizationPlugin configuration specifies the "all" pre-defined permission and associates the permission with an "admin" or other privileged role. Users can also upgrade to a Solr version outside of the impacted range, such as the recently released Solr 9.10.1. |
| Deserialization of Untrusted Data vulnerability in Apache Karaf Decanter.
The Decanter log socket collector exposes the port 4560, without authentication. If the collector exposes allowed classes property, this configuration can be bypassed.
It means that the log socket collector is vulnerable to deserialization of untrusted data, eventually causing DoS.
NB: Decanter log socket collector is not installed by default. Users who have not installed Decanter log socket are not impacted by this issue.
This issue affects Apache Karaf Decanter before 2.12.0.
Users are recommended to upgrade to version 2.12.0, which fixes the issue. |
| Exposure of Private Personal Information to an Unauthorized Actor vulnerability in Apache Answer.
This issue affects Apache Answer: through 1.7.1.
An unauthenticated API endpoint incorrectly exposes full revision history for deleted content. This allows unauthorized user to retrieve restricted or sensitive information.
Users are recommended to upgrade to version 2.0.0, which fixes the issue. |
| Apache Airflow versions 3.1.0 through 3.1.6 contain an authorization flaw that can allow an authenticated user with custom permissions limited to task access to view task logs without having task log access.
Users are recommended to upgrade to Apache Airflow 3.1.7 or later, which resolves this issue. |
| Observable Timing Discrepancy vulnerability in Apache Shiro.
This issue affects Apache Shiro: from 1.*, 2.* before 2.0.7.
Users are recommended to upgrade to version 2.0.7 or later, which fixes the issue.
Prior to Shiro 2.0.7, code paths for non-existent vs. existing users are different enough,
that a brute-force attack may be able to tell, by timing the requests only, determine if
the request failed because of a non-existent user vs. wrong password.
The most likely attack vector is a local attack only.
Shiro security model https://shiro.apache.org/security-model.html#username_enumeration discusses this as well.
Typically, brute force attack can be mitigated at the infrastructure level. |
