Threats affecting pkg:brew/travis

Addressable versions from 2.2.5 through 2.9.0 contain a URI normalization flaw where paths with certain '..' segments are incorrectly resolved, deviating from RFC 3986. This can cause normalized paths to appear within an allowed directory while the actual resolved path points outside it, enabling potential path traversal bypasses of allowlist checks. The issue is fixed in version 2.9.1. Applications that rely on Addressable's normalization for access control but send the original URI to other components that resolve paths correctly are vulnerable. Rejecting paths with '..' segments or upgrading to 2.9.1 mitigates the risk.

Addressable versions prior to 2.9.1 contain a denial of service vulnerability in the URI path normalization function. The function normalize_path operates with quadratic time complexity relative to the number of nested dot segments in a URI path, causing excessive resource consumption when processing crafted inputs. This can lead to denial of service when normalizing, comparing, or joining URIs derived from untrusted sources. The issue is fixed in version 2.9.1.

Addressable library versions >= 2.0.0 (pure-Ruby IDNA) and >= 2.5.2 (native IDNA) have an issue where display_uri can show misleading hostnames containing bidirectional and invisible Unicode characters. This can cause malicious domains to appear visually similar to trusted ones in user interfaces that show display_uri, such as link previews or admin panels. The flaw affects only the displayed form, not the actual host parsing or connections. It is fixed in version 2.9.1, where such labels are returned unchanged.

A vulnerability in the pure-Ruby IDNA implementation of the Addressable library allows certain invalid Punycode A-labels to be decoded incorrectly by the to_unicode method. This causes the display_uri method to show misleading hostnames that differ from the actual host used in connections. This can lead to confusion or incorrect trust decisions if applications rely on display_uri or to_unicode output for security checks. The issue affects Addressable versions from 2.0.0 up to but not including 2.9.1 and is fixed in version 2.9.1. Using the native IDNA implementation or avoiding security decisions based on display_uri output mitigates the risk.

Addressable versions from 2.3.0 (excluding yanked 2.3.0 and 2.3.1) through 2.9.0 contain a Regular Expression Denial of Service (ReDoS) vulnerability in URI template matching. This occurs when templates include multiple variables in one expression or several single-variable expressions adjacent to each other, causing excessive backtracking in the regex engine. The vulnerability affects Ruby implementations with backtracking regex engines such as MRI Ruby before 3.3, JRuby, and TruffleRuby 40.0. It can lead to denial of service by consuming excessive CPU resources when matching crafted URIs. The issue is fixed in Addressable 2.9.1 and MRI Ruby 3.3 or later.

Addressable versions from 2.3.0 (excluding yanked 2.3.0 and 2.3.1) through 2.9.0 contain a Regular Expression Denial of Service (ReDoS) vulnerability in URI template matching when using the explode modifier (*) with certain operators. This flaw causes catastrophic backtracking in regex matching, leading to exponential processing time and denial of service when maliciously crafted URIs are matched. The issue is fixed in version 2.9.1. Ruby MRI versions prior to 3.2 and JRuby are vulnerable due to their regex engines lacking backtracking memoization, while MRI 3.2+ and TruffleRuby 40.0 are not affected. Users only expanding templates or not using template matching are unaffected.