CVE-2024-27317

What it actually does

The flaw is a Zip Slip-style path traversal in Apache Pulsar Functions Worker package extraction. An authenticated user who is allowed to upload Pulsar functions as JAR or NAR files can craft archive entries containing path traversal sequences such as ../ so that, when the Functions Worker extracts the archive, files are written outside the intended extraction directory. Because the write occurs with the privileges of the Pulsar process, successful exploitation can modify or create files accessible to that process, potentially altering configuration, poisoning classpaths or plugins, disrupting service operation, or setting up later code execution depending on filesystem permissions and restart/load behavior. The issue also affects Pulsar Broker deployments when the broker is configured with functionsWorkerEnabled=true.

Why it matters to the business

Organizations running affected Apache Pulsar versions with Pulsar Functions enabled risk an authenticated user turning a function upload capability into unauthorized file modification on Pulsar infrastructure. This can lead to message-processing disruption, tampering with broker or worker behavior, exposure of sensitive configuration material, and possible footholds for broader compromise if writable paths influence runtime behavior. Although exploitation requires authenticated access and a crafted archive, the EPSS value indicates meaningful exploitation likelihood, and the issue has been public for a long period, so exposed or loosely governed function-upload environments should be treated as high priority.

How an attack unfolds

An attacker first obtains valid Pulsar credentials or compromises an account with permission to upload functions. They create a malicious JAR or NAR package, which is structurally a ZIP archive, and include entries whose filenames contain traversal components such as ../../target-file. The attacker uploads the package through the Pulsar Functions API or administrative tooling. When the Functions Worker, or a Broker with functionsWorkerEnabled=true, processes the upload, it extracts archive contents without safely canonicalizing and enforcing the destination path. The malicious entries are then written outside the intended temporary extraction directory. The attacker can use this primitive to overwrite or plant files writable by the Pulsar service account, such as configuration, extension/plugin artifacts, startup-adjacent files, or application data, and may then trigger a reload, restart, or subsequent function execution path to make the modification take effect.

How to fix it

Upgrade Apache Pulsar to a fixed release for the deployed branch: 2.10.x users should upgrade to 2.10.6 or later; 2.11.x users to 2.11.4 or later; 3.0.x users to 3.0.3 or later; 3.1.x users to 3.1.3 or later; and 3.2.x users to 3.2.1 or later. Source builds should include Apache Pulsar commit a7ebc3de57cef9c068f2d018edc8b11fd328f6e3 or a later equivalent fix. Affected version ranges are 2.4.0 through 2.10.5, 2.11.0 through 2.11.3, 3.0.0 through 3.0.2, 3.1.0 through 3.1.2, and 3.2.0. As interim mitigations, disable Pulsar Functions where not required, set functionsWorkerEnabled=false on brokers that do not need embedded worker functionality, tightly restrict which authenticated users can upload functions, require review of submitted JAR/NAR packages, run Pulsar under a least-privilege service account, and ensure Pulsar runtime directories do not have write access to sensitive system paths.

How to confirm the fix worked

Confirm the running Apache Pulsar version is outside the affected ranges and matches a fixed release: 2.10.6+, 2.11.4+, 3.0.3+, 3.1.3+, or 3.2.1+. For source or custom builds, verify the fix equivalent to commit a7ebc3de57cef9c068f2d018edc8b11fd328f6e3 is present. Review broker and worker configuration for functionsWorkerEnabled=true and confirm that any enabled Functions Worker has been upgraded. Validate access controls by confirming only intended administrative or CI/CD identities can upload functions. Where safe in a non-production test environment, attempt to upload a benign test archive containing traversal-style entries and verify extraction is rejected or constrained to the intended directory. Also inspect filesystem ownership and permissions to ensure the Pulsar service account cannot write to sensitive directories outside required Pulsar paths.

Typical attack path

1. Identify an Apache Pulsar deployment with Pulsar Functions Worker enabled, or a Broker configured with functionsWorkerEnabled=true.
2. Obtain or compromise an authenticated Pulsar user that is authorized to upload functions.
3. Build a malicious JAR or NAR archive containing ZIP entries with path traversal sequences such as ../ or ..\.
4. Upload the crafted function package through Pulsar admin tooling or the functions REST API.
5. Allow the Functions Worker to extract the archive and write one or more files outside the intended extraction directory.
6. Use the written file to tamper with configuration, affect service behavior, disrupt Pulsar operations, or stage follow-on execution depending on local permissions and load paths.

How to detect it

To determine whether exploitation has already occurred, correlate Pulsar admin/API access logs, Functions Worker logs, broker logs, authentication and authorization logs, reverse proxy or ingress logs, and filesystem audit logs. Look for function creation or update requests that uploaded JAR or NAR packages, especially from unusual users, source addresses, automation tokens, or outside normal deployment windows. Search HTTP logs for traversal markers in multipart uploads, filenames, request bodies, or encoded paths, including ../, ..\, %2e%2e%2f, and %252e%252e%252f. Review Functions Worker logs around package extraction, function registration, and worker restarts for errors involving archive extraction, unexpected destination paths, or failed writes. On hosts or containers, compare file modification times in Pulsar configuration, plugin, lib, bin, data, logs, temporary, and function package directories against function upload timestamps. Investigate newly created or modified files owned by the Pulsar service account outside expected Pulsar extraction directories. If auditd, EDR, or container runtime telemetry is available, query for Java/Pulsar processes writing outside approved Pulsar runtime paths shortly after function upload requests.

• ../
• ..\\
• %2e%2e%2f
• %2e%2e%5c
• %252e%252e%252f
• %252e%252e%255c
• POST /admin/v3/functions/
• POST /admin/v2/functions/
• PUT /admin/v3/functions/
• PUT /admin/v2/functions/
• .jar
• .nar
• functionsWorkerEnabled=true
• pulsar-admin functions create
• pulsar-admin functions update
• org.apache.pulsar.functions.worker
• Failed to extract
• extract archive
• ZipEntry
• java.util.zip.ZipEntry
• /admin/v3/functions/
• /admin/v2/functions/

What your security team should do

• Inventory all Apache Pulsar brokers and Functions Workers, including embedded broker worker configurations using functionsWorkerEnabled=true.
• Prioritize upgrades for internet-reachable, multi-tenant, or broadly accessible Pulsar deployments and any environment where many users can upload functions.
• Upgrade affected Pulsar branches to 2.10.6+, 2.11.4+, 3.0.3+, 3.1.3+, or 3.2.1+ as applicable.
• Immediately restrict function upload permissions to a minimal set of trusted identities until patching and validation are complete.
• Search historical logs for suspicious function uploads, traversal strings, and unexpected JAR/NAR submissions.
• Inspect Pulsar runtime, configuration, plugin, extraction, and temporary directories for unexpected files modified around function upload times.
• Harden the Pulsar service account and filesystem permissions so archive extraction cannot modify configuration, binaries, service definitions, or other sensitive paths.
• Add SIEM detections for function upload API calls containing JAR/NAR uploads and for traversal encodings in HTTP requests or archive metadata.