Overview 9 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
9matches
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
9
100.0%
Outside Waratek scope
0
0.0%
Not applicable
0
0.0%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
9
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
1
11.1%
Forecast only
0
0.0%
No public exploit
8
88.9%
split by
peak 3 / year
20031
No exploit published1
Medium1
not blocked1
No public exploit1
20040
20050
20060
20070
20080
20090
20100
20110
20120
20130
20140
20150
20160
20170
20180
20190
20200
20212
No exploit published2
Critical1
Medium1
not blocked2
No public exploit2
20220
20230
20242
No exploit published2
Critical1
High1
not blocked2
Proof of concept only1
No public exploit1
20253
No exploit published3
High2
Medium1
not blocked3
No public exploit3
20261
No exploit published1
High1
not blocked1
No public exploit1
200420062008201020122014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-55225 | High | 2026-09-15 | No exploit published | No public exploit | Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. In Strimzi 1.0.0 and earlier, an attacker who can create a Kafka custom resource can set Kafka.spec.entityOperator watchedNamespace to a target namespace, causing the Cluster Operator to create a Role with full Secret CRUD permissions there and bind it to the Entity Operator ServiceAccount in the attacker's namespace. The attacker can mint a token for that ServiceAccount and read or write Secrets in any target namespace where the Cluster Operator has been granted permissions, regardless of STRIMZI_NAMESPACE. This issue is fixed in versions 1.0.1 and 1.1.0. |
| CVE-2025-58365 | High | 2025-09-08 | No exploit published | No public exploit | The XWiki blog application allows users of the XWiki platform to create and manage blog posts. Prior to version 9.14, the blog application in XWiki allowed remote code execution for any user who has edit right on any page. Normally, these are all logged-in users as they can edit their own user profile. For an exploit, it is sufficient to add an object of type `Blog.BlogPostClass` to any page and to add some script macro with the exploit code to the "Content" field of that object. The vulnerability has been patched in the blog application version 9.14 by executing the content of blog posts with the rights of the appropriate author. No known workarounds are available. |
| CVE-2025-49581 | High | 2025-06-13 | No exploit published | No public exploit | XWiki is a generic wiki platform. Any user with edit right on a page (could be the user's profile) can execute code (Groovy, Python, Velocity) with programming right by defining a wiki macro. This allows full access to the whole XWiki installation. The main problem is that if a wiki macro parameter allows wiki syntax, its default value is executed with the rights of the author of the document where it is used. This can be exploited by overriding a macro like the children macro that is used in a page that has programming right like the page XWiki.ChildrenMacro and thus allows arbitrary script macros. This vulnerability has been patched in XWiki 16.4.7, 16.10.3 and 17.0.0 by executing wiki parameters with the rights of the wiki macro's author when the parameter's value is the default value. |
| CVE-2025-24814 | Medium | 2025-01-27 | No exploit published | No public exploit | Core creation allows users to replace "trusted" configset files with arbitrary configuration Solr instances that (1) use the "FileSystemConfigSetService" component (the default in "standalone" or "user-managed" mode), and (2) are running without authentication and authorization are vulnerable to a sort of privilege escalation wherein individual "trusted" configset files can be ignored in favor of potentially-untrusted replacements available elsewhere on the filesystem. These replacement config files are treated as "trusted" and can use "<lib>" tags to add to Solr's classpath, which an attacker might use to load malicious code as a searchComponent or other plugin. This issue affects all Apache Solr versions up through Solr 9.7. Users can protect against the vulnerability by enabling authentication and authorization on their Solr clusters or switching to SolrCloud (and away from "FileSystemConfigSetService"). Users are also recommended to upgrade to Solr 9.8.0, which mitigates this issue by disabling use of "<lib>" tags by default. |
| CVE-2024-35154 | High | 2024-07-09 | No exploit published | No public exploit | IBM WebSphere Application Server 8.5 and 9.0 could allow a remote authenticated attacker, who has authorized access to the administrative console, to execute arbitrary code. Using specially crafted input, the attacker could exploit this vulnerability to execute arbitrary code on the system. IBM X-Force ID: 292641. |
| CVE-2024-25421 | Critical | 2024-03-26 | No exploit published | Proof of concept only | An issue in Ignite Realtime Openfire v.4.9.0 and before allows a remote attacker to escalate privileges via the ROOM_CACHE component. |
| CVE-2021-41035 | Critical | 2021-10-25 | No exploit published | No public exploit | In Eclipse Openj9 before version 0.29.0, the JVM does not throw IllegalAccessError for MethodHandles that invoke inaccessible interface methods. |
| CVE-2020-27826 | Medium | 2021-05-28 | No exploit published | No public exploit | A flaw was found in Keycloak before version 12.0.0 where it is possible to update the user's metadata attributes using Account REST API. This flaw allows an attacker to change its own NameID attribute to impersonate the admin user for any particular application. |
| CVE-2003-0043 | Medium | 2003-02-07 | No exploit published | No public exploit | Jakarta Tomcat before 3.3.1a, when used with JDK 1.3.1 or earlier, uses trusted privileges when processing the web.xml file, which could allow remote attackers to read portions of some files through the web.xml file. |