Page 7 of 39 results (0.026 seconds)

CVSS: 6.9EPSS: 6%CPEs: 206EXPL: 5

In jQuery versions greater than or equal to 1.2 and before 3.5.0, passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0. En las versiones de jQuery mayores o iguales a 1.2 y anteriores a la versión 3.5.0, se puede ejecutar HTML desde fuentes no seguras, incluso después de desinfectarlo, a uno de los métodos de manipulación DOM de jQuery (es decir .html (), .append () y otros). código no seguro Este problema está corregido en jQuery 3.5.0. A Cross-site scripting (XSS) vulnerability exists in JQuery. This flaw allows an attacker with the ability to supply input to the ‘HTML’ function to inject Javascript into the page where that input is rendered, and have it delivered by the browser. jQuery version 1.2 suffers from a cross site scripting vulnerability. • https://www.exploit-db.com/exploits/49766 https://github.com/0xAJ2K/CVE-2020-11022-CVE-2020-11023 https://github.com/ossf-cve-benchmark/CVE-2020-11022 https://github.com/Snorlyd/https-nj.gov---CVE-2020-11022 http://lists.opensuse.org/opensuse-security-announce/2020-07/msg00067.html http://lists.opensuse.org/opensuse-security-announce/2020-07/msg00085.html http://lists.opensuse.org/opensuse-security-announce/2020-11/msg00039.html http://packetstormsecurity.com/files/162159/jQuery-1.2& • CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') •

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. •