6 results (0.002 seconds)

CVSS: 9.8EPSS: 0%CPEs: 7EXPL: 6

In spring security versions prior to 5.4.11+, 5.5.7+ , 5.6.4+ and older unsupported versions, RegexRequestMatcher can easily be misconfigured to be bypassed on some servlet containers. Applications using RegexRequestMatcher with `.` in the regular expression are possibly vulnerable to an authorization bypass. En las versiones 5.5.6 y 5.6.3 de Spring Security y en versiones anteriores no soportadas, RegexRequestMatcher puede ser fácilmente configurado de forma incorrecta para ser evitado en algunos contenedores de servlets. Las aplicaciones que utilizan RegexRequestMatcher con `.` en la expresión regular son posiblemente vulnerables a un bypass de autorización A flaw was found in Spring Security. When using RegexRequestMatcher, an easy misconfiguration can bypass some servlet containers. • https://github.com/DeEpinGh0st/CVE-2022-22978 https://github.com/ducluongtran9121/CVE-2022-22978-PoC https://github.com/aeifkz/CVE-2022-22978 https://github.com/umakant76705/CVE-2022-22978 https://github.com/Raghvendra1207/CVE-2022-22978 https://github.com/wan9xx/CVE-2022-22978-demo https://spring.io/security/cve-2022-22978 https://access.redhat.com/security/cve/CVE-2022-22978 https://bugzilla.redhat.com/show_bug.cgi?id=2087606 • CWE-863: Incorrect Authorization CWE-1220: Insufficient Granularity of Access Control •

CVSS: 9.0EPSS: 0%CPEs: 11EXPL: 0

Spring Security 5.4.x prior to 5.4.4, 5.3.x prior to 5.3.8.RELEASE, 5.2.x prior to 5.2.9.RELEASE, and older unsupported versions can fail to save the SecurityContext if it is changed more than once in a single request.A malicious user cannot cause the bug to happen (it must be programmed in). However, if the application's intent is to only allow the user to run with elevated privileges in a small portion of the application, the bug can be leveraged to extend those privileges to the rest of the application. Spring Security versiones 5.4.x anteriores a 5.4.4, versiones 5.3.x anteriores a 5.3.8.RELEASE, versiones 5.2.x anteriores a 5.2.9.RELEASE, y versiones anteriores no compatibles, pueden producir un fallo al guardar el SecurityContext si se cambia más de una vez en una sola petición. Un usuario malicioso no puede causar el error (debe estar programado). Sin embargo, si la intención de la aplicación es sólo permitir que el usuario solo se ejecute con privilegios elevados en una pequeña parte de la aplicación, el error puede ser aprovechado para extender esos privilegios al resto de la aplicación • http://www.openwall.com/lists/oss-security/2021/02/19/7 https://lists.apache.org/thread.html/r163b3e4e39803882f5be05ee8606b2b9812920e196daa2a82997ce14%40%3Cpluto-dev.portals.apache.org%3E https://lists.apache.org/thread.html/r2cb05e499807900ba23e539643eead9c5f0652fd271f223f89da1804%40%3Cpluto-scm.portals.apache.org%3E https://lists.apache.org/thread.html/r37423ec7eea340e92a409452c35b649dce02fdc467f0b3f52086c177%40%3Cpluto-dev.portals.apache.org%3E https://lists.apache.org/thread.html/r3868207b967f926819fe3aa8d33f1666429be589bb4a62104a49f4e3%40%3Cpluto-dev.portals.apache. •

CVSS: 9.8EPSS: 0%CPEs: 10EXPL: 0

When using the CAS Proxy ticket authentication from Spring Security 3.1 to 3.2.4 a malicious CAS Service could trick another CAS Service into authenticating a proxy ticket that was not associated. This is due to the fact that the proxy ticket authentication uses the information from the HttpServletRequest which is populated based upon untrusted information within the HTTP request. This means if there are access control restrictions on which CAS services can authenticate to one another, those restrictions can be bypassed. If users are not using CAS Proxy tickets and not basing access control decisions based upon the CAS Service, then there is no impact to users. Cuando se utiliza la autenticación de tickets de Proxy CAS de Spring Security, versiones de la 3.1 a la 3.2.4, un servicio CAS malicioso permitiría engañar a otro servicio CAS para autenticar un ticket proxy que no estaba asociado. • https://pivotal.io/security/cve-2014-3527 • CWE-287: Improper Authentication •

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

Both Spring Security 3.2.x, 4.0.x, 4.1.0 and the Spring Framework 3.2.x, 4.0.x, 4.1.x, 4.2.x rely on URL pattern mappings for authorization and for mapping requests to controllers respectively. Differences in the strictness of the pattern matching mechanisms, for example with regards to space trimming in path segments, can lead Spring Security to not recognize certain paths as not protected that are in fact mapped to Spring MVC controllers that should be protected. The problem is compounded by the fact that the Spring Framework provides richer features with regards to pattern matching as well as by the fact that pattern matching in each Spring Security and the Spring Framework can easily be customized creating additional differences. Tanto en Spring Security versiones 3.2.x, 4.0.x, 4.1.0 como el Framework Spring versiones 3.2.x, 4.0.x, 4.1.x, 4.2.x, se basan en el mapeo de patrones de URL para la autorización y para mapear las peticiones hacia los controladores, respectivamente. Las diferencias en el rigor de los mecanismos de coincidencia de patrones, por ejemplo con respecto al recorte de espacio en los segmentos de ruta (path), pueden hacer que Spring Security no reconozca ciertas rutas (paths) como no protegidas que de hecho se asignan a los controladores MVC de Spring que deben protegerse. • http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html http://www.securityfocus.com/bid/91687 https://pivotal.io/security/cve-2016-5007 https://www.oracle.com/technetwork/security-advisory/cpujul2019-5072835.html • CWE-264: Permissions, Privileges, and Access Controls •

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

An issue was discovered in Pivotal Spring Security before 3.2.10, 4.1.x before 4.1.4, and 4.2.x before 4.2.1. Spring Security does not consider URL path parameters when processing security constraints. By adding a URL path parameter with an encoded "/" to a request, an attacker may be able to bypass a security constraint. The root cause of this issue is a lack of clarity regarding the handling of path parameters in the Servlet Specification. Some Servlet containers include path parameters in the value returned for getPathInfo() and some do not. • http://www.securityfocus.com/bid/95142 https://access.redhat.com/errata/RHSA-2017:1832 https://pivotal.io/security/cve-2016-9879 https://access.redhat.com/security/cve/CVE-2016-9879 https://bugzilla.redhat.com/show_bug.cgi?id=1409838 • CWE-20: Improper Input Validation CWE-417: Communication Channel Errors •