Overview 3 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
3matches
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
3
100.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
3
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
3
100.0%
split by
peak 1 / quarter
Q3 211
No exploit published1
Medium1
not blocked1
No public exploit1
Q4 210
Q1 220
Q2 220
Q3 220
Q4 220
Q1 230
Q2 230
Q3 230
Q4 230
Q1 240
Q2 240
Q3 240
Q4 240
Q1 250
Q2 250
Q3 250
Q4 251
No exploit published1
Medium1
not blocked1
No public exploit1
Q1 261
No exploit published1
Medium1
not blocked1
No public exploit1
Q3 21Q1 22Q3 22Q1 23Q3 23Q1 24Q3 24Q1 25Q3 25Q1 26
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-23903 | Medium | 2026-02-09 | No exploit published | No public exploit | 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.1.0 and later has a new parameters to remediate this issue shiro.ini: filterChainResolver.caseInsensitive = true application.properties: shiro.caseInsensitive=true Shiro 3.0.0 and later makes this the default in shiro.ini-based configurations. Shiro 3.0.1 and later makes this the default in all configurations, including programmatic and Spring / Spring Boot. |
| CVE-2025-14777 | Medium | 2025-12-16 | No exploit published | No public exploit | A flaw was found in Keycloak. An IDOR (Broken Access Control) vulnerability exists in the admin API endpoints for authorization resource management, specifically in ResourceSetService and PermissionTicketService. The system checks authorization against the resourceServer (client) ID provided in the API request, but the backend database lookup and modification operations (findById, delete) only use the resourceId. This mismatch allows an authenticated attacker with fine-grained admin permissions for one client (e.g., Client A) to delete or update resources belonging to another client (Client B) within the same realm by supplying a valid resource ID. |
| CVE-2021-30640 | Medium | 2021-07-12 | No exploit published | No public exploit | A vulnerability in the JNDI Realm of Apache Tomcat allows an attacker to authenticate using variations of a valid user name and/or to bypass some of the protection provided by the LockOut Realm. This issue affects Apache Tomcat 10.0.0-M1 to 10.0.5; 9.0.0.M1 to 9.0.45; 8.5.0 to 8.5.65. |