Skip to content

← Public intelligence

Maven package

org.apache.ivy:ivy

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 8.8MavenPublished

    Apache Ivy External Entity Reference vulnerability

    CVE-2022-46751 · GHSA-2jc4-r94c-rp7h

    Affected
    • Maven org.apache.ivy:ivy < 2.5.2
    Fixed in
    2.5.2· Vendor fix available
    Issue
    Improper Restriction of XML External Entity Reference, XML Injection (aka Blind XPath Injection) vulnerability in Apache Software Foundation Apache Ivy.This issue affects any version of Apache Ivy prior to 2.5.2. When Apache Ivy prior to 2.5.2 parses XML files - either its own configuration, Ivy files or Apache Maven POMs - it will allow downloading external document type definitions and expand any entity references contained therein when used. This can be used to exfiltrate data, access resources only the machine running Ivy has access to or disturb the execution of Ivy in different ways. Starting with Ivy 2.5.2 DTD processing is disabled by default except when parsing Maven POMs where the default is to allow DTD processing but only to include a DTD snippet shipping with Ivy that is needed to deal with existing Maven POMs that are not valid XML files but are nevertheless accepted by Maven. Access can be be made more lenient via newly introduced system properties where needed. Users…

    Recommended action: Upgrade to 2.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  2. High, CVSS 7.5MavenPublished

    Apache Ivy vulnerable to path traversal

    CVE-2022-37866 · GHSA-wv7w-rj2x-556x

    Affected
    • Maven org.apache.ivy:ivy >= 2.0.0, < 2.5.1
    Fixed in
    2.5.1· Vendor fix available
    Issue
    When Apache Ivy downloads artifacts from a repository it stores them in the local file system based on a user-supplied "pattern" that may include placeholders for artifacts coordinates like the organisation, module or version. If said coordinates contain "../" sequences - which are valid characters for Ivy coordinates in general - it is possible the artifacts are stored outside of Ivy's local cache or repository or can overwrite different artifacts inside of the local cache. In order to exploit this vulnerability an attacker needs collaboration by the remote repository as Ivy will issue http requests containing ".." sequences and a "normal" repository will not interpret them as part of the artifact coordinates. Users of Apache Ivy versions 2.0.0 to 2.5.1 should upgrade to Ivy 2.5.1.

    Recommended action: Upgrade to 2.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  3. Critical, CVSS 9.1MavenPublished

    Apache Ivy does not verify target path when extracting the archive

    CVE-2022-37865 · GHSA-94rr-4jr5-9h2p

    Affected
    • Maven org.apache.ivy:ivy >= 2.4.0, < 2.5.1
    Fixed in
    2.5.1· Vendor fix available
    Issue
    With Apache Ivy 2.4.0 an optional packaging attribute has been introduced that allows artifacts to be unpacked on the fly if they used pack200 or zip packaging. For artifacts using the "zip", "jar" or "war" packaging Ivy prior to version 2.5.1 doesn't verify the target path when extracting the archive. An archive containing absolute paths or paths that try to traverse "upwards" using ".." sequences can then write files to any location on the local fie system that the user executing Ivy has write access to. Ivy users of version 2.4.0 to 2.5.0 should upgrade to Ivy version 2.5.1.

    Recommended action: Upgrade to 2.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →