Security
Headlines
HeadlinesLatestCVEs

Tag

#java

CVE-2023-39699: WSTG - v4.2 | OWASP Foundation

IceWarp Mail Server v10.4.5 was discovered to contain a local file inclusion (LFI) vulnerability via the component /calendar/minimizer/index.php. This vulnerability allows attackers to include or execute files from the local file system of the targeted server.

CVE
#xss#vulnerability#web#ios#dos#js#java#php#rce#perl
CVE-2023-40030: Malicious dependencies can inject arbitrary JavaScript into cargo-generated timing reports

Cargo downloads a Rust project’s dependencies and compiles the project. Starting in Rust 1.60.0 and prior to 1.72, Cargo did not escape Cargo feature names when including them in the report generated by `cargo build --timings`. A malicious package included as a dependency may inject nearly arbitrary HTML here, potentially leading to cross-site scripting if the report is subsequently uploaded somewhere. The vulnerability affects users relying on dependencies from git, local paths, or alternative registries. Users who solely depend on crates.io are unaffected. Rust 1.60.0 introduced `cargo build --timings`, which produces a report of how long the different steps of the build process took. It includes lists of Cargo features for each crate. Prior to Rust 1.72, Cargo feature names were allowed to contain almost any characters (with some exceptions as used by the feature syntax), but it would produce a future incompatibility warning about them since Rust 1.49. crates.io is far more stringe...

CVE-2023-39519: There is a risk of sensitive information leakage in the user information acquisition of CloudExplorer Lite

Cloud Explorer Lite is an open source cloud management platform. Prior to version 1.4.0, there is a risk of sensitive information leakage in the user information acquisition of CloudExplorer Lite. The vulnerability has been fixed in version 1.4.0.

GHSA-wrrj-h57r-vx9p: Malicious dependencies can inject arbitrary JavaScript into cargo-generated timing reports

The Rust Security Response WG was notified that Cargo did not escape Cargo feature names when including them in the report generated by `cargo build --timings`. A malicious package included as a dependency may inject nearly arbitrary HTML here, potentially leading to XSS if the report is subsequently uploaded somewhere. The severity of this vulnerability is "low" for users relying on dependencies from git, local paths, or alternative registries. Users who solely depend on crates.io are unaffected. Note that **by design** Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerability in this advisory allows performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it's possible to perform the same attacks with build scripts and procedural macros. # Overview Rust 1.60.0 [introduced](https://blog.rust-lang.org/2022/04/07/Rust-1.60.0.html#cargo...

GHSA-crqf-q9fp-hwjw: Spring-Kafka has Java Deserialization vulnerability When Improperly Configured

In Spring for Apache Kafka 3.0.9 and earlier and versions 2.9.10 and earlier, a possible deserialization attack vector existed, but only if unusual configuration was applied. An attacker would have to construct a malicious serialized object in one of the deserialization exception record headers. Specifically, an application is vulnerable when all of the following are true: * The user does not configure an ErrorHandlingDeserializer for the key and/or value of the record * The user explicitly sets container properties checkDeserExWhenKeyNull and/or checkDeserExWhenValueNull container properties to true. * The user allows untrusted sources to publish to a Kafka topic By default, these properties are false, and the container only attempts to deserialize the headers if an ErrorHandlingDeserializer is configured. The ErrorHandlingDeserializer prevents the vulnerability by removing any such malicious headers before processing the record.

CVE-2023-34040: CVE-2023-34040: Java Deserialization vulnerability in Spring-Kafka When Improperly Configured

In Spring for Apache Kafka 3.0.9 and earlier and versions 2.9.10 and earlier, a possible deserialization attack vector existed, but only if unusual configuration was applied. An attacker would have to construct a malicious serialized object in one of the deserialization exception record headers. Specifically, an application is vulnerable when all of the following are true: * The user does not configure an ErrorHandlingDeserializer for the key and/or value of the record * The user explicitly sets container properties checkDeserExWhenKeyNull and/or checkDeserExWhenValueNull container properties to true. * The user allows untrusted sources to publish to a Kafka topic By default, these properties are false, and the container only attempts to deserialize the headers if an ErrorHandlingDeserializer is configured. The ErrorHandlingDeserializer prevents the vulnerability by removing any such malicious headers before processing the record.

Lazarus Group exploits ManageEngine vulnerability to deploy QuiteRAT

This is the third documented campaign attributed to this actor in less than a year, with the actor reusing the same infrastructure throughout these operations.

Thousands of Unpatched Openfire XMPP Servers Still Exposed to High-Severity Flaw

Thousands of Openfire XMPP servers are unpatched against a recently disclosed high-severity flaw and are susceptible to a new exploit, according to a new report from VulnCheck. Tracked as CVE-2023-32315 (CVSS score: 7.5), the vulnerability relates to a path traversal vulnerability in Openfire's administrative console that could permit an unauthenticated attacker to access otherwise restricted

CVE-2023-40572: XWIKI-20849: Require a CSRF token in the create action · xwiki/xwiki-platform@4b20528

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. The create action is vulnerable to a CSRF attack, allowing script and thus remote code execution when targeting a user with script/programming right, thus compromising the confidentiality, integrity and availability of the whole XWiki installation. When a user with script right views this image and a log message `ERROR foo - Script executed!` appears in the log, the XWiki installation is vulnerable. This has been patched in XWiki 14.10.9 and 15.4RC1 by requiring a CSRF token for the actual page creation.