CVE Scan for strimzi/operator:latest
Docker image vulnerability scanner
196 Known Vulnerabilities in this Docker Image
| CVE ID | Severity | Package | Affected Version | Fixed Version | CVSS Score |
|---|---|---|---|---|---|
| CVE-2021-44228 | critical | log4j-core | >=2.13.0,<2.15.0 | 2.15.0 | 10.0 |
SummaryLog4j versions prior to 2.16.0 are subject to a remote code execution vulnerability via the ldap JNDI parser. As per Apache's Log4j security guide: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.16.0, this behavior has been disabled by default. Log4j version 2.15.0 contained an earlier fix for the vulnerability, but that patch did not disable attacker-controlled JNDI lookups in all situations. For more information, see the ImpactLogging untrusted or user controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against your application. This includes untrusted data included in logged errors such as exception traces, authentication failures, and other unexpected vectors of user controlled input. Affected versionsAny Log4J version prior to v2.15.0 is affected to this specific issue. The v1 branch of Log4J which is considered End Of Life (EOL) is vulnerable to other RCE vectors so the recommendation is to still update to 2.16.0 where possible. Security releasesAdditional backports of this fix have been made available in versions 2.3.1, 2.12.2, and 2.12.3 Affected packagesOnly the Remediation AdviceUpdated advice for version 2.16.0The Apache Logging Services team provided updated mitigation advice upon the release of version 2.16.0, which disables JNDI by default and completely removes support for message lookups. Even in version 2.15.0, lookups used in layouts to provide specific pieces of context information will still recursively resolve, possibly triggering JNDI lookups. This problem is being tracked as CVE-2021-45046. More information is available on the GitHub Security Advisory for CVE-2021-45046. Users who want to avoid attacker-controlled JNDI lookups but cannot upgrade to 2.16.0 must ensure that no such lookups resolve to attacker-provided data and ensure that the the JndiLookup class is not loaded. Please note that Log4J v1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and we recommend you migrate to Log4J 2.16.0 where possible. Relevance: The CVE-2021-44228 (Log4Shell) is highly relevant if the Strimzi operator uses Log4j for logging and exposes it to untrusted input, such as user-controlled Kafka topics or configurations. It becomes critical in environments where attackers can inject malicious payloads into logs, potentially leading to remote code execution. If the operator mitigates Log4j usage or restricts log input sources, the risk is reduced. (Note: Relevance analysis is automatically generated and may require verification.) Package URL(s):
More Info (NVD): | |||||
| CVE-2022-22824 | medium | expat | <2.1.0-14.el7_9 | 2.1.0-14.el7_9 | 9.8 |
| CVE-2022-23852 | medium | expat | <2.1.0-14.el7_9 | 2.1.0-14.el7_9 | 9.8 |
| CVE-2022-22823 | medium | expat | <2.1.0-14.el7_9 | 2.1.0-14.el7_9 | 9.8 |
| CVE-2022-25236 | high | expat | <2.1.0-14.el7_9 | 2.1.0-14.el7_9 | 9.8 |
| CVE-2022-22822 | medium | expat | <2.1.0-14.el7_9 | 2.1.0-14.el7_9 | 9.8 |
| CVE-2022-2526 | high | systemd | <219-78.el7_9.7 | 219-78.el7_9.7 | 9.8 |
| CVE-2022-25235 | high | expat | <2.1.0-14.el7_9 | 2.1.0-14.el7_9 | 9.8 |
| CVE-2021-27219 | high | glib2 | <2.56.1-9.el7_9 | 2.56.1-9.el7_9 | 9.8 |
| CVE-2022-25315 | high | expat | <2.1.0-14.el7_9 | 2.1.0-14.el7_9 | 9.8 |
Severity Levels
Exploitation could lead to severe consequences, such as system compromise or data loss. Requires immediate attention.
Vulnerability could be exploited relatively easily and lead to significant impact. Requires prompt attention.
Exploitation is possible but might require specific conditions. Impact is moderate. Should be addressed in a timely manner.
Exploitation is difficult or impact is minimal. Address when convenient or as part of regular maintenance.
Severity is not determined, informational, or negligible. Review based on context.
Sliplane is a simple container hosting solution. It enables you to deploy your containers in the cloud within minutes and scale up as you grow.
About the CVE Scanner
What is a CVE?
CVE stands for Common Vulnerabilities and Exposures. It is a standardized identifier for known security vulnerabilities, allowing developers and organizations to track and address potential risks effectively. For more information, visit cve.mitre.org.
About the CVE Scanner
The CVE Scanner is a powerful tool that helps you identify known vulnerabilities in your Docker images. By scanning your images against a comprehensive database of Common Vulnerabilities and Exposures (CVEs), you can ensure that your applications are secure and up-to-date. For more details, checkout the NIST CVE Database.
How the CVE Scanner Works
The CVE Scanner analyzes your Docker images against a comprehensive database of known vulnerabilities. It uses Docker Scout under the hood to provide detailed insights into affected packages, severity levels, and available fixes, empowering you to take immediate action.
Why CVE Scanning is Essential for Your Docker Images
With the rise of supply chain attacks, ensuring the security of your applications has become more critical than ever. CVE scanning plays a vital role in identifying vulnerabilities that could be exploited by attackers, especially those introduced through dependencies and third-party components. Regularly scanning and securing your Docker images is essential to protect your applications from these evolving threats.
Benefits of CVE Scanning
- Enhanced Security: Detect and mitigate vulnerabilities before they are exploited.
- Compliance: Meet industry standards and regulatory requirements for secure software.
- Proactive Maintenance: Stay ahead of potential threats by addressing vulnerabilities early.
The Importance of Patching Docker Images
Patching your Docker images is a critical step in maintaining the security and stability of your applications. By regularly updating your images to include the latest security patches, you can address known vulnerabilities and reduce the risk of exploitation. This proactive approach ensures that your applications remain resilient against emerging threats and helps maintain compliance with security best practices.
Sliplane is not associated with Docker Inc. or any of its products. Prices do not include VAT.