CVE-2025-11226
07h26 +00:00
CVE 描述
Conditional processing of logback.xml configuration file, in conjuction with Spring Framework and Janino
ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.18 in Java applications, allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. A successful attack requires the presence of Janino library and Spring Framework to be present on the user's class path. In addition, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege.CVE 解決方案
CVE 資訊
相關弱點
| 弱點名稱 | 來源 | |
|---|---|---|
| Improper Input Validation The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. |
指標
| 指標 | 評分 | 嚴重程度 | CVSS 向量 | 來源 |
|---|---|---|---|---|
| V4.0 | 7 | HIGH |
CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:N/SC:L/SI:L/SA:N/S:P/AU:N/RE:M/U:Green
更多資訊
Base: Exploitabilty MetricsThe Exploitability metrics reflect the characteristics of the “thing that is vulnerable”, which we refer to formally as the vulnerable system. Attack Vector This metric reflects the context by which vulnerability exploitation is possible. Local The vulnerable system is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or through terminal emulation (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document). Attack Complexity This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. Low The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system. Attack Requirements This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. Present The successful attack depends on the presence of specific deployment and execution conditions of the vulnerable system that enable the attack. These include: A race condition must be won to successfully exploit the vulnerability. The successfulness of the attack is conditioned on execution conditions that are not under full control of the attacker. The attack may need to be launched multiple times against a single target before being successful. Network injection. The attacker must inject themselves into the logical network path between the target and the resource requested by the victim (e.g. vulnerabilities requiring an on-path attacker). Privileges Required This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. High The attacker requires privileges that provide significant (e.g., administrative) control over the vulnerable system allowing full access to the vulnerable system’s settings and files. User Interaction This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. None The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges Base: Impact MetricsThe Impact metrics capture the effects of a successfully exploited vulnerability. Analysts should constrain impacts to a reasonable, final outcome which they are confident an attacker is able to achieve. Confidentiality Impact This metric measures the impact to the confidentiality of the information managed by the system due to a successfully exploited vulnerability. High There is a total loss of confidentiality, resulting in all information within the Vulnerable System being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server. Integrity Impact This metric measures the impact to integrity of a successfully exploited vulnerability. High There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the Vulnerable System. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the Vulnerable System. Availability Impact This metric measures the impact to the availability of the impacted system resulting from a successfully exploited vulnerability. None There is no impact to availability within the Vulnerable System. Sub Confidentiality Impact Low There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the Subsequent System. Sub Integrity Impact Low Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact to the Subsequent System. Sub Availability Impact None There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System. Threat MetricsThe Threat metrics measure the current state of exploit techniques or code availability for a vulnerability. Environmental MetricsThese metrics enable the consumer analyst to customize the resulting score depending on the importance of the affected IT asset to a user’s organization, measured in terms of complementary/alternative security controls in place, Confidentiality, Integrity, and Availability. The metrics are the modified equivalent of Base metrics and are assigned values based on the system placement within organizational infrastructure. Supplemental MetricsSupplemental metric group provides new metrics that describe and measure additional extrinsic attributes of a vulnerability. While the assessment of Supplemental metrics is provisioned by the provider, the usage and response plan of each metric within the Supplemental metric group is determined by the consumer. Automatable The “Automatable” metric captures the answer to the question ”Can an attacker automate exploitation events for this vulnerability across multiple targets?” based on steps 1-4 of the kill chain2 [Hutchins et al., 2011]. These steps are reconnaissance, weaponization, delivery, and exploitation. If evaluated, the metric can take the values no or yes. No Attackers cannot reliably automate all 4 steps of the kill chain for this vulnerability for some reason. These steps are reconnaissance, weaponization, delivery, and exploitation. Safety Like all Supplemental Metrics, providing a value for Safety is completely optional. Suppliers and vendors (AKA: scoring providers) may or may not provide Safety as a Supplemental Metric as they see fit. Present Consequences of the vulnerability meet definition of IEC 61508 consequence categories of 'marginal', 'critical', or 'catastrophic'. Vulnerability Response Effort The intention of the Vulnerability Response Effort metric is to provide supplemental information on how difficult it is for consumers to provide an initial response to the impact of vulnerabilities for deployed products and services in their infrastructure. Moderate The actions required to respond to a vulnerability require some effort on behalf of the consumer and could cause minimal service impact to implement. Examples include: simple remote update, disabling of a subsystem, or a low-touch software upgrade such as a driver update. Provider Urgency Many vendors currently provide supplemental severity ratings to consumers via product security advisories. Green Provider has assessed the impact of this vulnerability as having a reduced urgency. |
