Pandora CVE-2026-74764

The attacker only needs the ability to submit a TAR archive to Pandora for analysis - which is the platform's core, intended function - and no authentication is indicated by the CVSS vector (PR:N/UI:N), no user interaction, and no non-default feature toggle. The specific prerequisite is that the target processes attacker-supplied TAR archives through the vulnerable _extract_tar path (pre-fix code without filter='data'). Limiting factors that reduce real-world exposure: deployments that gate sample submission behind authentication or restrict it to trusted analysts, network-isolated instances, and impact bounded by the privileges of the Pandora worker process and which files are actually writable/targetable; the escalation to RCE versus mere DoS is not guaranteed and depends on the deployment's filesystem layout.

The signals are largely consistent toward high priority: the input CVSS 4.0 base is 10.0 (AV:N/AC:L/AT:N/PR:N/UI:N with high vulnerable- and subsequent-system impact), and accepting untrusted archives for analysis is Pandora's intended function, so the attack surface is exposed by design rather than by misconfiguration. Countering that, there is no CISA KEV listing and no EPSS score in the input, and no public exploit was identified - the only public artifact is the fix commit - so this reads as a serious but not yet actively-exploited issue. One caveat to verify: the 10.0 assumes PR:N, but real risk depends on whether a given deployment allows anonymous sample submission or gates it behind authentication; an internet-facing open-submission instance is far more exposed than an internal analyst-only one. On balance an operator running a public-facing Pandora instance should treat patching as urgent given the low complexity and file-write-to-RCE potential.

An attacker uploads a malicious TAR to a Pandora instance's normal submission interface; the archive contains a member named something like ../../../home/pandora/.config/malicious or an absolute path. When the worker extracts it, the file is written outside the sandbox - for example overwriting a config, script, or cron/startup file readable-writable by the worker - leading to persistence or code execution. No public exploit is identified, but the technique is well-documented and the crafted archive is trivial to build.