Page 5 of 43 results (0.007 seconds)

CVSS: 7.5EPSS: 0%CPEs: 4EXPL: 2

In the Jakarta Expression Language implementation 3.0.3 and earlier, a bug in the ELParserTokenManager enables invalid EL expressions to be evaluated as if they were valid. En la implementación de Jakarta Expression Language versiones 3.0.3 y anteriores, un bug en la función ELParserTokenManager permite que las expresiones EL no válidas sean evaluadas como si fueran válidas • https://github.com/eclipse-ee4j/el-ri/issues/155 https://securitylab.github.com/advisories/GHSL-2020-021-jakarta-el https://www.oracle.com/security-alerts/cpuapr2022.html https://access.redhat.com/security/cve/CVE-2021-28170 https://bugzilla.redhat.com/show_bug.cgi?id=1965497 • CWE-20: Improper Input Validation CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') •

CVSS: 9.1EPSS: 0%CPEs: 5EXPL: 1

Apache Maven will follow repositories that are defined in a dependency’s Project Object Model (pom) which may be surprising to some users, resulting in potential risk if a malicious actor takes over that repository or is able to insert themselves into a position to pretend to be that repository. Maven is changing the default behavior in 3.8.1+ to no longer follow http (non-SSL) repository references by default. More details available in the referenced urls. If you are currently using a repository manager to govern the repositories used by your builds, you are unaffected by the risks present in the legacy behavior, and are unaffected by this vulnerability and change to default behavior. See this link for more information about repository management: https://maven.apache.org/repository-management.html Apache Maven seguirá los repositorios que se definen en el Project Object Model (pom) de una dependencia, lo que puede resultar sorprendente para algunos usuarios, resultando en un riesgo potencial si un actor malicioso se hace cargo de ese repositorio o es capaz de insertarse en una posición para fingir ser ese repositorio. • http://www.openwall.com/lists/oss-security/2021/04/23/5 https://lists.apache.org/thread.html/r0556ce5db7231025785477739ee416b169d8aff5ee9bac7854d64736%40%3Cannounce.apache.org%3E https://lists.apache.org/thread.html/r06db4057b74e0598a412734f693a34a8836ac6f06d16d139e5e1027c%40%3Cdev.maven.apache.org%3E https://lists.apache.org/thread.html/r07a89b32783f73bda6903c1f9aadeb859e5bef0a4daed6d87db8e4a9%40%3Cissues.karaf.apache.org%3E https://lists.apache.org/thread.html/r08a401f8c98a99f68d061fde6e6659d695f28d60fe4f0413bcb355b0%40%3Ccommits.druid.apache.org%3E https://lists • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor CWE-346: Origin Validation Error •

CVSS: 8.0EPSS: 0%CPEs: 2EXPL: 1

In Gradle from version 5.1 and before version 7.0 there is a vulnerability which can lead to information disclosure and/or dependency poisoning. Repository content filtering is a security control Gradle introduced to help users specify what repositories are used to resolve specific dependencies. This feature was introduced in the wake of the "A Confusing Dependency" blog post. In some cases, Gradle may ignore content filters and search all repositories for dependencies. This only occurs when repository content filtering is used from within a `pluginManagement` block in a settings file. • https://docs.gradle.org/7.0/release-notes.html#security-advisories https://github.com/gradle/gradle/security/advisories/GHSA-jvmj-rh6q-x395 https://access.redhat.com/security/cve/CVE-2021-29427 https://bugzilla.redhat.com/show_bug.cgi?id=1949638 • CWE-829: Inclusion of Functionality from Untrusted Control Sphere •

CVSS: 8.8EPSS: 0%CPEs: 2EXPL: 1

In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. • https://docs.gradle.org/7.0/release-notes.html#security-advisories https://github.com/gradle/gradle/pull/15240 https://github.com/gradle/gradle/pull/15654 https://github.com/gradle/gradle/security/advisories/GHSA-89qm-pxvm-p336 https://access.redhat.com/security/cve/CVE-2021-29428 https://bugzilla.redhat.com/show_bug.cgi?id=1949643 • CWE-276: Incorrect Default Permissions CWE-378: Creation of Temporary File With Insecure Permissions CWE-379: Creation of Temporary File in Directory with Insecure Permissions •

CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 1

In Gradle before version 7.0, files created with open permissions in the system temporary directory can allow an attacker to access information downloaded by Gradle. Some builds could be vulnerable to a local information disclosure. Remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. Sensitive information contained in these files can be exposed to other local users on the same system. If you do not use the `TextResourceFactory` API, you are not vulnerable. • https://docs.gradle.org/7.0/release-notes.html#security-advisories https://github.com/gradle/gradle/security/advisories/GHSA-fp8h-qmr5-j4c8 https://access.redhat.com/security/cve/CVE-2021-29429 https://bugzilla.redhat.com/show_bug.cgi?id=1949636 • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor CWE-377: Insecure Temporary File •