| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Server-side request forgery (ssrf) in Microsoft Bing allows an unauthorized attacker to perform tampering over a network. |
| Insufficiently protected credentials in Azure DevOps allows an unauthorized attacker to elevate privileges over a network. |
| The Log4j1XmlLayout from the Apache Log4j 1-to-Log4j 2 bridge fails to escape characters forbidden by the XML 1.0 standard, producing malformed XML output. Conforming XML parsers are required to reject documents containing such characters with a fatal error, which may cause downstream log processing systems to drop or fail to index affected records.
Two groups of users are affected:
* Those using Log4j1XmlLayout directly in a Log4j Core 2 configuration file.
* Those using the Log4j 1 configuration compatibility layer with org.apache.log4j.xml.XMLLayout specified as the layout class.
Users are advised to upgrade to Apache Log4j 1-to-Log4j 2 bridge version 2.25.4, which corrects this issue.
Note: The Apache Log4j 1-to-Log4j 2 bridge is deprecated and will not be present in Log4j 3. Users are encouraged to consult the Log4j 1 to Log4j 2 migration guide https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html , and specifically the section on eliminating reliance on the bridge. |
| Improper neutralization of special elements used in an os command ('os command injection') in Microsoft Bing Images allows an unauthorized attacker to execute code over a network. |
| Apache Log4j Core's XmlLayout https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout , in versions up to and including 2.25.3, fails to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets producing invalid XML output whenever a log message or MDC value contains such characters.
The impact depends on the StAX implementation in use:
* JRE built-in StAX: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream log-processing systems to drop the affected records.
* Alternative StAX implementations (e.g., Woodstox https://github.com/FasterXML/woodstox , a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j's internal status logger.
Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output. |
| Server-side request forgery (ssrf) in Microsoft Purview allows an unauthorized attacker to elevate privileges over a network. |
| Server-side request forgery (ssrf) in Microsoft Purview allows an unauthorized attacker to elevate privileges over a network. |
| Apache Log4j's JsonTemplateLayout https://logging.apache.org/log4j/2.x/manual/json-template-layout.html , in versions up to and including 2.25.3, produces invalid JSON output when log events contain non-finite floating-point values (NaN, Infinity, or -Infinity), which are prohibited by RFC 8259. This may cause downstream log processing systems to reject or fail to index affected records.
An attacker can exploit this issue only if both of the following conditions are met:
* The application uses JsonTemplateLayout.
* The application logs a MapMessage containing an attacker-controlled floating-point value.
Users are advised to upgrade to Apache Log4j JSON Template Layout 2.25.4, which corrects this issue. |
| External initialization of trusted variables or data stores in Azure Entra ID allows an unauthorized attacker to elevate privileges locally. |
| Apache Log4cxx's XMLLayout https://logging.apache.org/log4cxx/1.7.0/classlog4cxx_1_1xml_1_1XMLLayout.html , in versions before 1.7.0, fails to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets in log messages, NDC, and MDC property keys and values, producing invalid XML output. Conforming XML parsers must reject such documents with a fatal error, which may cause downstream log processing systems to drop or fail to index affected records.
An attacker who can influence logged data can exploit this to suppress individual log records, impairing audit trails and detection of malicious activity.
Users are advised to upgrade to Apache Log4cxx 1.7.0, which fixes this issue. |
| Initialization of a resource with an insecure default in Azure Compute Gallery allows an authorized attacker to disclose information over a network. |
| CR/LF bytes were not rejected by HTTP client proxy tunnel headers or host. |
| Payment Orchestrator Service Elevation of Privilege Vulnerability |
| '.../...//' in Azure Compute Gallery allows an authorized attacker to elevate privileges locally. |
| When calling base64.b64decode() or related functions the decoding process would stop after encountering the first padded quad regardless of whether there was more information to be processed. This can lead to data being accepted which may be processed differently by other implementations. Use "validate=True" to enable stricter processing of base64 data. |
| Microsoft Devices Pricing Program Remote Code Execution Vulnerability |
| Permissive regular expression in Azure Compute Gallery allows an authorized attacker to elevate privileges locally. |
| Axios is a promise based HTTP client for the browser and Node.js. Prior to 1.15.0 and 0.3.1, the Axios library is vulnerable to a specific "Gadget" attack chain that allows Prototype Pollution in any third-party dependency to be escalated into Remote Code Execution (RCE) or Full Cloud Compromise (via AWS IMDSv2 bypass). This vulnerability is fixed in 1.15.0 and 0.3.1. |
| Improper resolution of path equivalence in Windows MapUrlToZone allows an unauthorized attacker to bypass a security feature over a network. |
| Net::CIDR::Lite versions before 0.23 for Perl does not validate IPv6 group count, which may allow IP ACL bypass.
_pack_ipv6() does not check that uncompressed IPv6 addresses (without ::) have exactly 8 hex groups. Inputs like "abcd", "1:2:3", or "1:2:3:4:5:6:7" are accepted and produce packed values of wrong length (3, 7, or 15 bytes instead of 17).
The packed values are used internally for mask and comparison operations. find() and bin_find() use Perl string comparison (lt/gt) on these values, and comparing strings of different lengths gives wrong results. This can cause find() to incorrectly report an address as inside or outside a range.
Example:
my $cidr = Net::CIDR::Lite->new("::/8");
$cidr->find("1:2:3"); # invalid input, incorrectly returns true
This is the same class of input validation issue as CVE-2021-47154 (IPv4 leading zeros) previously fixed in this module.
See also CVE-2026-40199, a related issue in the same function affecting IPv4 mapped IPv6 addresses. |
