Page 7 of 38 results (0.012 seconds)

CVSS: 9.0EPSS: 0%CPEs: 3EXPL: 2

Dropwizard-Validation before 1.3.19, and 2.0.2 may allow arbitrary code execution on the host system, with the privileges of the Dropwizard service account, by injecting arbitrary Java Expression Language expressions when using the self-validating feature. The issue has been fixed in dropwizard-validation 1.3.19 and 2.0.2. Dropwizard-Validation versiones anteriores a 1.3.19 y 2.0.2, puede permitir una ejecución de código arbitraria en el host system, con los privilegios de la cuenta de servicio de Dropwizard, mediante la inyección de expresiones arbitrarias de Java Expression Language cuando se utiliza la funcionalidad self-validating. El problema se ha corregido en dropwizard-validation versiones 1.3.19 y 2.0.2. • https://github.com/LycsHub/CVE-2020-5245 https://beanvalidation.org/2.0/spec/#validationapi-message-defaultmessageinterpolation https://docs.jboss.org/hibernate/validator/6.1/reference/en-US/html_single/#section-interpolation-with-message-expressions https://docs.oracle.com/javaee/7/tutorial/jsf-el.htm https://github.com/dropwizard/dropwizard/commit/28479f743a9d0aab6d0e963fc07f3dd98e8c8236 https://github.com/dropwizard/dropwizard/commit/d87d1e4f8e20f6494c0232bf8560c961b46db634 https://github.com/dropwizard/dropwizard/pull/3157 h • CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') •

CVSS: 7.5EPSS: 0%CPEs: 27EXPL: 0

When Connect workers in Apache Kafka 2.0.0, 2.0.1, 2.1.0, 2.1.1, 2.2.0, 2.2.1, or 2.3.0 are configured with one or more config providers, and a connector is created/updated on that Connect cluster to use an externalized secret variable in a substring of a connector configuration property value, then any client can issue a request to the same Connect cluster to obtain the connector's task configuration and the response will contain the plaintext secret rather than the externalized secrets variables. Cuando los trabajadores de Connect en Apache Kafka versiones 2.0.0, 2.0.1, 2.1.0, 2.1.1, 2.2.0, 2.2.1 o 2.3.0, son configurados con uno o más proveedores de configuración, y un conector es creado y actualizado sobre este clúster Connect para usar una variable secreta externalizada en una subcadena de un valor de propiedad de configuración del conector, cualquier cliente puede emitir una petición al mismo clúster de Connect para obtener la configuración de tareas del conector y la respuesta contendrá el secreto de texto plano en lugar de las variables secretas externalizadas. • http://www.openwall.com/lists/oss-security/2020/01/14/1 https://lists.apache.org/thread.html/r0e3a613705d70950aca2bfe9a6265c87503921852d9a3dbce512ca9f%40%3Ccommits.druid.apache.org%3E https://lists.apache.org/thread.html/r2d390dec5f360ec8aa294bef18e1a4385e2a3698d747209216f5a48b%40%3Ccommits.druid.apache.org%3E https://lists.apache.org/thread.html/r3154f5adbc905f1f9012a92240c8e00a96628470cc819453b9606d0e%40%3Ccommits.druid.apache.org%3E https://lists.apache.org/thread.html/r3203d7f25a6ca56ff3e48c43a6aa7cb60b8e5d57d0eed9f76dc2b7a8%40%3Ccommits.druid.apache.org%3E https:/ • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor CWE-319: Cleartext Transmission of Sensitive Information •

CVSS: 7.5EPSS: 0%CPEs: 110EXPL: 0

In Apache Commons Beanutils 1.9.2, a special BeanIntrospector class was added which allows suppressing the ability for an attacker to access the classloader via the class property available on all Java objects. We, however were not using this by default characteristic of the PropertyUtilsBean. En Apache Commons Beanutils 1.9.2, se agregó una clase especial BeanIntrospector que permite suprimir la capacidad de un atacante para acceder al cargador de clases a través de la propiedad de clase disponible en todos los objetos Java. Sin embargo, no se esta usando esta característica por defecto de PropertyUtilsBean. A flaw was found in the Apache Commons BeanUtils, where the class property in PropertyUtilsBean is not suppressed by default. • http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00007.html http://mail-archives.apache.org/mod_mbox/www-announce/201908.mbox/%3cC628798F-315D-4428-8CB1-4ED1ECC958E4%40apache.org%3e https://access.redhat.com/errata/RHSA-2019:4317 https://access.redhat.com/errata/RHSA-2020:0057 https://access.redhat.com/errata/RHSA-2020:0194 https://access.redhat.com/errata/RHSA-2020:0804 https://access.redhat.com/errata/RHSA-2020:0805 https://access.redhat.com/errata/RHSA-2020:0806 • CWE-502: Deserialization of Untrusted Data •

CVSS: 7.5EPSS: 0%CPEs: 29EXPL: 0

An issue was discovered in OpenLDAP 2.x before 2.4.48. When using SASL authentication and session encryption, and relying on the SASL security layers in slapd access controls, it is possible to obtain access that would otherwise be denied via a simple bind for any identity covered in those ACLs. After the first SASL bind is completed, the sasl_ssf value is retained for all new non-SASL connections. Depending on the ACL configuration, this can affect different types of operations (searches, modifications, etc.). In other words, a successful authorization step completed by one user affects the authorization requirement for a different user. • http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00053.html http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00058.html http://seclists.org/fulldisclosure/2019/Dec/26 https://lists.apache.org/thread.html/r1b103833cb5bc8466e24ff0ecc5e75b45a705334ab6a444e64e840a0%40%3Cissues.bookkeeper.apache.org%3E https://lists.apache.org/thread.html/r58af02e294bd07f487e2c64ffc0a29b837db5600e33b6e698b9d696b%40%3Cissues.bookkeeper.apache.org%3E https://lists.apache.org/thread.html/rf4c02775860db415b4955778a131c2795223f61cb8c6a450893651e4%40%3Cissues. •

CVSS: 4.9EPSS: 0%CPEs: 29EXPL: 0

An issue was discovered in the server in OpenLDAP before 2.4.48. When the server administrator delegates rootDN (database admin) privileges for certain databases but wants to maintain isolation (e.g., for multi-tenant deployments), slapd does not properly stop a rootDN from requesting authorization as an identity from another database during a SASL bind or with a proxyAuthz (RFC 4370) control. (It is not a common configuration to deploy a system where the server administrator and a DB administrator enjoy different levels of trust.) Se detectó un problema en el servidor en OpenLDAP anterior a versión 2.4.48. Cuando el administrador del servidor delega los privilegios de tipo rootDN (administrador de base de datos) para ciertas bases de datos, pero quiere mantener el aislamiento (por ejemplo, para implementaciones de múltiples inquilinos), slapd no detiene apropiadamente un rootDN de solicitar una autorización como una identidad de otra base de datos durante un enlace SASL o con un control proxyAuthz (RFC 4370). • http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00053.html http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00058.html http://seclists.org/fulldisclosure/2019/Dec/26 https://kc.mcafee.com/corporate/index?page=content&id=SB10365 https://lists.debian.org/debian-lts-announce/2019/08/msg00024.html https://seclists.org/bugtraq/2019/Dec/23 https://security.netapp.com/advisory/ntap-20190822-0004 https://support.apple.com/kb/HT210788 https://usn.ubuntu.com/4 •