CVE-2026-3479

What it actually does

This issue is disputed: the project clarified that pkgutil.get_data() intentionally follows the same security model as open(), and that earlier documentation incorrectly implied stronger validation of the resource argument. If an application passes attacker-controlled resource paths to pkgutil.get_data(), path traversal-style access may occur according to normal file-access permissions, but this is considered unsafe application usage rather than a vulnerability in the function itself. The supplied CVSS vector indicates no direct confidentiality, integrity, or availability impact.

Why it matters to the business

The main risk is misconfiguration or unsafe application design: software that relied on the old documentation rather than enforcing its own path restrictions may unintentionally read local files accessible to the application process. Because the issue is disputed, has very low EPSS, no known exploit maturity, is not in CISA KEV, and is not associated with ransomware activity, broad emergency response is not warranted; teams should instead review code paths where untrusted input is passed to resource-loading functions.

How an attack unfolds

An attacker would need an application-specific entry point where user-controlled input is passed directly or indirectly into pkgutil.get_data() as the resource argument. They would then attempt traversal sequences such as ../ to reference files outside the intended package resource location. Successful access would depend on the application exposing the returned data, the process filesystem permissions, packaging/runtime behavior, and the absence of application-level validation. The upstream project disputes this as a product vulnerability because pkgutil.get_data() is not intended to provide sandboxing or path containment beyond normal file access semantics.

How to fix it

No product-wide security patch is indicated from the provided data because the issue is disputed and no affected products or fixed versions are listed. Application maintainers should not rely on pkgutil.get_data() to constrain untrusted paths. If resource names can be influenced by users, enforce strict allowlists of known resource identifiers, reject absolute paths and traversal components, normalize paths before use, avoid returning raw file contents, run services with least-privilege filesystem permissions, and add tests for traversal attempts. Review updated upstream documentation so developer assumptions match the intended security model.

How to confirm the fix worked

Confirm whether any application code passes externally influenced values into pkgutil.get_data() or wrappers around it. Static searches should look for pkgutil.get_data( and trace the resource argument to request parameters, API payloads, command-line arguments, environment variables, message queues, or template names. Dynamic validation should send benign traversal probes such as ../ and URL-encoded variants to relevant endpoints and confirm they are rejected or mapped only to approved resources. Verify that allowlists, canonicalization, and least-privilege file permissions are in place. Because no fixed versions are listed, validation focuses on application-level safe usage rather than version compliance.

Typical attack path

1. Identify an application feature that retrieves packaged resources or templates based on user-supplied input.
2. Test whether the input reaches pkgutil.get_data() or similar file/resource loading logic without normalization or allowlisting.
3. Submit traversal-style resource names such as ../ or nested path variants to attempt access outside the intended resource directory.
4. Observe whether the application returns file contents, error differences, timing differences, or other evidence of unintended file access.
5. If successful, enumerate files readable by the application process and attempt to obtain secrets, configuration files, source files, or other sensitive local data.

How to detect it

To determine whether this pattern was already exploited, review application access logs, API gateway logs, WAF logs, and application error logs for traversal probes targeting features that load resources, templates, files, help pages, localization bundles, plugins, or static content. Look for repeated requests containing ../, encoded traversal variants, attempts to read sensitive local files, or application errors showing failed resource lookup paths. In code-level telemetry, inspect exceptions from resource-loading paths and any audit logs that record requested resource names. If the application returned file contents, compare response sizes and status codes for suspicious traversal requests. There are no CVE-specific network signatures because exploitation depends entirely on how an application exposes pkgutil.get_data().

• ../
• ..%2f
• ..%2F
• %2e%2e%2f
• %2e%2e/
• ..\
• ..%5c
• %2e%2e%5c
• /etc/passwd
• /etc/shadow
• /proc/self/environ
• /proc/self/cmdline
• /proc/self/cwd
• /proc/self/root
• C:\Windows\win.ini
• C:\Windows\System32\drivers\etc\hosts
• pkgutil.get_data(

What your security team should do

• Do not treat this as an emergency patch event unless internal applications pass untrusted input to pkgutil.get_data() or equivalent resource-loading code.
• Ask engineering teams to search codebases for pkgutil.get_data() usage and verify that the resource argument is not attacker-controlled without an allowlist.
• Add secure coding guidance stating that resource-loading and file-opening APIs do not provide sandboxing for untrusted paths.
• Prioritize review of internet-facing applications, developer portals, plugin systems, template loaders, and APIs that return local resource contents.
• Add regression tests for traversal payloads against any endpoint or function that loads packaged resources by name.
• Monitor application logs for path traversal probes, but calibrate severity because this CVE is disputed, has very low EPSS, and has no known exploitation or KEV listing.